Table of Contents
Advertisement
Debug Support
5.11
Exit from debug state
5-32
Leaving debug state involves restoring the internal state of the ARM9TDMI, 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 5-35.
Bit 33 of scan chain 1 is used to force the ARM9TDMI to resynchronize back to
GCLK. 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 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
instruction into the pipeline. Now, the RESTART instruction is selected in the TAP
controller. When the state machine enters the RUN-TEST/IDLE state, the scan chain
will revert back to system mode and clock resynchronization to GCLK will occur
within the ARM9TDMI. Normal operation will then resume, 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.
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 is in
debug state. This can be used to inhibit peripherals such as watchdog timers that have
real time characteristics. Also, DBGACK can be used 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 which 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 would normally be expected. Any system peripheral that may be
sensitive to the number of memory accesses can be inhibited through the use of
DBGACK.
Note
DBGACK can only be used in such a way using breakpoints. It will 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 should return the same answer after a program has run both with and
without debugging. Figure 5-7 on page 5-33 shows the behavior of the ARM9TDMI on
exit from debug state.
Copyright © 1998, 1999 ARM Limited. All rights reserved.
), with bit 33 set HIGH. The core is then clocked to load this
ARM DDI0145B
Advertisement
Table of Contents
