MIMXRT1064-EVK OpenSDA fails to run

[marcohaddad]

Hello everyone,

I have been playing with a MIMXRT1064-EVK for a few weeks now and suddenly, I'm not sure when and what I was doing at that time, its on-board OpenSDA debbuger lost its ability to run a program after loading it.

I'm using MCUXpresso IDE v11.1.1, which I have been using with a bunch of other MCUs for some years now. When I command to enter debugging, no matter which SDK example I pick, it loads the binary to the RT1064 flash but instead of running it pops an error message "Target error from Set break/watch: Et:96: Pseudo-address (0xFFFFFFxx) for EXC_RETURN is invalid (GDB error?)", as the attached picture.

Choosing OK on that popup message stays in the debugger and I can inspect the address 0x70002000 and confirm the program was loaded at the right place. Choosing Cancel exits the debugger and the loaded program starts and executes normally.

I have tried both available debugger modes, CMSIS-DAP and LPC-Link2, and the exactly same error occurs.

With a borrowed Segger J-Link connected to the 20-pin JTAG header it works just fine like before this problem started.

Can anybody help?

Thanks in advance,

Marco Haddad

[victorjimenez]

Hi Marco, 

Please follow the steps on the attached pdf file. Let me know if this solves the behavior you are facing. 

Best Regards, 

Victor 

[marcohaddad]

Hello Victor,

Thanks for your reply.

I did already try that, but even in serial boot mode (sw7=0001) I get the same error.

I understand that method helps to replace any very wrong program in the flash before it is run, but as I said, every demo program I've tried gets loaded to flash and runs correctly. I just can't execute it step by step in the debugger.

Regards,

Marco Haddad

On Fri, Apr 3, 2020 at 3:04 PM victorjimenez <admin@community.nxp.com>

[victorjimenez]

Hello Marco, 

Thanks for sharing more information. I have some questions: 

What version of the SDK are you using?

What version of MCUXpresso IDE are you using?

Could you please share with me a photo of your board? This way I can see if a bad configuration of a jumper might be the root cause of this behavior. 

If you use an external debugger you are able to debug the SDK examples without any problems, correct? 

Regards, 

Victor 

[marcohaddad]

Hello Victor,

My SDK is the lastest v2.7.0 and MCUXpressoIDE is 11.1.1_3241. But I don't see how this could affect since compiled programs are loaded and run correctly, but just can't be debugged. And, yes, I can debug those same programs with an external debugger.

As you can see on the attached photo, the only jumpers I've touched are J41, to test LPC-Link2 mode, and obviously J1 to power the MCU with another source.

I believe that being unable to set a breakpoint is the reason for this debugging problem. I just can't figure why...

Best regards,

Marco Haddad

[victorjimenez]

Hello Marco, 

Thanks for sharing more information about it. Before testing the LPC-Link2 mode, were you able to debug the SDK examples without any problems? Which examples are you trying to debug? I asked all these questions because I'm unable to reproduce this behavior on my end. 

Also, could you please try re-programming your FreeLink adapter with the DAPLink binary? You will find this file on the next link along with the instructions on how to achieve this: OpenSDA Serial and Debug Adapter | NXP 

Regards, 

Victor 

[marcohaddad]

Hi Victor,

The OpenSDA debugger was working normally at the time I got the board. I did used a few SDK examples to test it, but other jobs made me leave it aside for a few weeks and afterwards it was not working any more.

The SDK examples I used are the most simplistic iled_blinky and hello_world_virtual_com.

I only tried the LPC-Link2 mode after when debugging was not working, but the result is the same: flash gets programed but only runs after the MCU is reset or power cycled.

I did followed those instructions and retried a few times. I always get to the same point. There is one thing I didn't quite understand though. How do I check which Bootloader and Application version are already programmed on the board? Then it says to drag'n drop the Freelink Application binary file into the BOOTLOADER drive. Well, actually the drive is named MAINTENANCE, but it's okay, the confusing part is which of the two binaries is to be used. The Freelink V0244 or the DAPLink v0246?

Any way, if I paste the first file, which actual name is lpc4322_bl_crc_20180810.bin, I get an error message saved in a FAIL.txt file saying "The application file format is unknown and cannot be parsed and/or processed.". When I paste the second file, the lpc4322__mimxrt1064_evk_if_crc_20180810.bin, the red led on the debugger side goes off after a few seconds and the MCU starts running the iled_blinky demo I left loaded. And I still can't debug...

Any idea about that message "Target error from Set break/watch: Et:96: Pseudo-address (0xFFFFFFxx) for EXC_RETURN is invalid (GDB error?)" ???

Thanks in advance,

Marco Haddad

[victorjimenez]

Hi Marco,

The correct file you need to drag'n drop into the MAINTENANCE device is the DAPLink v0246. Once you do this, if everything went fine you should see that the red LED on the boards goes off and now your board is recognized as RT1064-EVK instead of MAINTENACE.

Do you have a lot of breakpoints in the project that you are currently trying to debug? If so, could you please delete all the breakpoints and see if this fixes the behavior that you are facing? You are trying to debug the iled_blinky example from the SDK as it is or did you make some changes? If you did make some changes, could you please share that project with me?

Regards,

Victor 

[marcohaddad]

Hello Victor,

The iled_blinky was freshly reloaded from the SDK with no change at all. I just compiled it and started debugging to get that error message again.

I did not set any breakpoint, but since you mentioned it too, I opened the breakpoint list and, bingo, there was a breakpoint at address 0xFFFF_FFFF before the normal main() breakpoint. Who the hell set that breakpoint???

I've never seen a persistent breakpoint. Even changing the active project it stays there. If the project is deleted and reloaded from the SDK, it is there yet.

Fortunately the infamous breakpoint was deletable and, once deleted, it didn't come back and the debugger is happy again.

The LPC-Link2 mode is working too. Thanks!

Best regards,

Marco Haddad

[victorjimenez]

Hello Marco, 

I'm glad to hear that the debugger is working fine now! Regarding the breakpoint at address 0xFFFF_FFFF this is weird, I made tons of tests on my side and I wasn't able to reproduce this. If you find how this breakpoint ended up here please let me know to see if I can reproduce this behavior. 

Best Regards, 

Victor