- Instant Power Drop on Connection: When the board is running independently, it works fine and the power LED stays fully illuminated. However, the exact millisecond I connect my DAP-Link probe harness to the board's SWD header, the 3.3V rail collapses, the power LED turns completely off, and the board powers down. This happens before executing any commands or clicking "Debug" in the IDE.
- Momentary Power Recovery and Crash During Debug: If I leave the probe connected and click the Debug button in MCUXpresso, the board suddenly gets powered back up and the LED turns back on. However, right when the flashing sequence begins, the system freezes at 3% progress with a Wire ACK Fault and a bus hang-up at memory location 0x2000A750. Immediately after this crash, the board powers down again and the LED turns off.
RT1064 Connect Script
DpID = 0BD11477 APID = 0x04770041
Disabling MPU
Configure FlexRAM for 768KB OC RAM, 128KB I-TCM, 128KB D-TCM
Finished
======================================================
...
Writing 1322080 bytes to address 0x70000000 in Flash
70008000 done 3% (32768 out of 1048576)
request to clear DAP error failed - status 5
After error Nn(05). Wire ACK Fault in DAP access -
Failed to read address register in DAP - Nn(05). Wire ACK Fault in DAP access
failed to send op Terminate message - rc Em(17). Debug port inaccessible after access at location 0x2000A750
Target error from Commit Flash write: Em(17). Debug port inaccessible after access at location 0x2000A750
- Hardwired BOOT_MODE[1:0] to 01 (Serial Downloader mode) via physical solder pads to isolate application interference.
- Target memory spaces are properly mapped to the internal 4MB QSPI flash baseline region at 0x70000000 within the IDE linker properties.
- The exact same DAP-Link probe seamlessly programs an official NXP MIMXRT1064-EVK kit using identical code and configuration parameters.
if power drop by connecting the probe，the power supply maybe undervoltage since the cmsis probe absorb energy suddenly during connectting. Can you check the power rail in the system？How many current the debugger need？
Hi @Anushka_SS ,
Thanks for your interest in NXP MIMXRT series!
All three symptoms (power drop when the probe is plugged in → board wakes up when you click Debug → hang at 3%) point to one single root cause: insufficient 3.3V supply margin on the board combined with an SWD/VTref wiring issue, causing a brown-out shutdown — not a software or flash-driver problem.
Why we're confident:
- You've hard-wired BOOT_MODE to Serial Downloader, so the application never runs — this rules out "app occupying the debug pins."
- The same probe and configuration work fine on the official EVK, so the difference is purely your custom-board hardware.
- A plain SWD connection draws almost no current, yet it collapses the entire 3.3V rail — this can only mean the probe is loading/back-feeding the 3.3V rail while the LDO trips into over-current protection.
About 0x2000A750: this address sits in DTCM (the 0x20000000 region), where the flash algorithm (flashloader) runs. The 3% mark is exactly when continuous writes to the QSPI flash begin and the core + FlexSPI current peaks — the supply can't hold up, the core browns out and resets, hence the Wire ACK Fault. It's simply where the device died on brown-out, not bad memory or a code bug.
Best regards,
Gavin
Thank you for you reply!
Actually I am facing an issue with the power-up and SWD programming of my custom i.MX RT1064 board.
I am using a TLV75733PDBV 3.3 V LDO. The LDO input is stable at 5 V, but sometimes the regulator does not produce 3.3 V because its EN pin remains low or has no voltage. The EN pin is controlled directly by the RT1064 through the PMIC_ON_REQ signal.
Sometimes PMIC_ON_REQ/EN suddenly becomes about 3.3 V, the regulator turns ON, the 3.3 V rail comes up correctly, and the board power LED starts glowing. However, this behavior is not consistent — sometimes the board powers up, sometimes it does not.
When the board is powered correctly and I then connect my MuseLab CMSIS-DAP probe for SWD programming, the 3.3 V rail drops again and the board powers down. At that point I get SWD errors such as:
Wire ACK Fault
Debug port inaccessible
Could not connect to core
The measured behavior is approximately:
Without probe:
U1 IN = 5.0 V
U1 EN = 3.3 V (sometimes)
U1 OUT = 3.3 V
POR_B = 3.3 V
After connecting probe:
U1 IN = 5.0 V
U1 EN = 0 V
U1 OUT = around 1.2–1.8 V
POR_B = around 2.1 V
So it looks like the LDO itself is not losing input power. Instead, the regulator is being disabled because its EN pin goes low.
My main questions are:
- Why is PMIC_ON_REQ from the RT1064 not consistently going high?
- Is this random power-up behavior caused by the RT1064 power-sequencing or reset circuit?
- Why does connecting the SWD probe cause PMIC_ON_REQ/EN to go low?
- Should the 3.3 V regulator EN be controlled directly from PMIC_ON_REQ, or should it be pulled up/handled differently?
- What is the recommended way to keep the 3.3 V rail stable so that I can reliably power and program the RT1064?
- Are there any important requirements for POR_B, DCDC_IN, DCDC_OUT, VDD_SNVS_IN, VDD_HIGH_IN, or boot-mode pins that could cause this behavior?
I previously made another custom board based on the Teensy 4.1 power circuit, and that board could be programmed successfully using the same CMSIS-DAP probe. The new PCB uses a very similar power circuit, but I added access to the boot-mode pins and changed the reset/power section slightly.
I am attaching my regulator section, reset circuit, power-pin connections, and boot-mode schematic. I would appreciate help checking whether the PMIC_ON_REQ/EN connection or RT1064 power-sequencing circuit is incorrect, and what changes are needed to get stable power and reliable SWD programming.
Hi @Anushka_SS ,
Thank you for providing the schematic. I took a look at it and found a few issues.
1. VDD_SNVS_IN: It cannot be floating. VDD_SNVS_IN supply must be turned on before any other power supply or be connected(shorted) with VDD_HIGH_IN supply. (Please strictly follow the power-up sequencing specified in the datasheet/RM and verify it on your board.)
2. Furthermore, this 3.3 V supply must not depend on PMIC_ON_REQ, while at the same time being used to power VDD_SNVS_IN. Otherwise, the SNVS domain will be de-energized during a cold start, and the internal state machine will not have a reliable condition to output PMIC_ON_REQ. Therefore, your LDO cannot power up reliably.
PMIC_ON_REQ can only be driven reliably after the RT1064's SNVS/PMU domain is up and running, and the SNVS domain first requires a valid supply on VDD_SNVS_IN. Since VDD_SNVS_IN is left floating on your board, PMIC_ON_REQ behaves erratically — the board powers up only intermittently, and it unexpectedly powers down the moment you connect the SWD probe.
In addition, do not drive the LED directly from PMIC_ON_REQ. A power-indicator LED should be placed on the stable 3.3 V rail, or isolated with a buffer/MOSFET. Hanging an LED + 470 Ω to ground on the PMIC_ON_REQ node effectively adds a significant load / pull-down path on this critical power-request pin. If the pin is in a high-Z or open-drain "ON" state, the LED branch pulls EN toward a low level; and even with a push-pull output, it forces this small SNVS-domain control pin to source the LED current — which is not recommended.
Best regards,
Gavin