Debug Interface
ARM7TDMI Data Sheet
ARM DDI 0029E
8-5
O
A breakpointed instruction may not cause ARM7TDMI to enter debug state for one of
two reasons:
a branch precedes the breakpointed instruction.
When the branch is executed, the instruction pipeline is flushed and the
breakpoint is cancelled.
an exception has occurred.
Again, the instruction pipeline is flushed and the breakpoint is cancelled.
However, the normal way to exit from an exception is to branch back to the
instruction that would have executed next. This involves refilling the pipeline,
and so the breakpoint can be re-flagged.
When a breakpointed conditional instruction reaches the execute stage of the pipeline,
the breakpoint is
always
taken and ARM7TDMI enters debug state, regardless of
whether the condition was met.
Breakpointed instructions
do not
get executed: instead, ARM7TDMI enters debug
state. Thus, when the internal state is examined, the state
before
the breakpointed
instruction is seen. Once examination is complete, the breakpoint should be removed
and program execution restarted from the previously breakpointed instruction.
Entry into debug state on watchpoint
Watchpoints occur on data accesses. A watchpoint is always taken, but the core may
not enter debug state immediately. In all cases, the current instruction will complete. If
this is a multi-word load or store (LDM or STM), many cycles may elapse before the
watchpoint is taken.
Watchpoints can be thought of as being similar to data aborts. The difference is
however that if a data abort occurs, although the instruction completes, all subsequent
changes to ARM7TDMI’s state are prevented. This allows the cause of the abort to be
cured by the abort handler, and the instruction re-executed. This is not so in the case
of a watchpoint. Here, the instruction completes and all changes to the core’s state
occur (ie load data is written into the destination registers, and base write-back
occurs). Thus the instruction does not need to be restarted.
Watchpoints are
always
taken. If an exception is pending when a watchpoint occurs,
the core enters debug state in the mode of that exception.
Entry into debug state on debug-request
ARM7TDMI may also be forced into debug state on debug request. This can be done
either through ICEBreaker programming (see
·
Chapter 9, ICEBreaker Module
), or by
the assertion of the
DBGRQ
pin. This pin is an asynchronous input and is thus
synchronised by logic inside ARM7TDMI before it takes effect. Following
synchronisation, the core will normally enter debug state at the end of the current
instruction. However, if the current instruction is a busy-waiting access to a
coprocessor, the instruction terminates and ARM7TDMI enters debug state
immediately (this is similar to the action of
nIRQ
and
nFIQ
).