By default, when debugging an embedded application, the target usually stops at main():

That’s usually fine, but what if I want to debug the code out of reset?

💡 I’m using the Eclipse based NXP MCUXpresso IDE 10.3 in this article, but same or similar things apply to most modern gdb + Eclipse based IDEs.

Why does the application stop at main? Because the debugger has set a temporary breakpoint on the main symbol (or function):

This is confirmed by the Log in the Debugger Console view:

So what happens is:

1. Debugger downloads the binary
2. Debugger sets a temporary breakpoint at main
3. Debugger issues a reset to the target followed by a ‘run’
4. The target will stop at the temporary breakpoint

Obviously a simple way to debug the startup code is to set a breakpoint in the startup code itself:

Another way is to inspect and change the debugger launch configuration. Because this might be different for each debug configuration, I’ll show it for LinkServer, Segger and PEMicro.

LinkServer

The LinkServer (CMSIS-DAP, LPC-Link2) connection does not have a dedicated ‘run’ setting: To debug the startup code, I have to change the ‘main’ to the ‘ResetISR’ Symbol. To revert back, change the symbol back to ‘main’.

Segger

With the GNU Mcu Eclipse plugins the settings are as shown below and easy to change:

To do startup code debugging, disable the ‘Continue’ option.

P&E (PEMicro)

The screenshot below shows the setting for P&E to set the temporary breakpoint and the ‘run on reset’ setting which are easy to find and change:

To start debugging from the reset vector, simply disable the ‘Run on reset’ option.

Summary

In order to debug the startup code with Eclipse and GDB, I could set a breakpoint in the reset routine, or better I can change the setting in the Eclipse CDT launch configuration to halt in the ResetISR (or whatever the reset function name is).

Happy Startuping 🙂

Links

• MCUXpresso IDE: http://www.nxp.com/mcuxpresso/ide
• GNU MCU Eclipse plugins: https://gnu-mcu-eclipse.github.io/