Debug interface signals

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

• IEBKPT, DEWPT, and EDBGRQ. The system can use these to ask the ARM922T to enter debug state.

• DBGACK. The ARM922T uses this signal to flag back to the system when it is in debug state.

9.3.1 Entry into debug state on breakpoint

Any instruction being fetched from memory is latched at the end of phase 2. To apply a breakpoint to that instruction, the breakpoint signal must be asserted by the end of the following phase 1. This minimizes the setup time, giving the EmbeddedICE macrocell an entire phase to perform the comparison. This is shown in Figure 9-2.

Figure 9-2 Breakpoint timing GCLK

IA[31:0]

IEBKPT

DBGACK

w1

D1 E1

Edebug2 Edebug1

Ddebug

ID[31:0] 1 2 I 3 4

w2 wI

M1 W1

F1

F2 D2 E2 M2 W2

FI DI EI MI WI

Debug Support

You can build external logic, such as additional breakpoint comparators, to extend the functionality of the EmbeddedICE macrocell. You must apply the external logic output to the IEBKPT input. This signal is ORed with the internally generated breakpoint signal before being applied to the ARM922T core control logic.

A breakpointed instruction is allowed to enter the Execute stage of the pipeline, but any state change as a result of the instruction is prevented. All writes from previous instructions complete as normal.

The Decode cycle of the debug entry sequence occurs during the Execute cycle of the breakpointed instruction. The latched breakpoint signal forces the processor to start the debug sequence.

9.3.2 Breakpoints and exceptions

A breakpointed instruction might have a Prefetch Abort associated with it. If so, the Prefetch Abort takes priority and the breakpoint is ignored. (If there is a Prefetch Abort, instruction data might be invalid, the breakpoint might have been data-dependent, and as the data might be incorrect, the breakpoint might have been triggered incorrectly.) SWI and undefined instructions are treated in the same way as any other instruction that might have a breakpoint set on it. Therefore, the breakpoint takes priority over the SWI or undefined instruction.

On an instruction boundary, if there is a breakpointed instruction and an interrupt (IRQ or FIQ), the interrupt is taken and the breakpointed instruction is discarded. When the interrupt has been serviced, the execution flow is returned to the original program.

This means that the instruction that has been breakpointed is fetched again, and if the breakpoint is still set, the processor enters debug state when it reaches the Execute stage of the pipeline.

When the processor has entered debug state, it is important that additional interrupts do not affect the instructions executed. For this reason, as soon as the processor enters debug state, interrupts are disabled, although the state of the I and F bits in the Program Status Register (PSR) are not affected.

Debug Support

9.3.3 Watchpoints

Entry into debug state following a watchpointed memory access is imprecise. This is necessary because of the nature of the pipeline and the timing of the watchpoint signal.

After a watchpointed access, the next instruction in the processor pipeline is always allowed to complete execution. Where this instruction is a single-cycle data-processing instruction, entry into debug state is delayed for one cycle while the instruction completes. The timing of debug entry following a watchpointed load in this case is shown in Figure 9-3 on page 9-8.

Note

Although instruction 5 enters the Execute state, it is not executed, and there is no state update as a result of this instruction. When the debugging session is complete, normal continuation involves a return to instruction 5, the next instruction in the code sequence to be executed.

The instruction following the instruction that generated the watchpoint might have modified the Program Counter (PC). If this happens, it is not possible to determine the instruction that caused the watchpoint. A timing diagram showing debug entry after a watchpoint where the next instruction is a branch is shown in Figure 9-4 on page 9-9.

However, you can always restart the processor.

When the processor has entered debug state, the ARM922T core can be interrogated to determine its state. In the case of a watchpoint, the PC contains a value that is five instructions on from the address of the next instruction to be executed. Therefore, if on entry to debug state, in ARM state, the instruction SUB PC, PC, #20 is scanned in and the processor restarted, execution flow returns to the next instruction in the code sequence.

Debug Support

Figure 9-3 Watchpoint entry with data processing instruction

DD[31:0]

GCLK

InMREQ

ID[31:0]

DA[31:0]

1 2 LDR Dp 5 6 7 8

DDIN[31:0]

Watchpoint

DBGACK

E1

F1 D1 M1 W1

D2

F2 E2 M2

ELDR

FLDR DLDR MLDR WLDR

DDp

FDp EDp MDp

E5

F5 D5 M5 W5

W2

WDp

Ddebug Edebug1 Edebug2

wLDR

w1 w2 wDp w5 w6

Debug Support

Figure 9-4 Watchpoint entry with branch

9.3.4 Watchpoints and exceptions

If there is an abort in the data access together with a watchpoint, the watchpoint condition is latched, the exception entry sequence performed, and then the processor enters debug state. If there is an interrupt pending, again the ARM922T processor allows the exception entry sequence to occur and then enters debug state.

DD[31:0]

GCLK

InMREQ

IA[31:1]

DA[31:0]

A+4 T T+8

DDIN[31:0]

Watchpoint

DBGACK

ELDR

FLDR DLDR MLDR WLDR

DB

FB EB MB

FT DT ET

Ddebug WB

Edebug1

A A+8 T+4 T+C

ID[31:0] LDR B X X T T+1 T+2 T+3

Edebug2

Debug Support

9.3.5 Debug request

A debug request can take place through the EmbeddedICE macrocell or by asserting the EDBGRQ signal. The request is synchronized and passed to the processor. Debug request takes priority over any pending interrupt. Following synchronization, the core enters debug state when the instruction at the Execute stage of the pipeline has completely finished executing (when Memory and Write stages of the pipeline have completed).

While waiting for the instruction to finish executing, no more instructions are issued to the Execute stage of the pipeline.

9.3.6 Actions of the ARM922T in debug state

When the ARM922T is in debug state, both memory interfaces indicate internal cycles.

This allows the rest of the memory system to ignore the ARM9TDMI core and function as normal. Because the rest of the system continues operation, the ARM9TDMI core ignores aborts and interrupts.

The BIGEND signal must not be changed by the system while in debug state. If it changes there might be a synchronization problem, and the ARM922T processor (as seen by the programmer) changes without the knowledge of the debugger. The BnRES signal must also be held stable during debug. If the system applies reset to the ARM922T processor (BnRES is driven LOW), the state of the ARM922T changes without the knowledge of the debugger.

When instructions are executed in debug state, the ARM9TDMI core changes asynchronously to the memory system outputs (except for InMREQ, ISEQ,

DnMREQ, and DSEQ that change synchronously from GCLK). For example, every time a new instruction is scanned into the pipeline, the instruction address bus changes.

If the instruction is a load or store operation, the data address bus changes as the instruction executes. Although this is asynchronous, it does not affect the system, because both interfaces indicate internal cycles. You must take care when designing the memory controller to ensure that this does not become a problem.

Debug Support