Performance Monitoring
3.6 Software Debug
3.6.5 Debug Exceptions
A debug exception causes the processor to re-direct execution to a debug event handling routine. IXP42X product line and IXC1100 control plane processors’ debug architecture defines the following debug exceptions:
• Instruction breakpoint
• Data breakpoint
• Software breakpoint
• Exception vector trap
• Trace-buffer full break
When a debug exception occurs, the processor’s actions depend on whether the debug unit is configured for Halt mode or Monitor mode.
Table 34 shows the priority of debug exceptions relative to other processor exceptions.
3.6.5.1 Halt Mode
The debugger turns on Halt mode through the JTAG interface by scanning in a value that sets the bit in DCSR. The debugger turns off Halt mode through JTAG, either by scanning in a new DCSR value or by a TRST. Processor reset does not effect the value of the Halt mode bit.
When halt mode is active, the processor uses the reset vector as the debug vector. The debug handler and exception vectors can be downloaded directly into the instruction cache, to intercept the default vectors and reset handler, or they can be resident in external memory. Downloading into the instruction cache allows a system with memory problems, or no external memory, to be debugged. Refer top “Downloading Code in ICache” on page 116 for details about downloading code into the instruction cache.
During Halt mode, software running on IXP42X product line and IXC1100 control plane processors cannot access DCSR, or any of hardware breakpoint registers, unless the processor is in Special Debug State (SDS), described below.
When a debug exception occurs during Halt mode, the processor takes the following actions:
• Disables the trace buffer
• Sets DCSR.moe encoding
• Processor enters a Special Debug State (SDS)
• For data breakpoints, trace buffer full break, and external debug break:
R14_dbg = PC of the next instruction to execute + 4
for instruction breakpoints and software breakpoints and vector traps:
R14_dbg = PC of the aborted instruction + 4
• SPSR_dbg = CPSR
• CPSR[4:0] = 0b10101 (DEBUG mode) Table 34. Event Priority
Event Priority
Reset 1
Vector Trap 2
data abort (precise) 3
data bkpt 4
data abort (imprecise) 5
external debug break, trace-buffer full 6
FIQ 7
IRQ 8
instruction breakpoint 9
pre-fetch abort 10
undef, SWI, software Bkpt 11
• CPSR[5] = 0
• CPSR[6] = 1
• CPSR[7] = 1
• PC = 0x0
Note: When the vector table is relocated (CP15 Control Register[13] = 1), the debug vector is relocated to 0xffff0000.
Following a debug exception, the processor switches to debug mode and enters SDS, which allows the following special functionality:
• All events are disabled. SWI or undefined instructions have unpredictable results.
The processor ignores pre-fetch aborts, FIQ and IRQ (SDS disables FIQ and IRQ regardless of the enable values in the CPSR). The processor reports data aborts detected during SDS by setting the Sticky Abort bit in the DCSR, but does not generate an exception (processor also sets up FSR and FAR as it normally would for a data abort).
• Normally, during halt mode, software cannot write the hardware breakpoint registers or the DCSR. However, during the SDS, software has write access to the breakpoint registers (see “HW Breakpoint Resources” on page 95) and the DCSR (see Table 33, “Debug Control and Status Register (DCSR)” on page 90).
• The IMMU is disabled. In halt mode, since the debug handler would typically be downloaded directly into the IC, it would not be appropriate to do TLB accesses or translation walks, since there may not be any external memory or if there is, the translation table or TLB may not contain a valid mapping for the debug handler code. To avoid these problems, the processor internally disables the IMMU during SDS.
• The PID is disabled for instruction fetches. This prevents fetches of the debug handler code from being remapped to a different address than where the code was downloaded.
The SDS remains in effect regardless of the processor mode. This allows the debug handler to switch to other modes, maintaining SDS functionality. Entering user mode may cause unpredictable behavior. The processor exits SDS following a CPSR restore operation.
When exiting, the debug handler should use:
This restores CPSR, turns off all of SDS functionality, and branches to the target instruction.
3.6.5.2 Monitor Mode
In monitor mode, the processor handles debug exceptions like normal ARM exceptions.
If debug functionality is enabled (DCSR[31] = 1) and the processor is in Monitor mode, debug exceptions cause either a data abort or a pre-fetch abort.
The following debug exceptions cause data aborts:
• Data breakpoint
• External debug break
• Trace-buffer full break
The following debug exceptions cause pre-fetch aborts:
subs pc, lr, #4
• Instruction breakpoint
• BKPT instruction
The processor ignores vector traps during monitor mode.
When an exception occurs in monitor mode, the processor takes the following actions:
• Disables the trace buffer
• Sets DCSR.moe encoding
• Sets FSR[9]
• R14_abt = PC of the next instruction to execute + 4 (for Data Aborts) R14_abt = PC of the faulting instruction + 4 (for Prefetch Aborts)
• SPSR_abt = CPSR
• CPSR[4:0] = 0b10111 (ABORT mode)
• CPSR[5] = 0
• CPSR[6] = unchanged
• CPSR[7] = 1
• PC = 0xc (for Prefetch Aborts), PC = 0x10 (for Data Aborts)
During abort mode, external debug breaks and trace buffer full breaks are internally pended. When the processor exits abort mode, either through a CPSR restore or a write directly to the CPSR, the pended debug breaks will immediately generate a debug exception. Any pending debug breaks are cleared out when any type of debug exception occurs.
When exiting, the debug handler should do a CPSR restore operation that branches to the next instruction to be executed in the program under debug.