The ARM Debug Interface v5 Architecture Specification defines a standard debug interface between ARM processor cores and external debuggers. This standard interface allows debuggers to more easily support multiple ARM processor cores without needing core-specific knowledge. The v5 debug architecture improves upon earlier versions by adding features for more advanced debugging while retaining backwards compatibility.
Overview
The ARM Debug Interface aims to provide a standard way for external debuggers to access information from ARM cores. This removes the need for debugger creators to understand the intricacies of each core’s internal implementation. The interface abstracts core internals into a consistent model. Debugger creators can then target this standardized model rather than individual cores.
The v5 architecture builds upon the earlier v4 architecture. It extends v4’s basic debug capabilities with new features for more advanced debugging. At the same time, v5 retains compatibility with v4. This allows debuggers supporting v5 to also work with older ARM cores implementing v4 or earlier versions.
Debug Access Port
The Debug Access Port (DAP) provides the interface between the ARM core and an external debugger. The DAP has two key components:
- The Debug Port (DP) handles communications and data transfers with the debugger.
- The Access Port (AP) provides access to core internal state.
Having separate components for communication and core access makes the interface more modular. The DP acts as the communication hub while the AP provides an abstraction layer for accessing core data.
Debug Port
The Debug Port (DP) module handles low-level communication with the external debugger through the physical debug interface. It provides access to APs and other debug components through a request-response protocol. The DP contains a small set of registers debuggers use to initiate requests and receive responses.
The DP handles the details of communicating over the physical interface protocol. This isolates APs and other components from these link-level details. It provides a consistent method for communication regardless of the type of debug interface (JTAG, SWD, etc).
Access Port
Access Ports (APs) provide access to internal core state based on abstract functional groupings. Different types of APs exist for different kinds of data:
- The Memory AP provides access to memory and registers.
- The Trace AP provides access to tracing data.
- The Debug AP provides miscellaneous debug control and status information.
APs contain sets of registers that a debugger can access to view or control different parts of core internal state. Which registers an AP contains depends on its type and functionality.
Debug Resources
In addition to the DAP, a debug target contains various other debug resources that a debugger may access. These include:
- Breakpoint registers – Configure instruction and data breakpoints.
- Watchpoint registers – Configure watchpoints to trigger on data accesses.
- OS Lock registers – Allow the OS to lock debug registers.
- Device power control – Enable debugger power control requests.
A debug target may contain multiple instances of a given resource type. For example, it might have several breakpoint registers to support multiple simultaneous breakpoints. The number of resources is implementation-defined.
Debug Instructions
ARMv5 defines some special debug instructions that software can execute for debugging purposes:
- BKPT – Causes a breakpoint exception to enter debug state.
- DBG – Enters debug state unconditionally.
- DSB – Debug barrier instruction to ensure completion of debug operations.
- DMB – Debug memory barrier instruction to order memory accesses.
These augment the normal ARM instruction set to provide additional debugging functionality. A debugger can leverage these special instructions along with the debug registers to fully control software execution.
Debug State
When a breakpoint or watchpoint triggers, the ARM core enters debug state. This pauses normal execution and grants control to the debugger. In debug state, the debugger can access all core internal state through the DAP. It can examine and modify register contents, memory, and other state information.
To start execution again, the debugger simply releases debug state. This transitions back to normal operational state, resuming where the core left off. Debug exceptions are essentially transparent software interrupts that give the debugger an opportunity to inspect and alter state.
Debug Communications
The Debug Interface supports several standard physical links for communication between the core and debugger:
- JTAG – Standard IEEE 1149.1 Test Access Port (TAP) interface.
- SWD – Serial Wire Debug provides a 2-pin alternative to JTAG.
- SWO – Single Wire Output provides unidirectional trace data output.
JTAG is the traditional debug interface supported in early ARM cores. SWD and SWO provide more modern and efficient options. SWD uses only two bidirectional data wires, while SWO outputs trace data over a single pin.
Trace Support
The v5 debug architecture introduces standard support for instruction and data tracing. Trace involves recording a log of instructions executed and/or data accesses made during normal execution. This provides valuable information for understanding program flow and optimizing performance.
A debugger can retrieve trace data by accessing the Embedded Trace Macrocell (ETM) through the Trace AP. The ETM is a specialized debug component that handles capturing trace information. It can record traces to an on-chip buffer or export them externally through SWO.
Debug Configurations
The v5 architecture defines several classes of debug configuration that an implementation may support:
- Minimal debug – Basic debug capability with limited numbers of breakpoints.
- Full debug – Extensive debug support with additional debug resources.
- Microcontroller debug – Debugging optimized for microcontroller environments.
- Run-control debug – Debugging optimized for complex operating environments.
Higher classes add more debug resources and capabilities. Which classes a given core supports depends on its design optimization. Cores meant for embedded microcontrollers might only support minimal or microcontroller debug. More complex application processors likely support full or run-control configurations.
Debug Security
The debug interface allows extensive access to sensitive core state. This raises security concerns when debugging deployed systems remotely. Arm offers various technologies to mitigate debug security risks:
- CoreSight lock – Locks key debug components until unlock sequence is provided.
- Arm TrustZone – Isolates secure debug sessions within secure world exception level.
- Arm CoreLink DAP – Authenticates external debug tools through layered security.
Using these technologies, organizations can reduce risks and debug fielded systems safely. This enables critical capabilities like software updates and failure analysis in remote or sensitive contexts.
Conclusion
The ARM Debug Interface v5 Architecture Specification propels debug capabilities forward while retaining backwards compatibility. It introduces major new functionality like instruction tracing while building on the solid foundation of earlier debug architectures. Moving forward, ARM aims to continue improving the debug experience on ARM-based systems.
