Debugging from reset

You can debug systems running in ROM. A typical embedded system has the application programmed in non-volatile memory, such as ROM or Flash. When target hardware is powered up, the application starts running. When connecting the debugger to a target already running the application, the application stops at an arbitrary point in the code. The default behavior of the debugger is to stop the target on connection. Loading the image symbols gives you source code view of the current location.

This means that you can examine the state of the system and restart execution from the current place. In some cases, this is sufficient. However, in many cases it is preferable to restart execution of the application as if from power-on. There are three ways to do this:

When you debug code that is running from ROM, you must ensure that at least one breakpoint unit remains available so that you can set breakpoints on code in ROM, because you cannot use software breakpoints for this purpose. On a processor without vector catch hardware, you must disable semihosting and vector catching as soon as possible after starting up the debugger. This can reduce the chances of the debugger taking these units for its own use.

On ARM processors that use a breakpoint resource to implement software breakpoints, such as the ARM7TDMI, you must remove all software breakpoints if you are out of breakpoint resources. This enables you to place a single hardware breakpoint in ROM.

Another factor in debugging a system in ROM is that the ROM image does not contain any debug information. When debugging, symbol or source code information is available by loading the relevant information into the debugger from the ELF image on the host.

Show/hideSee also

Copyright © 2010-2011 ARM. All rights reserved.ARM DUI 0498D