ETM traces and STM traces

Question

Need to understand the difference between STM traces and ETM traces ? Also want to get understand about source, sink, link in coresight device?

Please share any links/blogs for these queries

Answer 1

There is an introductory 'CoreSight Technical Introduction', but this is more aimed at providing some context to SoC designers. However, I can try and provide some developer focused information here.

STM or ITM are both software driven trace sources (in effect, an optimised/dedicated UART). In Cortex-M, there is an extra layer of hardware trace which does some way to compensating for the absence of performance monitor counters in the smaller parts. Access to the STM can be fairly fast, and software can dump a raw payload to a specific channel. This is a lower overhead than a UART (and the bandwidth should be arranged to permit streamiung writes without worrying about handshaking. Capture for this trace is often built into low end tools.

ETM is quite a lot more sophisticated. It provides a non-invasive view of the program execution stream, in real time. Except for Cortex-R, this is generally the instruction stream only, and the stream is heavily compressed. Depending on the device, there may be an option to include timing information in the stream. ETM trace is used for profiling, code coverage, and diagnosing hard problems or race conditions (since the sequence of taken exceptions, etc, is explicit.)

ETMs also have triggering logic to help narrow down capture to specific sequences of interest.

CoreSight is an architecture and a set of components for implementing trace/debug. In this terminology, STM and ETM are trace sources. They stream trace data in a byte-based protocol over a wide bus. The chalenge is extracting this data off chip. Data can either be stored in a buffer, and read out over a debug interface later, or streamed in real time. The small Cortex-M devices often have a 4 bit trace port, this needs to run at least at half the core frequency to be able to keep up. Capture hardware for the basic 4/8/16/32 bit trace ports is non-trivial since they typically operate at high frequencies.

In CoreSight terminology, the trace sink is an endpoint which stores or exports the trace data. Either an external trace port, a trace-to-memory bridge, or an on chip buffer.

A trace link is part of the interconnect (and mostly only visible to designers, except where there is configurable routing). Links can be 1:n or n:1 connections, clock/power bridges, or fifos.

Trace/debug is designed for both external (on the bench) use, and self-hosted use cases (provided there is a software accessible buffer). The latter can be exposed through an OS to user-space if required.

The purpose of a software driven trace source is to allow the developer to embed printf like functionality within their code. Of course, printf to a uart is expensive, there is the masive library overhead (in an embedded aplication), the function call and formatting cost, exception handlers for the uart, etc. STM trace can be far more trivial. At key locations in your code, a single store to the address of an STM channel is enough to send a message (so the overhead is roughly 2-3 instructions). The channels can be disabled which allows the messaging impact on timing to be static (even in production code). Tools can tokenise the messages for a better user experience (I guess most of your debug printf will be static messages). There is good support for using the ITM like this in Cortex-M since the capture hardware can be easily integrated with a debug probe. Although this trace is real-time, and low overhead, the granularity is reduced and the developer needs to modify the critical code sections to include instrumentation trace.