a debugger in halt processor mode connects to the processor

the stop button is pressed in the debugger

the processor hits a breakpoint or watchpoint

the processor passes through a vector and vector catch is enabled

the program running on the processor makes a semihosting call and standard semihosting is selected in the debugger

the debugger steps to the next instruction

external hardware, for example the ETM, asserts the DBGRQ signal on the core.

If multiple device execution control is required while making semihosting calls, DCC Semihosting must be set in the Processor Properties dialog in AXD. In ADW, the debugger internal variable semihosting_enabled must be set to 2. See the description of semihosting_enabled=2 in Debugger internal variables for more details.

The debugger uses breakpoints for its own purposes, but these are treated identically to your breakpoints by the Multi-ICE server. For example, if you create a breakpoint with a count value of 50 in AXD, the processor stops every time it hits the breakpoint, and then restarts until it has hit the breakpoint 50 times. This has the following consequences:

When you click Step in the debugger, stop events are actioned for that processor. This is because the step is implemented by setting a breakpoint on the next instruction and then starting the processor. When the processor hits the breakpoint the server carries out stop events as in every other case.

Usually when you load an image using a debugger, a breakpoint is automatically placed on the function main. Clicking Go runs through the initialization code to this point and you must press Go again to run the program. This breakpoint is treated just like any other breakpoint.