The debug subsystem in ARM processors provides hardware support for debugging code running on the processor. It allows external debug tools to halt execution, examine processor state like registers and memory, set breakpoints, and more. The key components of the ARM debug subsystem are:
Debug Access Port (DAP)
The Debug Access Port (DAP) provides the interface for an external debugger to access the processor’s debug features. The DAP has several registers that can be used to halt/resume execution, access processor registers, set breakpoints, and more. It uses the JTAG interface standard so external JTAG debug probes can connect to it.
Breakpoints
ARM processors support different types of breakpoints through its debug hardware:)
- Software breakpoints – The processor can be halted when it executes a particular instruction address.
- Watchpoints – Watchpoints can be set on data addresses to halt the processor when they are read from or written to.
- Exception breakpoints – These cause a debug halt when a particular exception or fault occurs.
The breakpoints are managed through the DAP debug registers. Multiple breakpoints of each type are supported.
Debug Exception and Monitor Mode
When a breakpoint or watchpoint triggers, the ARM core will enter debug state. This causes it to jump to Monitor mode, a special privileged mode for debugging, and take the debug exception. Monitor mode has access to all system resources needed for debugging like register access. The debugger communicates with Monitor mode through the DAP to control execution and read processor state.
Embedded Cross Trigger Interface
In multicore ARM systems, the embedded cross trigger interface allows coordination between multiple connected cores. Trigger events can be propagated between different CPUs using this. For example, a breakpoint hit on one core can be configured to halt execution on other cores as well.
Trace Flow
The ARM trace flow hardware collects a stream of trace data from the processor as it executes instructions. This can record things like program flow, performance counters, timestamp information, etc. Trace data is output through the DAP and allows more detailed debugging and profiling of code.
Debug Authentication
For security reasons, the ARM debug components have authentication support. This allowsdebug access to be restricted only to authorized users. Authentication can cover both debug register access through the DAP and trace information capture.
CoreSight Components
ARM CoreSight is a set of standards that define useful debug components like trace encoder, trace decoder, debug bus master, etc. ARM processors include some of these components to augment their debug capabilities. For example, a CoreSight program trace macrocell can provide instruction trace information to the DAP.
Summary
In summary, the key aspects of the ARM debug subsystem are:
- Debug Access Port interface for debugger connection.
- Breakpoints, watchpoints and exceptions to control program execution.
- Monitor mode to handle debug exceptions.
- Multicore cross triggering.
- Trace flow hardware for logging debug data.
- Debug authentication for security.
- CoreSight components to enhance debugging.
This comprehensive debug support allows powerful real-time debugging and profiling on ARM processors. Both software tools and hardware probes can connect to the subsystem to analyze system state and software behavior during execution. The flexible DAP and breakpoint architecture offer non-intrusive and robust debugging. Trace capabilities enable inspection of dynamic program flow. And the multicore triggering allows synchronized debugging across multiple CPUs.
Using the Debug Subsystem
For programmers working on ARM, utilizing the debug subsystem during development can greatly help accelerate coding and testing. Some common use-cases are:
Debugger Integration
Tools like GDB can connect to the DAP interface to enable run-control and breakpoint debugging right within the normal coding workflow. IDEs like Eclipse, Visual Studio Code, etc. provide front-ends to integrate this debugger connection.
Validating Code Changes
Setting breakpoints and examining program state when they are hit is a fast way to validate code changes. The debugger can step through execution flow statement-by-statement to home in on any issues.
Analyzing Memory Corruption
Memory watchpoints allow tracking unauthorized memory accesses that could cause corruption. If an area of memory is hit unexpectedly, the debugger can halt the system to analyze the situation.
Tracing Execution Flow
Trace data gives insight into code hotspots, branching behavior, stalls, and function calls/returns. This helps optimize performance or identify anomalies.
Profiling and Statistics
The trace macros can record timing data, performance counters, and other statistics as code executes. This profiling information enables optimization of slow code areas.
Checking Interrupt Latency
Measuring the time from an interrupt trigger to the handler code executing provides valuable latency data that impacts real-time performance.
Analyzing Multicore Interactions
Using cross-triggers, a developer can debug issues arising from interactions between multiple CPUs working together.
The ARM debug subsystem enables all these use cases and more. Proper utilization of its powerful hardware capabilities can greatly boost debugging productivity during embedded software development.
How Debug Subsystem Works Internally
Under the hood, the ARM debug subsystem relies on a few key mechanisms to enable non-intrusive debugging:
Debug State
Executing the DMCR instruction via the DAP causes the processor to enter debug state. This halts normal execution and gates the clocks to hold the core in its current state. Debug logic remains active.
Monitor Mode
The core switches to Monitor mode privilege when in debug state. This allows full access to system resources needed for debugging. The PC also jumps to the debug exception vector.
Debug Context Saving
On debug entry, the core’s general purpose registers, special registers and CP15 context are saved by hardware to System mode memory. This preserves the processor state for inspection.
DAP Debug Register Access
In Monitor mode, the JTAG DAP interface provides access to the breakpoints, watchpoints, and other debug control registers. These facilitate examining and modifying state.
Instruction Stepping
The step-over and step-into instructions use debug hardware to increment the PC by one instruction and re-enter debug state. This enables single stepping through code execution.
Exit and Resume
The DAP debug registers are used to exit debug state, restoring the saved context and resuming normal execution at the point it left off.
This behind-the-scenes workflow is what enables non-invasive inspection and control of processor state for debugging purposes.
Debug Subsystem Hardware Blocks
The ARM debug subsystem encompasses several hardware blocks integrated into the SoC design. These work together to enable the debug capabilities discussed earlier.
Debug Access Port (DAP)
The DAP is the interface block that a debugger uses to communicate with the debug subsystem. It exposes registers to control debug features and processor state.
Debug Communications Channel (DCC)
The DCC provides a message passing mechanism for communicating small packets of data between the external debugger and the target processor.
Breakpoint Control Unit
This unit contains the breakpoint and watchpoint registers that configure debug break events and their handling.
Debug Power and Reset Control
Power and reset control logic manages the debug components’ power states and resets.
Cross Trigger Interface (CTI)
The CTI implements the cross-trigger matrix between multiple processors for coordinated debugging.
Instrumentation Trace Macrocell (ITM)
ITM provides the processor-driven trace data output capabilities, sending trace data to the DAP.
Embedded Trace Macrocell (ETM)
ETM implements instruction trace capabilities for data like program flow tracing and timing information.
These blocks and more work in conjunction to give ARM processors advanced integrated debug capabilities with minimal overhead or intrusion.
Conclusion
In summary, the ARM debug subsystem provides a versatile set of hardware-based debugging features for embedded software development. Its debug access port and extensive breakpoint support enable powerful control over program execution. Monitor mode grants full system access when debugging. Multicore cross triggering allows coordinated debugging. And trace capabilities facilitate detailed profiling. Together, these capabilities allow ARM developers to debug even the most complex systems and software interactions quickly and efficiently.
