The ARM Debug Interface Architecture (DIA) specification defines a standard debugging interface between debug agents and ARM processor cores. This allows debug agents from various vendors to connect to and debug ARM cores without needing core-specific knowledge. The DIA provides a consistent method for accessing debug features like breakpoints, watchpoints, and register access across ARM cores.
Overview of ARM Debug Interface Architecture
The key components of the ARM DIA include:
- Debug Access Port (DAP): The DAP provides the connection between the debug agent and the target system. It has a standard set of register accesses that allow discovery and initialization of the debug target.
- Access Link: The link between the DAP and the ARM core(s). Handles data transfer and flow control.
- Debug Port (DP): Acts as the connection point on the ARM core to receive debug requests and data from the DAP.
- Breakpoint (BP) and Watchpoint (WP) Units: Hardware modules that support breakpoints for instruction fetches and watchpoints for data accesses.
- Debug Registers: Registers used for configuration, control and status reporting of debugging functions.
The DAP abstracts the details of the physical debug connection (JTAG, SWD, etc), while the DP and associated units provide a standard way to access the debug capabilities of ARM cores. The debug agent can use memory-mapped reads/writes to the DAP to discover, initialize and access debug resources on the target system.
Debug Access Port (DAP)
The Debug Access Port (DAP) handles the low-level details of the physical debug interface protocol. It provides a set of memory-mapped registers that the debug agent can access to discover, initialize and communicate with the target system. The DAP supports both JTAG and SWD as transport mechanisms.
Key capabilities provided by the DAP include:
- Interface identification and capabilities discovery
- Target device identification
- Managing resets and power modes
- Accessing AP/DP registers on target system
- Handling async events from target
The DAP has two primary interfaces – the Debug Port Interface (DPI) which connects to the target system, and the Host Interface (HI) which connects to the debug host. Communication and synchronization between the two interfaces is handled internally by the DAP.
DAP Registers
Some key DAP registers include:
- IDCODE – Provides information about DAP capabilities
- ABORT – Generates a debug abort on the target
- CTRL/STAT – Controls DAP state machine and checks status
- SELECT – Selects between AP/DP interfaces on target
- RDBUFF – Read buffer for data from AP/DP
These registers allow the debug agent to query the DAP, initiate target operations, and transfer data to/from the target system.
Access Link
The Access Link provides the connection between the DAP and ARM core(s) in the target system. It is responsible for:
- Data transfers between DAP and DP
- Handling differing bus widths between DAP and DP
- Inserting wait states if DAP and DP operate at different speeds
The Access Link uses a simple request/acknowledge handshake mechanism for data transfers. It also includes a Debug Access Port Access Control Register (DAPACR) that can be configured to provide some protection against unintentional or unauthorized accesses.
Debug Port (DP)
The Debug Port acts as the connection point on the ARM core to receive debug requests and data from the DAP. It has a set of registers that can be accessed by the DAP to control and monitor debug operations.
Key capabilities provided by the DP include:
- Breakpoint and watchpoint configuration
- Access to core and special registers
- Debug control and status reporting
Accesses to the DP registers are used to setup and control debugging on a core as well as extract debug-related information from the core.
DP Registers
Some key DP registers include:
- CTRL/STAT – Controls DP operation and checks status
- SELECT – Selects between the AP/DP interfaces
- RDBUFF – Read buffer for data from AP/DP
- BPCTRL – Controls number of breakpoints
- BP0 – BP3 – Breakpoint address and control
These registers allow the debug agent to initialize the DP, configure breakpoints, and access registers/memory on the core.
Breakpoint Unit
The Breakpoint (BP) Unit is responsible for implementing breakpoints – halting core execution when a particular instruction address matches a defined value. It compares instruction addresses generated on the core against breakpoint addresses configured by the debug agent.
Key capabilities of the BP unit include:
- Support for multiple hardware breakpoints
- Breakpoint matching on instruction fetch addresses
- Ability to link breakpoints to trigger other actions
The number of breakpoints supported is implementation-defined. Breakpoint addresses, matching control, and actions are configured via the DP registers exposed to the DAP.
Breakpoint Types
The ARM DIA supports different types of breakpoints including:
- Address Breakpoints – Break on access to a specific instruction address
- Context Breakpoints – Break only within a given context ID
- VMID Breakpoints – Break only within a given VMID
This provides flexibility to target breakpoints by various criteria.
Watchpoint Unit
The Watchpoint (WP) Unit is responsible for implementing watchpoints – halting core execution when a data access matches defined address, size and access type values. It compares data addresses generated on the core against watchpoint addresses configured by the debug agent.
Key capabilities of the WP unit include:
- Support for multiple hardware watchpoints
- Watchpoint matching on data access addresses and attributes
- Ability to link watchpoints to trigger other actions
The number of watchpoints supported is implementation-defined. Watchpoint configuration and actions are controlled via DP registers.
Watchpoint Types
The ARM DIA supports different types of watchpoints including:
- Address Watchpoints – Break on access to a data address range
- Context Watchpoints – Break only within a given context ID
- VMID Watchpoints – Break only within a given VMID
Watchpoints can further be targeted to specific access sizes and types e.g. only 8-bit writes.
Debugging Arm Cores
To debug an ARM core, the debug agent connects to the DAP interface and discovers the target topology and capabilities. It can then initialize the DP and use DP register accesses to:
- Setup breakpoints and watchpoints
- Read/write core registers for analysis
- Halt and resume execution
- Single-step instructions
- Read memory areas
The breakpoint and watchpoint units generate debug events that halt core execution and allow inspection of the system state. The debug agent leverages these capabilities to control execution flow and extract debug information.
Debug Interface Example
Here is a simplified example of how a debug agent might interact with the ARM DIA to debug code running on an ARM core:
- Connect to DAP using SWD and read ID register to verify interface
- Discover DP and associated debug resources using DAP register accesses
- Initialize DP and configure 2 breakpoints via DP accesses
- Enable debug on core by setting DP CTRL/STAT register
- Run code on core until a breakpoint triggers
- Halt core and read registers, memory to inspect state
- Single-step instructions while monitoring state
- Repeat 4-7 to debug code execution
This demonstrates how the standardized DAP and DP interfaces enable a debug agent to control and inspect ARM core execution without needing core-specific knowledge.
Summary
The ARM Debug Interface Architecture provides a standardized way for tools to access debug capabilities across ARM cores. The DAP abstracts the debug connection while the DP provides consistent access to core-specific resources. This enables robust and unified debugging of various ARM processors by different debug agents.
Key features of the ARM DIA include:
- Discovery and initialization via DAP registers
- Breakpoint and watchpoint configuration using DP
- Processor control through DP debug control and single-step
- Register, memory and state inspection
By leveraging the ARM DIA, tool vendors can create sophisticated debuggers, tracers and analysis tools that work seamlessly across the spectrum of ARM cores.
