9.11. Exit from debug state

Leaving debug state involves restoring the internal state of the ARM9TDMI core, causing a branch to the next instruction to be executed, and synchronizing back to GCLK. After restoring the internal state, you must load a branch instruction into the pipeline. For details on calculating the branch, see The behavior of the program counter during debug.

Use bit 33 of scan chain 1 to force the ARM9TDMI core to resynchronize back to GCLK. The penultimate instruction in the debug sequence is a branch to the instruction where execution is to resume. This is scanned in with bit 33 set LOW. The core is then clocked to load the branch into the pipeline. The final instruction that you must scan in is a NOP (such as MOV R0, R0), with bit 33 set HIGH. You must the clock the core to load this instruction into the pipeline. Now, select the RESTART instruction in the TAP controller. When the state machine enters the RUN-TEST/IDLE state, the scan chain reverts back to system mode and clock resynchronization to GCLK occurs within the ARM9TDMI. Normal operation resumes, with instructions being fetched from memory.

The delay, until the state machine is in RUN-TEST/IDLE state, allows you to set up conditions in other devices in a multiprocessor system without taking immediate effect. Then, when RUN-TEST/IDLE state is entered, all the processors resume operation simultaneously.

The function of DBGACK is to tell the rest of the system when the ARM9TDMI core is in debug state. You can use this to inhibit peripherals such as watchdog timers that have real-time characteristics. Also, you can use DBGACK to mask out memory accesses that are caused by the debugging process. For example, when the ARM9TDMI enters debug state after a breakpoint, the instruction pipeline contains the breakpointed instruction plus two other instructions that have been prefetched. On entry to debug state, the pipeline is flushed. So, on exit from debug state, the pipeline must be refilled to its previous state. Therefore, because of the debugging process, more memory accesses occur than are normally expected. You can inhibit any system peripheral that might be sensitive to the number of memory accesses by using DBGACK.


DBGACK can only be used in this way using breakpoints. It does not mask the correct number of memory accesses after a watchpoint.

For example, consider a peripheral that merely counts the number of instruction fetches. This device must return the same answer after a program has run both with and without debugging. Figure 9.9 shows the behavior of the ARM9TDMI core on exit from debug state.

Figure 9.9. Debug exit sequence

Figure 9.10 shows that two instructions are fetched after the instruction that breakpoints. Figure 9.10 shows that DBGACK masks the first three instruction fetches out of the debug state, corresponding to the breakpoint instruction, and the two instructions prefetched after it.


When a system speed access occurs, DBGACK remains HIGH, masking any memory access.

Figure 9.10. Debug state entry

Copyright © 2000, 2001 ARM Limited. All rights reserved.ARM DDI 0184B