topic Re: debug through bootloader, or attach to a running target? in LPCXpresso IDE

debug through bootloader, or attach to a running target?

lpcware — Wed, 15 Jun 2016 23:59:48 GMT

Content originally posted in LPCWare by joeyoravec on Fri Oct 12 06:08:54 MST 2012
I've written a bootloader for my LPC11C24. The bootloader and main application are separate lpcxpresso projects, compiled as separate *.axf files, and converted to *.bin images that can be written to internal flash memory.

The problem is that at some point the bootloader jumps to the application like:

// We're currently running the bootloader at 0x00000000
// The main application exists at 0x00002000
// Get a function pointer to the main application's ResetISR
void (*(* const app_pfnVectors))(void) = 0x00002000;
void (*app_entry)(void) = app_pfnVectors[1];
// Run the main application, this will not return
app_entry();

which works fine, but the debugger was started for the bootloader project so it has no symbols loaded for, and cannot step into, the main application.

I want some way to debug the main application. My ideas so far were:

- Allow the bootloader to launch the main application, then make the debugger attach to an already running target. Is this possible?? Every time I debug it automatically resets the target, downloads code, and expects to start from reset.

- When debugging, compile a special version of the main app linked to run from 0x0 instead of the normal location. But this is not ideal because then I'd be debugging a binary that gets launched fundamentally differently than the one I ship to customers.

- Compile both bootloader and application into a single image, but this is also non-ideal since the two would have global symbol conflicts.

Any ideas? :confused:

Re: debug through bootloader, or attach to a running target?

lpcware — Wed, 15 Jun 2016 23:59:49 GMT

Content originally posted in LPCWare by ex-kayoda on Fri Oct 12 06:14:54 MST 2012

Quote: joeyoravec
Every time I debug it automatically resets the target, downloads code, and expects to start from reset.

Any ideas? :confused:

Did you try to debug a runing target already? http://knowledgebase.nxp.com/showthread.php?t=2787

Re: debug through bootloader, or attach to a running target?

lpcware — Wed, 15 Jun 2016 23:59:49 GMT

Content originally posted in LPCWare by ArtjomGromak on Fri Oct 12 13:07:22 MST 2012

Quote: joeyoravec
I've written a bootloader for my LPC11C24. The bootloader and main application are separate lpcxpresso projects, compiled as separate *.axf files, and converted to *.bin images that can be written to internal flash memory.

I did so:

1. Create bootloader project, which start application.

__set_MSP(*(uint32_t *)0x1000);
ISRPtr application_reset_handler=(ISRPtr)(*(uint32_t *)0x1004);
application_reset_handler();

2. Program bootloader in flash.

3. Create application project which is placed in flash from 0x1000.
4. Build application
5. Just debug application:
lpcxpresso write application to our flash region (0x1000) and don't erase bootloader. Bootloader started application. Debug is the same as
debug application without bootloader.

Quote: joeyoravec

- Allow the bootloader to launch the main application, then make the debugger attach to an already running target. Is this possible??

I think it's don't work.

Quote: joeyoravec

- Compile both bootloader and application into a single image, but this is also non-ideal since the two would have global symbol conflicts.
Any ideas? :confused:

One project for bootloader and application is bad idea.

Re: debug through bootloader, or attach to a running target?

lpcware — Wed, 15 Jun 2016 23:59:50 GMT

Content originally posted in LPCWare by daniel.widyanto on Sun Oct 14 21:38:33 MST 2012
Hi,

To debug the application, that's not stored in 0x00 (the default reset address), you can use the same method to debug the program that's running from SDRAM.

See http://knowledgebase.nxp.com/showthread.php?t=3589

Just set the PC to 0x2000, and SP = *0x2004 from GDB init script (the GDB init should emulate the bootloader's behavior).