Difference between revisions of "Protocol decoder:Arm tpiu"
(→Hardware: added link to ARM CoreSight specification of Manchester) |
|||
(8 intermediate revisions by 2 users not shown) | |||
Line 6: | Line 6: | ||
| license = GPLv2+ | | license = GPLv2+ | ||
| source_code_dir = arm_tpiu | | source_code_dir = arm_tpiu | ||
| image = | | image = [[File:Pv arm tpiu.png|250px]] | ||
| input = uart | | input = [[Protocol_decoder:Uart|uart]] | ||
| output = uart | | output = [[Protocol_decoder:Uart|uart]] | ||
| probes = | | probes = — | ||
| optional_probes = | | optional_probes = — | ||
| options = stream | | options = stream, sync_offset | ||
}} | }} | ||
''' | The '''arm_tpiu''' protocol decoder decodes the [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0337h/BABBIFBG.html ARM TPIU (Trace Port Interface Unit)] protocol. | ||
The TPIU 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. | |||
'''This is one of three closely related protocol decoders:''' [[Protocol_decoder:arm_tpiu|arm_tpiu]], [[Protocol_decoder:arm_itm|arm_itm]], [[Protocol_decoder:arm_etmv3|arm_etmv3]]. | |||
== | == Hardware == | ||
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 [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0314h/Chdbabbg.html Manchester encoded single wire] data, but this is not yet implemented in a protocol decoder. | |||
== 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 the range of 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. | |||
== Usage == | |||
=== Protocol decoder stacking === | |||
The protocol decoder stacking has to match the actual configuration on the chip. A typical stacking would be: | |||
* [[Protocol_decoder:uart|uart]], with the '''baudrate''' option matching the clock rate on the TRACESWO pin | |||
* [[Protocol_decoder:arm_tpiu|arm_tpiu]], with the '''stream''' option matching the value configured in the CPU | |||
* [[Protocol_decoder:arm_itm|arm_itm]] or [[Protocol_decoder:arm_etmv3|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, [[Protocol_decoder:arm_itm|arm_itm]] or [[Protocol_decoder:arm_etmv3|arm_etmv3]] can be stacked directly on top of the [[Protocol_decoder:uart|uart]] decoder. | |||
=== 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 occasional pauses of at least 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. | |||
== Resources == | |||
* [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0337h/BABBIFBG.html Cortex-M3 Technical Reference Manual: Trace Port Interface Unit] | |||
* [http://infocenter.arm.com/help/topic/com.arm.doc.ihi0029d/IHI0029D_coresight_architecture_spec_v2_0.pdf IHI0029: ARM CoreSight Architecture Specification v2.0] (PDF), chapter D4 "Trace Formatter" | |||
[[Category:Protocol decoder]] | |||
[[Category:UART]] |
Latest revision as of 04:17, 10 April 2019
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 |
Probes | — |
Optional probes | — |
Options | stream, sync_offset |
The arm_tpiu protocol decoder decodes the ARM TPIU (Trace Port Interface Unit) protocol.
The TPIU 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.
This is one of three closely related protocol decoders: arm_tpiu, arm_itm, arm_etmv3.
Hardware
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 a protocol decoder.
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 the range of 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.
Usage
Protocol decoder stacking
The protocol decoder stacking has to match the actual configuration on the chip. A typical stacking would be:
- uart, with the baudrate option matching the clock rate on the TRACESWO pin
- arm_tpiu, with the stream option 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 the uart decoder.
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 occasional pauses of at least 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.
Resources
- Cortex-M3 Technical Reference Manual: Trace Port Interface Unit
- IHI0029: ARM CoreSight Architecture Specification v2.0 (PDF), chapter D4 "Trace Formatter"