Other NXP ProductsのトピックRe: MIMXRT1064CVL5B Custom PCB Flash Failure

MIMXRT1064CVL5B Custom PCB Flash Failure

Anushka_SS — Thu, 06 Aug 2026 10:58:07 GMT

Hi everyone,

I am bringing up a custom board utilizing the MIMXRT1064CVJ5B processor. The board is powered by an external 5V SMPS power supply fed into a 3.3V LDO regulator. I am using a CMSIS-DAP / DAP-Link debug probe to program and debug via the SWD interface inside MCUXpresso IDE.

I am encountering a highly specific, repeatable power state crash when attempting to flash my code.

The Symptoms:

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.

LinkServer Debug Console Log Output:

============= SCRIPT: RT1064_connect.scp =============
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

What I have tried so far:

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.

Why is the connection causing an immediate power drop, why does the board temporarily wake up during debugging, and why does it consistently deadlock at the 3% flash mark? Any guidance on how to reliably program the chip with this layout behavior would be highly appreciated.

Thanks!

Re: MIMXRT1064CVL5B Custom PCB Flash Failure

Gavin_Jia — Fri, 07 Aug 2026 03:11:39 GMT

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

Re: MIMXRT1064CVL5B Custom PCB Flash Failure

db16122 — Fri, 07 Aug 2026 03:29:56 GMT

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？

Re: MIMXRT1064CVL5B Custom PCB Flash Failure

Anushka_SS — Fri, 07 Aug 2026 09:59:43 GMT

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.