
Debug in Depth
ARM DDI 0029G Copyright © 1994-2001. All rights reserved. B-29
B.9 Behavior of the program counter during debug
The debugger must keep track of what happens to the PC, so that the ARM7TDMI core
can be forced to branch back to the place at which program flow was interrupted by
debug. Program flow can be interrupted by any of the following:
• Breakpoints on page B-29
• Watchpoin ts on page B-29
• Watchpoint with another exception on page B-30
• Debug request on page B-30
• System speed access on page B-31.
B.9.1 Breakpoints
Entry into debug state from a breakpoint advances the PC by four addresses or 16 bytes.
Each instruction executed in debug state advances the PC by one address or four bytes.
The usual way to exit from debug state after a breakpoint is to remove the breakpoint
and branch back to the previously-breakpointed address.
For example, if the ARM7TDMI core entered debug state from a breakpoint set on a
given address and two debug speed instructions were executed, a branch of minus seven
addresses must occur:
• four for debug entry
• two for the instructions
• one for the final branch.
The following sequence shows the data scanned into scan chain 1, most significant bit
first. The value of the first digit goes to the BREAKPT bit and then the instruction data
into the remainder of scan chain 1:
0 E0802000; ADD R2, R0, R0
1 E1826001; ORR R6, R2, R1
0 EAFFFFF9; B-7, two’s complement, seven instructions backwards
After the ARM7TDMI core enters debug state, it must execute a minimum of two
instructions before the branch, although these can both be NOPs (
MOV R0, R0
). For small
branches, you can replace the final branch with a subtract, with the PC as the
destination,
SUB PC, PC, #28
in the above example.
B.9.2 Watchpoints
The return to program execution after entry to debug state from a watchpoint is done in
the same way as the procedure described in Breakpoints on page B-29.
Comments to this Manuals