Problems debugging iMXRT1011 project

[expertsleepers]

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.

[diego_charles]

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

[expertsleepers]

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?

[diego_charles]

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

[expertsleepers]

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.

[diego_charles]

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

[expertsleepers]

> 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.

[diego_charles]

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

[expertsleepers]

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

[Habib_MS]

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

[expertsleepers]

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;

[Habib_MS]

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

[expertsleepers]

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.

[Habib_MS]

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

[expertsleepers]

I will try that.

Could you explain though, why is the ROM requirement relevant? Since my application is already running when I change the FlexRAM, what ROM code would be running after that point?

I can understand that this would affect the boot loader if the FlexRAM was changed in the fuses. But I'm not changing the fuses - I'm changing the FlexRAM in software.

[Habib_MS]

Hello @expertsleepers,

Could you try to take that note into account to see if this resolves the issue?

In the other hand, the SDK (version 25.06) offers an example that configures the FlexRAM called “flex_ram_access”, I highly recommend analyzing this example to understand how it works so you can replicate it in your code.
Additionally, could you verify that the requirements mentioned in chapter 2.1.1.2 called “Runtime configuration” in the app note I provided to you are being met?

BR
Habib 

[Habib_MS]

Hello @expertsleepers,

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

BR
Habib

[expertsleepers]

Both preprocessor symbols are set to 1 in my project.

XIP_EXTERNAL_FLASH=1

XIP_BOOT_HEADER_ENABLE=1

[Habib_MS]

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

[expertsleepers]

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.

[expertsleepers]

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?