
Debug Support
ARM DDI 0144B
Copyright 1999, 2000 ARM Limited. All rights reserved.
8-33
8.9
Exit from debug state
Leaving debug state involves restoring the ARM940T internal state, causing a branch
to the next instruction to be executed, and synchronizing back to
GCLK
. After restoring
the internal state, a branch instruction must be loaded into the pipeline. For details on
calculating the branch, see
The behavior of the program counter during debug
on
page 8-36.
Bit 33 of scan chain 1 is used to force the ARM940T 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 to be scanned in is a NOP (such
as
MOV r0, r0
), with bit 33 set HIGH. The core is then clocked to load this instruction
into the pipeline, and 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
GCLK
occurs within the ARM940T.
Normal operation then resumes, with instructions being fetched from memory.
The delay, until the state machine is in RUN-TEST/IDLE state, allows conditions to be
set up in other devices in a multiprocessor system without taking immediate effect.
When RUN-TEST/IDLE state is subsequently entered, all the processors resume
operation simultaneously.
The function of
DBGACK
is to tell the rest of the system when the ARM940T is in
debug state. This can be used to inhibit peripherals such as watchdog timers that have
real time characteristics.
DBGACK
can also be used to mask out memory accesses that
are caused by the debugging process. For example, when the ARM940T 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. On exit from debug state, the pipeline must then be refilled to its
previous state. Because of the debugging process, more memory accesses occur than
normally expected. Any system peripheral that might be sensitive to the number of
memory accesses can be inhibited with
DBGACK
.
Note
DBGACK
can only be used in such a way using breakpoints. It does not mask the
correct number of memory accesses after a watchpoint.
For example, consider a peripheral that counts the number of instruction fetches. This
device must return the same answer after a program has run both with or without
debugging.