2

I need to run a RAM app on an imx rt 1024, through JLink.

What works

I have a simple SDK example (blink) which is compiled to SRAM (0x20000000 on the imx rt). When I launch that project from the IDE, it runs. I can verify in the debugger that it's running in SRAM.

After I stop debugging (app remains running) I can go in JLink commander and execute

reset
loadfile myapp.axf 0x20000000 noreset
halt
setpc 0x20000000
go

And the app runs again, from SRAM. When I enter halt I can see that PC is running somewhere in the 0x20000000 region of SRAM.

What doesn't work

When I

  • power off the board,
  • and power it again,
  • connect via JLink,
  • and enter the same commands as above

I always end up in the internal bootloader. The app never runs.

Why....

I have googled so much, and all I can find is that it "should work" exactly the way I am doing it. I am 100% sure that the binary (.axf) is good. When I launch from MCUxpresso the exact same binary is used.

I also used arm-none-eabi-objcopy to extract the .bin file, but it makes no difference. It works when I launched the project from the IDE. It never works when I powered cycled the board.

Who can help me out? What is the magical command I am missing?

bas
  • 541
  • 1
  • 7
  • 21
  • 1
    First halt, then load the program. – Eugene Sh. Feb 15 '23 at 22:12
  • 1
    When the chip isn't halted, it is running the bootloader and setting some memory under it's feet and changing pc when it is in unknown state isn't a good idea. – Eugene Sh. Feb 15 '23 at 22:19
  • same result, all goes fine, but app never starts – bas Feb 15 '23 at 22:51
  • @bas - Hi, Thanks for coming back with an answer to your question. In order to effectively mark the topic as solved, please consider "[áccepting](https://meta.stackexchange.com/q/5234)" your choice of the best answer (i.e. click the "tick mark" next to an answer - [your answer](/help/self-answer) or another one, if one is written - to turn the relevant tick mark green). This shows that you don't need more help and future readers can quickly see there was a confirmed solution. Thanks. – SamGibson Feb 24 '23 at 16:57

1 Answers1

2

Do you recognize these moments where you are so happy, and you want to hit yourself in the face at the same time.....

The problem has nothing to do with memory being overwritten, nor is there any dark magic going on.

When I started to compare the memory loaded by mcuxpresso (or through vscode/cortex-debug) against the memory after loading the bin file through JLink, I learned three things.

  1. The memory is equal
  2. I am an idiot.
  3. I am instructing JLink to jump to 0x20000000

The memory after loading my app

J-Link>mem32 0x20000000,40
20000000 = 20010000 200002DD 20000361 200045D1 
20000010 = 20000365 20000367 20000369 00000000 
20000020 = 00000000 00000000 00000000 2000036B 
20000030 = 2000036D 00000000 2000036F 20000371 
20000040 = 20004161 20004169 20004171 20004179 
20000050 = 20004181 20004189 20004191 20004199 
20000060 = 200041A1 200041A9 200041B1 200041B9 

Stackpointer = 20010000
Address of reset handler = 200002DD

Djeeze, what would happen when I jump to that address instead...

For completeness for anybody who makes the same mistake, this script works just fine.

halt
loadfile myapp.axf 0x20000000 noreset
setpc 0x200002DD
go

To be fair, Eugene makes good points. In my case the moment of halting didn't matter. But to be sure the internal bootloader doesn't overwrite memory while it's still active, halt first, then load. Solid advice. Thx for that too.

bas
  • 541
  • 1
  • 7
  • 21