How to debug relocated code

[WilliamW]

I have a project for a MK64FX512VLQ12 that I've relocated from 0x0 to 0x20000 and I am trying to debug it.  I built the program using the configuration tools.  I'm guessing that the vector table isn't just going to work in the new location and that I might need to tell the debugger to run from some offset.  Are there any articles, pointers, or something that someone could point me to in order to debug my relocated code?

[ErichStyger]

As for debugging relocated code:

gdb has a feature to load symbols with a given offset.

This is needed for example with position-independent code too, for which I wrote an article about it:

https://mcuoneclipse.com/2021/06/05/position-independent-code-with-gcc-for-arm-cortex-m/

Last section in this article covers how to tell the debugger the relocated symbols.

I hope this helps,

Erich

[ErichStyger]

Hi @WilliamW ,

are you suing PIC (Position Independent Code)? In that case you don't need to the tell the debugger anything to debug it because everything is relative to a PIC descriptor.

If you just moved the address map by the linker (e.g. to load it by a bootloader), then see https://mcuoneclipse.com/2020/11/03/debugging-bootloader-and-application-with-one-debug-session/

I hope this helps,

Erich

[WilliamW]

Thanks for your suggestion.  I am not using position independent code.  The example you provided isn't really what I am looking for at the moment as I just want to be able to debug my relocated code.  When I try to debug my code relocationed to 0x20000, it I get a hard fault with the following stack trace (screen shot attached).

[ErichStyger]

The hard fault and the reloacated code are two different things: if your code runs wild and executes instructions around address zero, then your debugger very likely shows what you see here: regardless from where you come, there is nothing useful to show around address zero with respect to source code.

You will have to set a breakpoint earlier in your code with the technique I described in that article (with the symbols loaded) and then debug until you get the hard fault.

What I recommend and this might not help in all cases of a hard fault is to install a custom hard fault handler, see https://mcuoneclipse.com/2012/11/24/debugging-hard-faults-on-arm-cortex-m/

I hope this helps,

Erich

[WilliamW]

I took a running application and set the program flash address to 0x20000.  I then attempted to debug it in the MCUxpresso debugger (without a bootloader).  Instead of stopping at the first line of main it triggered a hard fault.  So when you say "if your code runs wild" are you referring to the start up code for the application?  It's not well documented (if you have references please advise), so I don't really know where to stop the debugger.  In any case it would seem to be a sufficiently common issue that the problem and fix would be known.  Am I trying to do something that the MCUxpresso debugger just isn't capable of doing without the bootloader installed?  I had this working nicely with a ColdFire processor running on CodeWarrior so I just assumed that this would be possible if not trivial.  Thanks for your help.

[converse]

What are you setting the PC to when you start debugging? Typically, the start of the image contains the stack pointer and the next word contains the initial PC address. If you are just trying to run from 0x2000, I would guess you are trying to run the stack pointer...

[WilliamW]

Yes.  I agree that is what is probably happening.  Do I need to set PC manually?  Should I use the Set PC (absolute hex address or symbol) field in the Debug Startup tab to do this.  However there doesn't seem to be a way set the Stack Pointer in the Startup tab.  Any idea how I would do that?  Do I also need to do something with the vector table since I believe it points to 0x0 to start?  Thanks again.