Home
CoreSight SoC-600 provides features that allow platforms to implement Debug and Trace functionality over a "Functional I/O" interface (as opposed to JTAG/SWD, HSSTP or other traditional debug and trace interfaces).
This allows high-speed functional interfaces (e.g. Ethernet, USB, PCIe, etc) that are already in the SoC to provide debug and trace. The debug and trace data can then be consumed by a host, e.g. a common PC (without the use of a traditional debug/trace probe), or by other specialized debug/trace hardware.
The Coresight SoC-600 describes, as part of Arm Debug Interface Version 6 (ADIv6), a revised Debug Access Port (DAP) architecture. A memory mapped Access Port (AP) which can provide debug facilities can be accessed by a PE.
CoreSight SoC-600 also describes a new CoreSight ETR (Embedded Trace Router) mode that can be used for streaming trace. An ETR can use RAM on the platform as a trace buffer. It can issue a hardware interrupt on a certain buffer fill level, which is processed by a PE (Processing Element) to transmit trace over the Functional I/O.
The platform to be debugged (the "target") will provide functionality to read/write data from a given AP, process ETR interrupts, send/recv data over a functional I/O. Such a platform needs to:
- Bring up and maintain a functional I/O link to a host
- Service debug requests from host (halting debug and configure CoreSight trace components and devices)
- Collect trace data from an ETR and send it to a host
- Provide driver support for ETR and the functional I/O interface
- Run and manage any debug/trace "agent" software independently from the host
Optionally, the platform can provide a System Description File (SDF), which contains information about its CoreSight topology and the addresses of CoreSight components.
The debug agent software can run either on the same processor that is under test, or in a separate, dedicated processor.
When running on the same processor, the agent:
- Accesses CoreSight components via a driver, or as memory mapped registers
- Does not need extra hardware
- Cannot provide halting debug
- Has an effect on the system under test (execution overhead and shared bandwidth on the functional I/O interface)
- Needs an OS with driver support
- Can collect samples of trace of specific OS processes
When running on a separate, dedicated processor, the agent:
- Does not have an effect on the system under test
- Does not need a driver for CoreSight access
- Enables halting debug and trace from boot
- Can be used for OS bring up on another processor
- Uses a separate link to host (no bandwidth contention, needs extra hardware)
Coresight Wire Protocol (CSWP) is a defined command-response protocol between the host and the target debug agent. It is transport neutral and a reference C library for decoding and encoding commands and responses is provided in this package. The CSWP specification is available in this package, under cswp/doc.
On the host side, the following components need to be provided:
- Debug interface via a subset of RDDI Config and RDDI MEM-AP APIs
- CSWP client layer
- Functional I/O client transport layer
On the target side:
- Debug agent with CoreSight access
- CSWP server layer
- Functional I/O drivers and server transport layers
On the host side:
- Trace interface via the RDDI streaming trace API
- Functional I/O client transport layer and/or driver
On the target side:
- ETR driver that configures ETR and processes interrupts
- Functional I/O server transport layer
Arm Development Studio (ArmDS) provides support to add, manage, debug and decode trace from platforms over a functional I/O interface, via its Debug Probe API integration.
Once a new debug/trace probe implementation has been added to a Configuration Database in ArmDS, the probe definition file (probes.xml) can be edited to specify the location of RDDI library implementations and additional configuration files.
The README in this repository and the following links can provide further guidance: