Protocol decoder:Arm tpiu

arm_tpiu

Name	ARM Trace Port Interface Unit
Description	Frame format for ARMv7m trace data
Status	supported
License	GPLv2+
Source code	decoders/arm_tpiu
Input	uart
Output	uart
Options	stream, sync_offset

This is one of three closely related protocol decoders: arm_tpiu, arm_itm, arm_etmv3.

ARM TPIU (Trace Port Interface Unit) is a stream formatter and multiplexer that combines data from several sources into one stream. It is used inside an ARM-based microcontroller or SoC to combine ITM and ETM trace output into a single port.

Currently only 'uart' is supported as physical layer protocol. This is the TRACESWO NRZ protocol. The TPIU hardware also supports synchronous 2- and 4-bit buses, and Manchester encoded single wire data, but this is not yet implemented in protocol decoder.

Protocol decoder stacking

The protocol decoder stacking has to match the actual configuration on the chip. A typical stacking would be:

• uart, with baudrate matching the TRACESWO clock rate
• arm_tpiu, with stream matching the value configured in the CPU
• arm_itm or arm_etmv3

On some chips, the TPIU formatting can be disabled if only one source is used, in order to remove the framing overhead. In that case, arm_itm or arm_etmv3 can be stacked directly on top of uart decoder.

ARM TPIU protocol

The ARM TPIU protocol consists of 16 byte frames. Even bytes (0, 2, ... 14) contain a stream id if bit 0 is set and data otherwise. Odd bytes are always data. The byte 15 in the frame contains the lowermost bits of each even data byte.

Stream IDs can be in range 0 to 127. Index 0 is idle stream and is ignored. Indexes over 120 are reserved, for example stream 125 is used to emit trigger messages when specific events occur.

More information on TPIU protocol is found in ARM IHI0029: CoreSight Architecture Specification, section D4: Trace Formatter.

Trace synchronization

The TPIU protocol includes synchronization packets and the protocol decoder will use them to synchronize itself with the trace. However, the sync packets are emitted with quite long intervals (several seconds). There are a few ways to synchronize faster:

• If there are occassional pauses of atleast 16 bytes intervals, the synchronization will be regained after that.
• The sync_offset option of the protocol decoder allows skipping bytes from the beginning of the trace. By adjusting the value between 0 to 15, the initial synchronization can be done manually. This is useful if one needs to see the trace data immediately after the trace starts.