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.

[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?

[expertsleepers]

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.