topic Re: Problems debugging iMXRT1011 project in i.MX RT Crossover MCUs

Problems debugging iMXRT1011 project

expertsleepers — Mon, 03 Nov 2025 12:11:42 GMT

I have a simple custom board based on an iMXRT1011 processor. I'm using MCUXpresso IDE v24.12 and a Segger J-Link Ultra+. I'm experienced with iMXRT development in general and the J-Link has worked fine for me on another project.

Everything started fine, but at some point, I lost the ability to debug my project. The code runs fine if I install it using the serial boot loader (via the Secure Provisioning tool), but if I flash it from the debugger it doesn't run.

It seems to crash somewhere before main(). Sometimes I can set a breakpoint in ResetISR() and step through. In these cases everything is fine if I keep single stepping, but it crashes if I let it run. Sometimes it goes straight to 0xdeadbeee and there's nothing to debugger can do.

As you can imagine this is very frustrating. Any suggestions would be gratefully received.

Re: Problems debugging iMXRT1011 project

diego_charles — Tue, 04 Nov 2025 00:10:03 GMT

Hi @expertsleepers

Thank you for reaching out!

Maybe it is the FCB on your IDE side. Have you reviewed that? Let me explain.

When using the SEC tool, the SEC tool does not writes the image but writes a "minimalistic" FCB. When using the IDE the image contains the FCB (qspi_config if I remember well). Have checked that the FCB/qspi_config matches your image?

Best regards,

Diego

Re: Problems debugging iMXRT1011 project

expertsleepers — Tue, 04 Nov 2025 10:04:05 GMT

I'm using the attached files to configure the flash. They're copied from an SDK example, and I've checked that they're identical with the files on my working project.

The flash IC is the same on both boards, a Winbond W25Q64JVXGIQ.

Do these files define the "FCB" that you're referring to?

Re: Problems debugging iMXRT1011 project

diego_charles — Wed, 05 Nov 2025 16:01:50 GMT

Hi @expertsleepers

Thank you for your clarification, yes I was referring to those files as the FCB.

What if the problem lies on the current application settings? I want to differentiate if this is problem lies on flash settings, application settings or IDE.

what is the result if you try to run hello world demo? using your same FCB that already works.

Could you provide more details about your project?

Best regards,

Diego

Re: Problems debugging iMXRT1011 project

expertsleepers — Wed, 05 Nov 2025 16:31:33 GMT

It's a very simple board that I was using to test a few peripherals. Basically it's the MCU, a QSPI flash for XIP, a few SPI and I2C peripherals, and a USB port.

Perhaps I didn't make it clear that the project all worked fine and ran OK under the debugger until it reached a certain size. I was working on this quite happily for a couple of days until the debugger suddenly began to fail.

The IDE itself continues to work fine for my other project, so I'm not concerned about the IDE itself.

Re: Problems debugging iMXRT1011 project

diego_charles — Mon, 10 Nov 2025 22:11:00 GMT

Hi @expertsleepers

Thank you for your patience and more info!

Do you mean that If you commit back to a previous stage of your project, does debug starts to work better?

I wonder how I could replicate this problem on my side. Does this problem repeats by importing the project on other workspace or PC?

All the best,

Diego

Re: Problems debugging iMXRT1011 project

expertsleepers — Tue, 11 Nov 2025 09:19:49 GMT

> Do you mean that If you commit back to a previous stage of your project, does debug starts to work better?

Yes. However, after reverting to an old version, I have to flash the board once using the Secure Provisioning tool before debugging becomes reliable again. From then on, I can flash from the IDE as usual.

If I then go back to my latest code, I can debug successfully once, but then subsequent attempts fail.

> Does this problem repeats by importing the project on other workspace or PC?

I installed the IDE v25.6 on a fresh machine with no previous install, copied over the project, built and attempted to debug, and the result was the same.

Re: Problems debugging iMXRT1011 project

diego_charles — Tue, 11 Nov 2025 17:44:46 GMT

Hi @expertsleepers

Thank you for your clarification!

You mentioned earlier, this: Sometimes it goes straight to 0xdeadbeee and there's nothing to debugger can do.

If I understand well this deadbee problem only occurs with the debugger, and if you boot latest SW, without the debugger the does it works well rigth?

If you debug latest app using Segger's J-Link commander, letting the IDE aside, do you see any problems? I refer to using the go, and halt operations once the debugger is connected.

Could you share and idea of the changes on your latest SW version? Do a step by step debug, while you monitor program counter, and heap an SRAM. I do not know if you are using an RTOS. Check for any jumps to invalid addresses, for example from flash to SRAM, and viceversa.

Best regards,

Diego

Re: Problems debugging iMXRT1011 project

expertsleepers — Wed, 12 Nov 2025 11:40:01 GMT

If I flash the application with SEC, it runs fine. If I connect with J-Link commander, I can halt and go successfully.

In the IDE, today I can set a breakpoint at ResetISR(). If I step over SystemInit(), it crashes. If I step into SystemInit(), step through the function and then step over SystemInitHook(), it crashes. If I do the same and step into SystemInitHook(), it does not crash. This is what I mean when I say the behaviour depends on whether the debugger is stepping over or into the code.

An example of the stack when it crashes:

Thread #1 57005 (Suspended : Signal : SIGTRAP:Trace/breakpoint trap)

_vfprintf_r() at 0x600134a4

0x0

So it looks like it's jumping to 0x0, but only when the code is freely running, not when stepping in the debugger. There is no code at 0x0 - the ITC is not being used.

Just to repeat, this is before main(), long before any RTOS or similar is invoked. It's crashing in the initial startup code.

Re: Problems debugging iMXRT1011 project

expertsleepers — Thu, 13 Nov 2025 11:53:31 GMT

Further odd behaviour I've noticed this morning.

I set a breakpoint before the call to SystemInitHook(). You can see the disassembly of that function in the attached image.

Before the call, the SP is at 0x20207ff8 which is expected, having followed through the code. The call to SystemInitHook() is

bl 0x6001220c

If I step into the function in C, the debugger stops at 0x60012210 and the SP is still 0x20207ff8. The SP is also 0x20207ff8 when the function returns, which is as expected.

If I instead step into the function in instruction stepping mode, it executes the push instruction at 0x6001220c, reducing the SP to 0x20207ff4. So the SP is wrong when the function exits and subsequent code crashes.

Can you think what might cause this difference of behaviour? And is that SystemInitHook() correct? To have a push but no pop?

Re: Problems debugging iMXRT1011 project

expertsleepers — Mon, 24 Nov 2025 09:58:15 GMT

To rule out issues with my custom board, I obtained an MIMXRT1010 EVK. The behaviour is the same on the EVK board.

Re: Problems debugging iMXRT1011 project

Habib_MS — Wed, 03 Dec 2025 22:43:48 GMT

Hello @expertsleepers,
I understand that the issue started after you made changes to your code. in order to support you better, could you please share the specific modifications you applied compared to the original project?
In particular, I am interested in any changes related to the boot process, such as:

Updates to the FCB.
Adjustments to memory regions.
Whether you switched between XIP and non-XIP modes.

BR
Habib

Re: Problems debugging iMXRT1011 project

expertsleepers — Thu, 04 Dec 2025 08:43:20 GMT

I've not changed the FCB and have always used XIP.

I did change the memory regions. I do this in ResetISR()

#define IOMUXC_GPR_GPR16 (*(unsigned int*)0x400AC040)
#define IOMUXC_GPR_GPR17 (*(unsigned int*)0x400AC044)

void ResetISR(void) {
// Disable interrupts
__asm volatile ("cpsid i");
__asm volatile ("MSR MSP, %0" : : "r" (&_vStackTop) : );

// reconfigure the flexram
IOMUXC_GPR_GPR17 = 0xE9;
IOMUXC_GPR_GPR16 = IOMUXC_GPR_GPR16 | 0x4;

Re: Problems debugging iMXRT1011 project

Habib_MS — Wed, 10 Dec 2025 20:56:27 GMT

Hello @expertsleepers,

Could you please check if this app note helps you solve the problem?

BR
Habib

Re: Problems debugging iMXRT1011 project

expertsleepers — Thu, 11 Dec 2025 08:24:28 GMT

Both preprocessor symbols are set to 1 in my project.

XIP_EXTERNAL_FLASH=1

XIP_BOOT_HEADER_ENABLE=1

Re: Problems debugging iMXRT1011 project

Habib_MS — Fri, 12 Dec 2025 21:39:52 GMT

Hello @expertsleepers,

Could you perform a mass erase through MCUXpresso using the serial downloader configuration before debugging the application?
This in order to verify that the flashed application is not interfering with any communication between the debugger and the MCU.

BR
Habib

Re: Problems debugging iMXRT1011 project

expertsleepers — Mon, 15 Dec 2025 09:26:57 GMT

In the meantime I've unblocked myself by removing the instructions to reallocate the FlexRAM (mentioned in my post above).

If I leave the FlexRAM at its default allocation, I can debug fine.

Is there something wrong with how I'm reallocating the FlexRAM? I'm doing it in exactly the same way on another project and that's always worked fine.

Re: Problems debugging iMXRT1011 project

Habib_MS — Mon, 15 Dec 2025 18:58:31 GMT

Hello @expertsleepers,

The problem could be that the FlexRAM configurations are being manipulated while it is in execution, which may cause an unexpected error. Therefore, to use FlexRAM correctly, I highly recommend checking this app note that explains how to use FlexRAM in i.MX RT.
In the other hand, it could be that in your other projects you are not using FlexRAM, and it is configured correctly, which would not cause any issues.

Finally, I suggest you check out these community posts that might help you solve the issue:

Relocating Code and Data Using the MCUXpresso IDE - NXP Community

RT board recovery for debugger connect issues - NXP Community

BR
Habib

Re: Problems debugging iMXRT1011 project

expertsleepers — Mon, 15 Dec 2025 19:20:41 GMT

I'm aware of the app note. As you can see from my post, I'm changing the FlexRAM configuration at the start of the reset handler, as recommended by the app note. My other project does exactly the same thing and this has worked fine for over a year now.

Re: Problems debugging iMXRT1011 project

Habib_MS — Tue, 16 Dec 2025 21:01:56 GMT

Hi @expertsleepers,

If we look at the configuration of IOMUXC_GPR_GPR17 based on the app note that I provided to you, I can see that you have the following configuration:

However, keep in mind the following note:

Could you try another configuration that better fits the requirements of your application and complies with the note’s conditions?

BR
Habib