4.11.1. Debugging from reset

You can use the Multi-ICE DLL to debug systems running in ROM. Typically, when a target board with an application stored in ROM is powered up, the application begins running. Therefore, when the debugger is started up on the host, the processor on the target is stopped. At this stage, the application can be at any point in its execution lifetime, depending on when the debugger was started.

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 two ways to do this:

When you debug code running from ROM, ensure that at least one watchpoint unit remains available to allow breakpoints to be set on code in ROM, because you cannot use software breakpoints. The chances of the debugger taking these units for its own use can be reduced by not using standard semihosting or vector catching. To do this on a processor without vector catch hardware you must set the following debugger internal variables as soon as possible after starting up the debugger:

semihosting_enabled = 0
vector_catch = 0

Next set up any ROM breakpoints before any non-ROM breakpoints or watchpoints are set. Otherwise the watchpoint units might be full, causing the attempt to set the ROM breakpoint to fail with a debugger-dependent message saying that there are too many breakpoints already set to add another.

Another factor in debugging a system in ROM is that the ROM image does not contain any debug information. When debugging using the Multi-ICE DLL, symbol or source code information is available by loading the relevant information into the debugger from a file on the host, for example by using Load Symbols....

Simulating a reset

You can often simulate a reset from within the debugger by setting:

  • pc to 0 (the address of the reset vector)

  • cpsr to %IF_SVC (to change into Supervisor mode with interrupts disabled).

This simulates the state of the ARM processor at power-on or reset, but it does not allow for a reset memory map or the initialization of any target-specific features such as peripheral registers. You are recommended to modify any of these target-specific features to resemble their startup state before executing the application again, if this is possible. You can automate this procedure with the scripting facilities of your debugger, as shown in Example 4.5 for ADW. The name embed.axf must be replaced with the name of the file that the target is executing. You might also have to change the top_of_memory value shown, depending on the memory layout of your target.

Example 4.5. Suggested reset script for ADS versions of ADW, ADU

readsyms embed.axf
pc = 0x0
cpsr = %IFt_SVC
$vector_catch = 0
$semihosting_enabled = 0
$top_of_memory = 0x40000

The same example for AXD is shown in Example 4.6.

Example 4.6. Suggested reset script for AXD

loadsymbols embed.axf
setpc 0
sreg cpsr 0xd3
spp vector_catch 0
spp semihosting_enabled 0
let $top_of_memory 0x40000

Carrying out a real reset

Depending on the design of the reset circuitry, you might be able to carry out a real reset of the board. However, take care about when this is done, because if the EmbeddedICE logic is also reset, the debugger might not be able to regain synchronization. Two forms of reset are required on the board:

  • a full power-on reset that resets everything on the board

  • a reset button that resets everything on the board except the EmbeddedICE logic.

See Chapter 6 System Design Guidelines for more information about the different forms of reset.

If a hardware breakpoint is set on the reset vector (or on the start address of the reset code) and the recommended reset circuit is used, when the target is reset, it halts on reset as required.


If Multi-ICE is unable, because of the wiring of the hardware, to detect a reset on your target, you are recommended to delete all other software breakpoints and watchpoints before resetting the processor.

Example using the ARM Integrator board

The ARM Integrator board implements the required two levels of reset. The reset switch carries out the required initialization reset, so enabling debug from reset. All that is required is to set the hardware breakpoint, and then press the Reset button.

Copyright © 1998-2002 ARM Limited. All rights reserved.ARM DUI 0048F