B.6.3. Exit from debug state

Leaving debug state involves:

After restoring the internal state, a branch instruction must be loaded into the pipeline. See Behavior of the program counter during debug for details on calculating the branch.

The SYSSPEED bit of scan chain 1 forces the ARM7EJ-S processor to resynchronize back to CLK conditioned with CLKEN. The penultimate instruction in the debug sequence is a branch to the instruction at which execution is to resume. This is scanned in with bit 32 (SYSSPEED) clear. The final instruction to be scanned in is a NOP (such as MOV R0, R0), with bit 32 set. The core is then clocked to load this instruction into the pipeline.

The ARM instructions shown in Example B.4 are used to exit from debug state to Jazelle state.

Example B.4. Forcing the processor from debug state to Jazelle state

BXJ r0         ; jump to Jazelle state
LDMIA r0,{pc}  ; reload pc
MOV pc,pc      ; system speed access to return to functional Jazelle state

Next, the RESTART instruction is selected 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 CLK conditioned with CLKEN occurs within the ARM7EJ-S processor. Normal operation then resumes, with instructions being fetched from memory.

The delay, waiting until the state machine is in RUN-TEST/IDLE state, enables conditions to be set up 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 ARM7EJ-S processor is in debug state. You can use this signal 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 ARM7EJ-S processor 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. It is possible, using the DBGACK signal and a small amount of external logic, for a peripheral which is sensitive to the number of memory accesses to return the same result with and without debugging.


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

For example, consider a peripheral that simply counts the number of instruction fetches. This device must return the same answer after a program has run both with and without debugging.

Figure B.5 shows the behavior of the ARM7EJ-S processor on exit from debug state.

Figure B.5. Debug exit sequence

In Figure B.6, two instructions are fetched after the breakpointed instruction. Figure B.5 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.

Under some circumstances DBGACK can remain HIGH for more than three instruction fetches. Therefore, if you require precise instruction access counting, you must provide some external logic to generate a modified DBGACK that always falls after three instruction fetches.


When system speed accesses occur, DBGACK remains HIGH throughout. It then falls after the system speed memory accesses are completed, and finally rises again as the processor reenters debug state. Therefore, DBGACK masks all system speed memory accesses.

Copyright ©  2001 ARM Limited. All rights reserved.ARM DDI 0214B