Can't flash / debug i.MX RT1010 (Em(12). Target rejected debug access at location 0x00000000)

[carotte]

Hi,

Im currently having a terrible experience with MCUxpresso + i.MX RT1010.

The problem is flashing the MCU. I always get the error:

Probe Firmware: DAPLink CMSIS-DAP (ARM)
Serial Number:  02270000118adf5000000000000000000000000097969905
VID:PID:  0D28:0204
USB Path: USB_0d28_0204_2120000_ff00
Using memory from core 0 after searching for a good core
warning - watchpoint hit but none found set
debug interface type      = CoreSight DP (DAP DP ID 0BD11477) over SWD TAP 0
processor type            = Cortex-M7 (CPU ID 00000C27) on DAP AP 0
number of h/w breakpoints = 8
number of flash patches   = 0
number of h/w watchpoints = 4
Probe(0): Connected&Reset. DpID: 0BD11477. CpuID: 00000C27. Info: <None>
Debug protocol: SWD. RTCK: Disabled. Vector catch: Disabled.
Content of CoreSight Debug ROM(s):
RBASE E00FD000: CID B105100D PID 000008E88C ROM (type 0x1)
ROM 1 E00FE000: CID B105100D PID 04000BB4C8 ROM (type 0x1)
ROM 2 E00FF000: CID B105100D PID 04000BB4C7 ROM (type 0x1)
ROM 3 E000E000: CID B105E00D PID 04000BB00C Gen SCS (type 0x0)
ROM 3 E0001000: CID B105E00D PID 04000BB002 Gen DWT (type 0x0)
ROM 3 E0002000: CID B105E00D PID 04000BB00E Gen (type 0x0)
ROM 3 E0000000: CID B105E00D PID 04000BB001 Gen ITM (type 0x0)
ROM 2 E0041000: CID B105900D PID 04001BB975 CSt ARM ETMv4.0 type 0x13 Trace Source - Core
ROM 2 E0042000: CID B105900D PID 04004BB906 CSt type 0x14 Debug Control - Trigger, e.g. ECT
ROM 1 E0040000: CID B105900D PID 04000BB9A9 CSt type 0x11 Trace Sink - TPIU
ROM 1 E0043000: CID B105F00D PID 04001BB101 Sys (type 0x0)
NXP: MIMXRT1011xxxxx
DAP stride is 1024 bytes (256 words)
Inspected v.2 External Flash Device on SPI using SFDP JEDEC ID MIMXRT1010_SFDP_QSPI.cfx
Image 'iMXRT1010_SFDP_QSPI Dec 18 2024 17:30:03'
Opening flash driver MIMXRT1010_SFDP_QSPI.cfx
Sending VECTRESET to run flash driver
chip initialization failed - Em(12). Target rejected debug access at location 0x00000000
failed to initialize flash driver MIMXRT1010_SFDP_QSPI.cfx

I was previously able to flash / debug in the same way (before the project was on hold for several months).

This failure occurs in all tested configurations:

Custom board + MCU Link Pro

I.MX RT1010 EVK + MCU Link Pro

I.MX RT1010 EVK + On-board programmer

However, the rate of failure seems to be lowest with the I.MX RT1010 EVK + On-board programmer.

I'm talking about a 1 in 50 attempts chance of getting a successful debug session, which is still abysmal.

I tried on three different computers, one Mac and two Windows 11 machines, each with MCUX versions 24.12.148 and 11.9.0.

The former because it is the latest version, latter because it was the version I used before the project was put on hold.

On one of the two Windows computers, I was able to successfully flash / debug every time under version 11.9.0 for a day. On the next day, I got the same behavior as with all other systems, which was not being able to debug, or at least with abysmal success rates.

This is when the boot switches are in the „OFF, OFF, ON, OFF“ positions on the EVK. 

I am always able to flash the board when all switches are off, then reset and attach for debug manually.

Changing the flash driver reset mechanism has had no effect.

I also tried with a J-Link firmware, which shows no error, but debugging also doesn’t work, which seems to be an entirely different rabbit hole to get the board working with J-Link.

I'm hoping to get some advice on how to flash / debug reliably one way or the other.

Thanks!

[carotte · Accepted solution]

After some more hours of experimentation, I finally found the problem…

I had my connect script path like this:

    <stringAttribute key="internal.connect.script"value="${workspace_loc}\evkmimxrt1010_FlexRAM_BK_dev_audio_speaker_freertos\RT1010_connect_0itcm.scp"/>

This path might have existed at some point, but no longer did.

Apparently, instead of warning the user, MCUXpresso just uses the default (in this case incompatible) connect script, resulting in the aforementioned error message.

I changed the line to 

<stringAttribute key="internal.connect.script" value="${ProjDirPath}/RT1010_connect_0itcm.scp"/>

And now it works..

IMHO MCUX should complain if it can't find a given path.

This would have spared me a lot of frustration.

[carotte]

Thanks for your quick reply!
I tried your suggestion.

In this case, using the Mac with MCUX version 24.12.148 and the EVK.

Doing the mass erase took 4 attempts to succeed. The three first gave me the "Wire ACK Fault".
After successfully performing the mass erase, I tried debugging the "Hello World" project from the SDK. 
1. Attempt: Wire ACK Fault
2. Attempt: Success
3. Attempt: Em 12 Fault (like originally stated)
4. Attempt: Wire ACK Fault 

So that wasn't a success...

[EdwinHz]

Hi @carotte,

How are you powering the board? In what position is the J1 placed? Try placing it on position 3-4 and power the board using another micro-USB on J9. Let me know if this makes the programming more stable.

[carotte]

I tried all available options (powering via debugger, powering via MCU USB), but this has no effect on the issue.

[EdwinHz]

Hi @carotte,

And does this happen with other debugging tools like Secure Provisioning Tool?

[carotte]

After some more experimentation, it seems that this is at least partially related to my project.

Here are some examples of what works and what doesn’t work:


Erase Flash -> Switch to internal boot -> Flash MyProject -> Works -> Flash again -> Error

Erase Flash -> Switch to internal boot -> Flash LED Blinky -> Works -> Flash again -> Works

Erase Flash -> Switch to internal boot -> Flash LED Blinky -> Works -> Flash MyProject -> Works -> Flash MyProject again -> Error

Erase Flash -> Switch to internal boot -> Flash MyProject -> Works -> Flash LED Blinky -> Error


So basically, if my project is flashed once, a Flash Erase needs to be done before flashing any other application.

I tried reverting MyProject's state to when it was just SDK example (i'm using Git for version control), but the issue persists.

Does that help in narrowing down the issue?

[carotte]

Flashing does work with secure provisioning tool (tried via USB), but that's not really debugging.

As mentioned, loading the application with the debugger also works, but only when in ISP mode.

[EdwinHz]

Hi @carotte,

Please follow the steps described in the following knowledge base article and flash an example code from our SDK to your board, and let me know if the problem persists: RT board recovery for debugger connect issues - NXP Community.

BR,
Edwin.