Difference between revisions of "Protocol decoder:Arm tpiu"

From sigrok
Jump to navigation Jump to search
(→‎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
| annotations    = Text, Python
}}
}}


'''This is one of three closely related protocol decoders:''' [[Protocol_decoder:arm_tpiu|arm_tpiu]], [[arm_itm]],[[arm_etmv3]].
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.


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.
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.


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.
'''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]].


== Protocol decoder stacking ==
== Hardware ==


The protocol decoder stacking has to match the actual configuration on the chip.
Currently only UART is supported as physical layer protocol. This is the '''TRACESWO''' NRZ protocol.
A typical stacking would be:


* uart, with baudrate matching the TRACESWO clock rate
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.
* 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.
== Protocol ==


== 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.


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.


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.
== Usage ==


More information on TPIU protocol is found in ''ARM IHI0029: CoreSight Architecture Specification, section D4: Trace Formatter''.
=== 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

arm_tpiu
Pv arm tpiu.png
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