A few days ago, I saw the news that ARM launched the CoreSight SoC-600, achieving the next generation of debugging and tracing. What is the next generation? Now you can throw away the JTAG cables and debug and trace your SoC directly via WiFi, CAN Bus, Ethernet, or USB. Sounds promising, right?
However, many people may not be very clear about what CoreSight actually is. No worries, I have gathered a lot of information to learn about it, and perhaps by the end, you will understand it too.
Let’s explore it using the traditional 3W learning method:
WHY: Why It Is Needed
First, from the name, we can infer: it’s just to see what the core is doing!
Of course, this is just my casual way of speaking. According to ARM’s official information, CoreSight mainly implements two functions: Debug and Trace.
This is not unfamiliar to embedded engineers; it’s about debugging and tracing the kernel.
In the early days, external instruments could measure the data and instruction flow during processor debugging. However, with the wide application of SoCs and the extensive use of on-chip caches, external instruments became unable to monitor the situation. Therefore, processor manufacturers provided trace functionalities on the hardware chip, which non-invasively records the program execution path and data read/write information in real-time via proprietary hardware, compressing it into a trace data stream that is transmitted to the debug host through dedicated data channels and output ports (the innovation of the SoC-600 mainly targets this area). The development tools in the debug host decompress these trace data streams, restoring program execution information for debugging and performance analysis.
CoreSight can help users achieve four main functions: SoC tuning, software debugging, system configuration, and post-mortem analysis.
Besides ARM, other companies will also launch such trace technology products. However, for our readers, CoreSight should hold the most significance, right? (We can explore niche ones later.)
WHAT: What Is It
You can refer to CoreSight as a technology, a piece of hardware, or a system-level IP (this should be the most accurate). It is a new debugging architecture introduced by ARM in 2004.
The image below is a diagram about CoreSight taken from the ARM official website. The components ETM, PMU, CTM, TPIU, STM, TMC, and Timestamp all belong to CoreSight; their functions are also indicated above.
It may seem a bit overwhelming, but in summary, CoreSight’s debugging structure can be divided into three main parts: Source, Link, and Sink.
Source refers to the source components that generate tracking data sent to the ATB (AMBA Trace Bus), usually through the APB bus.
For example, STM and ETM belong to the Source part.
STM (System Trace Macrocell): Used to obtain system tracing information.
ETM (Embedded Trace Macrocell): Used to obtain tracing information from the processor core.
Sink refers to access control components that configure and control the generation of data streams without producing data streams. These are modules that can hold the data coming from the source.
For example, DAP and ECT belong to the Sink part.
DAP (Debug Access Port): Allows real-time access to system memory, peripheral registers, and all debug configuration registers on the AMBA bus without suspending the system.
ECT (Embedded Cross Trigger): Includes CTI (Cross Trigger Interface) and CTM (Cross Trigger Matrix), providing interfaces for ETM to transmit debugging events from one processor to another.
Link refers to the endpoint for tracking data on the chip. It is used to guide the flow of data from source to sink, acting like a channel.
For example, TPIU, ETB, and SWO all belong to the Link part.
TPIU (Trace Port Interface Unit): Assembles information from various on-chip trace data sources into TPIU frame format and transmits it to the outside via the Trace Port.
ETB (Embedded Trace Buffer): A 32-bit RAM that serves as an on-chip trace information buffer.
SWO (Serial Wire Output): Similar to TPIU but only outputs tracing information from the ITM unit, requiring just one pin.
How: DS5
The image above shows a typical CoreSight debugging structure, which has been mentioned earlier, so I won’t elaborate on it here. This section mainly explains how to implement it in software. Developers can use ARM DS Development Tools to achieve CoreSight debugging and tracing, or choose from over 25 third-party development tools.
Among them, DS-5 is the latest version, which mainly includes three components: programming tools, debugging tools, and pipeline analysis tools. The DS-5 debugger combines the convenience of integrated microcontroller tools with high productivity and the powerful functionality and flexibility of open-source tools for Linux. Its Eclipse-based GUI simplifies the complex task of managing different target connection types, providing various ways to debug software at the bootloader, kernel, and application levels. Additionally, its command-line interface similar to GDB adds quick control and scripting capabilities for professional Linux users.
Due to space constraints, I will only briefly describe how to use the CoreSight trace function from the perspective of tracing, believing that you can gain a glimpse of the whole picture.
Non-Intrusive Tracing
When debugging software, in many cases, the negative effects of errors are obvious, but the root causes of such errors may have existed long before the program execution. The ARM CoreSight ETM and PTM supported by the DS-5 debugger provide non-intrusive program tracing, allowing developers to view explanations (and associated source code) when errors occur. It also enables developers to debug time-sensitive issues that would be difficult to detect using traditional intrusive step techniques. The DS-5 debugger currently uses DSTREAM to capture traces on the ETB. Support for the 4 GB external trace buffer installed in this debug and trace probe has also been added.
Flexible tracing display is valuable for debugging and short-term performance analysis. However, very few developers can cope with the long list of executed machine instructions. In DS-5, great emphasis is placed on presenting this data in high-level languages that developers can easily process meaningfully, such as linking instructions to corresponding source code, displaying function-level trace analysis, or providing graphical trace displays.
Based on trace data, the DS-5 debugger generates timeline charts containing information that helps developers quickly understand how their software executes on the target and which functions consume the most CPU. By providing different zoom levels, the timeline can display hotspots at its highest resolution based on the number of instructions per time unit and provide a per-instruction display color-coded by typical latency times for each group of instructions.
