Debug Interface Signals

There are three primary external signals associated with the debug interface:

•BREAKPT and DBGRQ

with which the system requests ARM7TDMI to enter debug state.

•DBGACK

which ARM7TDMI uses to flag back to the system that it is in debug state.

Entry into debug state

ARM7TDMI is forced into debug state after a breakpoint, watchpoint or debug-request has occurred.

Conditions under which a breakpoint or watchpoint occur can be programmed using ICEBreaker. Alternatively, exter-

Figure 76. Debug State Entry

Debug

nal logic can monitor the address and data bus, and flag breakpoints and watchpoints via the BREAKPT pin.

The timing is the same for externally generated breakpoints and watchpoints. Data must always be valid around the falling edge of MCLK. If this data is an instruction to be breakpointed, the BREAKPT signal must be HIGH around the next rising edge of MCLK. Similarly, if the data is for a load or store, this can be marked as watchpointed by asserting BREAKPT around the next rising edge of MCLK.

When a breakpoint or watchpoint is generated, there may be a delay before ARM7TDMI enters debug state. When it does, the DBGACK signal is asserted in the HIGH phase of MCLK. The timing for an externally generated breakpoint is shown in Figure 76.

Internal Cycles

Entry into debug state on breakpoint

After an instruction has been breakpointed, the core does not enter debug state immediately. Instructions are marked as being breakpointed as they enter ARM7TDMI’s instruction pipeline.

Thus ARM7TDMI only enters debug state when (and if) the instruction reaches the pipeline’s execute stage.

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

141

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 “ICEBreaker Module” on page 163) or be 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).

Action of ARM7TDMI in debug state

Once ARM7TDMI is in debug state, nMREQ and SEQ are forced to indicate internal cycles. This allows the rest of the memory system to ignore ARM7TDMI and function as normal. Since the rest of the system continues operation, ARM7TDMI must be forced to ignore aborts and interrupts.

The BIGEND signal should not be changed by the system during debug. If it changes, not only will there be a synchronisation problem, but the programmer’s view of ARM7TDMI will change without the debugger’s knowledge. nRESET must also be held stable during debug. If the system applies reset to ARM7TDMI (ie. nRESET is driven LOW) then ARM7TDMI’s state will change without the debugger’s knowledge.

The BL[3:0] signals must remain HIGH while ARM7TDMI is clocked by DCLK in debug state to ensure all of the data in the scan cells is correctly latched by the internal logic.

When instructions ar e executed in debug state, ARM7TDMI outputs (except nMREQ and SEQ) will change asynchronously to the memory system. For example, every time a new instruction is scanned into the pipeline, the address bus will change. Although this is asynchronous it should not affect the system, since nMREQ and SEQ are forced to indicate internal cycles regardless of what the rest of ARM7TDMI is doing. The memory controller must be designed to ensure that this asynchronous behaviour does not affect the rest of the system.