Debug in Depth
B-30 Copyright © 2001, 2004 ARM Limited. All rights reserved. ARM DDI 0210C
B.9 Behavior of the program counter in debug state
The debugger must keep track of what happens to the program counter, 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:
• Software breakpoints
• Watchpoints
• Watchpoint with another exception on page B-31
• Debug request on page B-31
• System speed access on page B-32.
B.9.1 Software 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. In the above example, this could be:
SUB PC, PC, #28
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 Software breakpoints.
To Next Page
Loading...
Need help?
General
