What is the difference between ETM trace and SWO?

The ETM (Embedded Trace Macrocell) produces compressed instruction trace, a record of the program flow the core executed. SWO (Serial Wire Output) is a single pin on Cortex-M devices that carries instrumentation and data trace from the ITM and DWT, such as software messages, PC samples and exception events. Arm's Keil documentation describes ETM trace as output on the trace port or held in an on-chip trace buffer, so SWO alone does not give you full instruction trace.

What are ETB, ETF and ETR?

They are configurations of Arm's CoreSight Trace Memory Controller. As an Embedded Trace Buffer, trace is stored in dedicated on-chip SRAM used as a circular buffer. As an Embedded Trace FIFO, the SRAM acts as a buffer in the trace path. As an Embedded Trace Router, trace is routed over the AXI bus to system memory. Which configurations a chip has is decided by the silicon vendor.

How wide is a parallel trace port?

Arm's CoreSight Trace Port Interface Unit supports trace data widths up to 32 bits, but each implementation decides which widths it offers, and the silicon vendor decides how many trace pins reach the package. Check the device reference manual for the trace port width your part actually brings out.

When should we choose serial trace over a parallel trace port?

When the silicon implements a high-speed serial trace port and you need more trace bandwidth than the pins you can spare for a parallel port would carry. Arm describes its High Speed Serial Trace Port as carrying trace on a single two-pin lane at rates comparable to a 16-pin parallel trace port. Serial trace needs a probe that supports the specific serial protocol and careful high-speed routing on the board.

Is an on-chip trace buffer good enough for code coverage?

Usually not on its own. An on-chip buffer keeps a limited window of recent execution, which suits fault forensics around a trigger point. Coverage over a full test suite needs continuous trace across the whole run, which is what streaming trace through a trace port provides. Some teams combine the two: buffers in the field, a trace port on the development board.

Off-Chip Trace Explained: ETM, Serial Trace, Trace Buffers

Every modern Arm core, and most automotive microcontrollers, can record what the processor executed. The hard part is not generating trace. It is getting trace off the chip fast enough, and for long enough, to answer the question you have.

There are three routes. Silicon vendors choose which ones a chip implements, and board designers choose which ones survive into the hardware. If a team in Bengaluru or Pune discovers on the bench that the route it needs was never routed, the fix is a board spin. This article explains the three routes in vendor-neutral terms, mostly using Arm CoreSight because its documentation is public, then gives a decision table.

Where trace comes from

On Arm cores, instruction trace comes from the Embedded Trace Macrocell (ETM). The ETM watches the core’s execution and emits a compressed stream describing program flow: which branches were taken, which exceptions occurred, and, when enabled, timestamps and cycle counts. It does not output every instruction. A debugger rebuilds the full instruction sequence by combining the stream with the program image, which is why trace decoding needs the exact ELF file that ran.

Some older Cortex-A cores use a closely related unit: Arm’s Cortex-A9 documentation calls it the Program Flow Trace Macrocell (PTM), based on the Program Flow Trace architecture. For selection purposes it plays the same role as the ETM.

Cortex-M devices add two more trace sources: the ITM (Instrumentation Trace Macrocell) for software-generated messages, and the DWT (Data Watchpoint and Trace) unit, which Arm’s Keil documentation describes as providing data trace, PC sampling and exception tracing. These are useful, low-cost signals, but they are not instruction trace.

In a multicore device each core typically has its own trace source. The Arm Cortex-R52 Technical Reference Manual, for example, states that each core has its own ETM implementing the ETMv4.2 architecture. Arm describes that trace as exported on trace buses that a CoreSight system can use to combine trace sources before a trace sink.

Route 1: the parallel trace port

The classic route. A Trace Port Interface Unit (TPIU) formats trace and drives it out on a trace clock pin and a set of trace data pins to a connector, where a trace probe captures it.

Width. Arm’s TPIU supports data widths up to 32 bits. Each implementation decides which widths it supports, and the package decides how many pins are available. Arm’s TPIU-Lite, for example, supports 2, 4, 8, 16 and 32 bit ports. Your device reference manual is the authority.
What it needs on the board. The trace pins routed to a trace connector, with attention to signal integrity on the trace clock and data lines. Trace pins are often multiplexed with other functions, so the pin budget has to be settled early.
What it gives you. Continuous trace for as long as the probe can store or stream it. Probes differ here. SEGGER J-Trace PRO and Arm’s DSTREAM-ST stream trace to the host computer; Arm’s announcement of DSTREAM-ST says it “does not contain any trace RAM” and streams all trace data to the host. Arm’s DSTREAM-PT captures up to 32 bits of parallel trace into an on-probe trace store.

Streaming and on-probe storage solve different problems. Streaming removes the depth limit, which matters for coverage across a whole test suite. A deep on-probe store with a wide port suits short, very high bandwidth captures. The J-Trace PRO streaming trace article goes deeper on the streaming side.

Route 2: high-speed serial trace

Parallel ports run out of pins and signal margin as trace bandwidth rises. Serial trace replaces the wide bus with one or more high-speed differential lanes.

Arm’s version is the High Speed Serial Trace Port (HSSTP). On its DSTREAM-HT product page Arm states that on a single two-pin lane HSSTP can transport trace data at rates comparable to a 16-pin parallel trace port. Other silicon vendors implement their own high-speed serial trace interfaces, and automotive multicore microcontrollers are a common place to find them.

What it needs on the board. High-speed differential routing and the connector the probe expects, designed with the same care as any multi-gigabit link.
What it needs from the probe. Support for that specific serial trace protocol and that specific device. Serial trace is less interchangeable than parallel trace.
What it gives you. Far more trace bandwidth per pin, which matters for fast multicore devices where a parallel port would overflow.

Route 3: on-chip trace buffers

Some devices route no trace pins at all, or the production board has no room for a trace connector. On-chip buffers keep trace inside the chip for the debugger to read out over the normal debug connection.

Arm’s CoreSight Trace Memory Controller (TMC) is the common building block. Arm documents three configurations:

ETB (Embedded Trace Buffer): trace stored in a dedicated SRAM used as a circular buffer.
ETF (Embedded Trace FIFO): the SRAM acts as a FIFO in the trace path, smoothing bursts before trace goes to another sink.
ETR (Embedded Trace Router): trace routed over the AXI bus to system memory, so a region of the device’s RAM becomes the trace buffer.

Small Cortex-M devices have a lighter option: the Micro Trace Buffer (MTB), which Arm’s Keil documentation describes for Cortex-M0+ and Cortex-M23 based devices. It records program flow into a region of on-chip SRAM.

On-chip buffers cost no pins, which is their strength. Their weakness is depth: you keep a window of recent execution, not a continuous record. That suits “what happened just before this fault”, and it does not suit coverage over an eight-hour regression.

Decision table

	Parallel trace port	High-speed serial trace	On-chip buffer (ETB, ETF, ETR, MTB)	SWO (Cortex-M)
What leaves the chip	ETM or PTM program flow trace	ETM or vendor trace, serialised	Nothing until the debugger reads the buffer	ITM and DWT data, not instruction trace
Board cost	Trace clock plus data pins and a connector	Differential lanes and a high-speed connector	None beyond the debug connector	One pin
History you keep	Continuous while the probe streams or stores	Continuous while the probe streams or stores	A window sized by the buffer	Continuous, low bandwidth
Probe requirement	Trace probe supporting the port width	Probe supporting that serial protocol and device	Any probe whose debugger can read the buffer	Most debug probes
Best for	Coverage, timing, long captures on development boards	Fast multicore devices that overflow a parallel port	Fault forensics, field units, boards with no trace connector	Logging, sampling, first look at timing

Three design rules that save a board spin

Read the device’s debug and trace chapter before the schematic review, and write down which trace sinks the silicon implements. You cannot add a trace port the chip does not have.
Route trace on development and test boards even if production will not have it. Coverage and timing evidence is collected on development hardware. The production-silicon side of the story is covered in non-intrusive debug of safety ECUs on production silicon.
Plan for overflow. Any trace route can be overwhelmed by a fast core executing dense code. Trace filters, start and stop conditions, and cycle-accurate mode settings change how much data the ETM generates. Decide what you need to see before you decide how wide a port to route.

Where GSAS fits

GSAS Micro Systems supplies trace probes and debuggers from SEGGER and Arm in India, including J-Trace PRO, DSTREAM-ST, DSTREAM-PT and ULINKpro, with Arm Development Studio for multicore Arm targets. Our application engineers in Bengaluru, Pune, Chennai and Hyderabad review trace routing on schematics and bring up trace on real boards.

For automotive multicore microcontrollers with their own serial trace interfaces, such as AURIX and RH850, talk to our FAE team about the right probe for your device and trace interface.