Embedded debug and trace basics

JTAG is the traditional method using several signals (TCK/TMS/TDI/TDO, optionally TRST) and supports daisy-chaining. SWD is Arm's two-wire interface (SWCLK/SWDIO), widely used on small boards because it saves pins. cJTAG provides JTAG-equivalent functions over two wires.

When selecting, check the connector type (10/20-pin, Cortex Debug, proprietary automotive connectors), the target voltage range, and how the reset signal is handled. Being on the list of supported cores alone does not always mean you can connect.

Hardware trace streams the CPU's execution information non-intrusively from a dedicated port. Arm ETM/ITM, Infineon MCDS and NEXUS on Power Architecture are examples. Because it does not affect execution, it is suited to keeping timing as evidence.

However, it cannot be used unless a trace port is brought out on the board. Buying a probe later is pointless if the hardware does not support it — the most common regret in this field. Decide whether you need trace when designing the board.

Software trace builds recording code into the RTOS or application. It can be introduced on existing hardware, but you must account for recording overhead and design the instrumentation. It is quite practical for following the behavior of task switches, interrupts, and synchronization primitives.

Hardware trace can be stored in a buffer inside the probe or streamed continuously to the host.

An internal buffer records only as long as its capacity allows. To catch rare events, streaming support or the ability to target them with trigger conditions becomes important.

The required trace bandwidth is determined by core count, clock and branch density. When tracing many cores simultaneously, output bandwidth can become the bottleneck.

On a multicore SoC, if the other cores keep running when one core stops, the state of the whole system changes and the root cause cannot be found. Check that the equipment supports synchronized halt between cores (cross-triggering).

With automotive AURIX or multi-SoC configurations, being able to see what happened on each core on the same time axis is a prerequisite. Without it, timing-related bugs are effectively untraceable.

If you run many units automatically, Ethernet/PoE-capable probes are more stable than USB. With USB, enumeration and power supply tend to become problems as the number of units grows.

Also check for a scripting API (Python etc.). If you include automated unit tests, coverage collection and regression monitoring of execution time, control through an API rather than the GUI is a prerequisite.

Under ISO 26262 ASIL C/D you may be asked to show CPU headroom (margin against worst-case execution time).

If instrumentation overhead is not acceptable, measuring with non-intrusive hardware trace is the reliable way. If this requirement may arise, reserve a trace port at the board-design stage.