User:AMartinMG/mipi debug

MIPI Alliance Debug Architecture provides a standardized infrastructure for debugging deeply embedded systems in the mobile space and mobile-influenced space. The MIPI Debug Working Group released therefore a portfolio of specifications. Their objective is to provide standard debug protocols and standard interfaces from the SoC to the debug tool. The whitepaper Architecture Overview for Debug summarizes all efforts. In the last years the group focused on specifying protocols that improve the visibility of internal operations in deeply embedded systems, standardizing debug solutions via the functional interfaces of form factor devices and specifiying the use of I3C as debug bus. .

The Term "Debug"

The term debug is used as an inclusive way to encompass the various methods used to detect, triage, trace, and potentially eliminate mistakes, or bugs, in hardware and/or software. Debug includes control/configure methods, stop/step mode debugging, and various forms of trace.

Control/Configure Methods

Debug can be used to control and/or configure components, including embedded systems, of a given target system. Common functions include setting up hardware breakpoints, configuring watchpoints, preparing and configuring the trace system, and examining system states.

Stop/Step Mode Debugging

In stop/step mode debugging, the core/microcontroller is stopped through the use of breakpoints. This can be used to “step” through the code. If the other cores/microcontrollers of the SoC are stopped synchronously, the overall state of the system can be examined without worrying that things may change underfoot. Stop/step mode debugging includes control/configure techniques (as given previously), run control of a core/microcontroller, start-/stop synchronization with other cores, memory and register access and additional debug features such as performance counter, run-time memory access.

Tracing

Traces allow an in-depth analysis of the behavior and the timing characteristics of an embedded system. The following trace sources typically generate trace data:

• A core trace provides detailed visibility of the program execution on an embedded core. Trace data are generated for the instruction execution sequence (sometimes referred to as instruction trace) and/or data transfers (sometimes referred to as data trace). A SoC may contain several core traces.
• A bus trace provides detailed visibility on the data transfers on a specific bus.
• A system trace provides visibility of various events/states inside the embedded system. Trace data can be generated by instrumented application code and/or by hardware modules within the SoC. A SoC may contain several system traces.

Visibility of SoC-internal Operations

Layering of the trace specifications

Tracing is the tool of choice to monitor and analyze what is going on in a complex SoC. There is a number of non-MIPI core trace and bus trace standards well established in the embedded market. Thus, there was no need for the MIPI Debug Working Group to specify new ones. But no standard existed for system trace, when the Debug Working Group published its first version of the MIPI System Trace Protocol (MIPI STP) in 2006.

MIPI System Software Trace (MIPI SyS-T)

The generation of system trace data from software is typically done by inserting additional function calls, which produce diagnostic information valuable for the debug process. This debug technique is called instrumentation. Examples are: printf-style string generating functions, value information, assertions etc. The purpose of the MIPI System Software Trace is to define a reusable, general purpose data protocol and instrumentation API for debug. The specification defines message formats, which allow a trace analysis tool to decode the debug messages either to human-readable text or to messages optimized for an automated analysis.

Since verbose textual messages are stressing bandwidth limits for debug, so-called catalog messages are provided. Catalog messages are compact binary messages that replace strings with numeric values. The translation from this value to the verbose message is done by the trace receiving analysis tool with the help of an XML collateral information. This information is provided by the software build process using an XML schema that is part of the specification as well.

The SyS-T data protocol is designed to work efficiently on top of lower level transport links like the MIPI System Trace Protocol. SyS-T protocol features like timestamping or data integrity checksums can be disabled, if the transport link already provides such capabilities. Other transport links, such as UART, USB or TCP/IP are also possible.

The MIPI Debug working group will provide an open source reference implementation for the SyS-T instrumentation API, a SyS-T message pretty printer, and a tool to generate the XML collateral data as soon as the Specification for System Software Trace (SyS-T) is approved .

MIPI System Trace Protocol (MIPI STP)

The MIPI System Trace Protocol specifies a generic protocol, that allow to merge trace streams originated from anywhere in the SoC to a trace stream of 4-bit frames. It was intentionally designed to merge system trace information. The MIPI system trace protocol uses a channel/master topology that allows the trace receiving analysis tool to collate the individual trace streams for analysis and display. The protocol provides additionally the following features: stream synchronization and alignment, trigger markers, global timestamping and multiple stream time synchronization.

The stream of STP packets produced by the System Trace Module can be directly saved to a trace RAM, directly exported off-chip or can be routed to a TWP module to merge it with further trace streams. ARM´s CoreSight System Trace Macrocell which is compliant with MIPI STP is today an integral part of most multi-core chips used in the mobile space.

The last MIPI board adopted version of Specification for System Trace Protocol (STP^SM) is version 2.2 (February 2016).

MIPI Trace Wrapper Protocol (MIPI TWP)

The MIPI Trace Wrapper Protocol enables multiple trace streams to be merged into a single trace stream (byte streams). A unique ID is assigned to each trace stream by a wrapping protocol. The detection of byte/word boundaries is possible even if the data is transmitted as a stream of bits. Inert packets are used if a continuous export of trace data is required. MIPI Trace Wrapper Protocol is based on ARM´s Trace Formatter Protocol specified for ARM® CoreSight^TM.

The last MIPI board adopted version of Specification for Trace Wrapper Protocol (TWP^SM) is version 1.1 (December 2014).

From Dedicated to Functional Interfaces

From dedicated to functional interfaces

Dedicated Debug Interfaces

In the early stages of product development, it is common to use development boards with dedicated and readily-accessible debug interfaces for connecting the debug tools. SoCs employed in the mobile market rely on two debug technologies: stop mode debugging via a scan chain and stop mode debugging via memory-mapped debug registers.

The following non-MIPI debug standards are well established in the embedded market: IEEE 1149.1 (5-pin) and ARM Serial Wire Debug (2-pin), both using single-ended pins. Thus, there was no need for the MIPI Debug Working Group to specify a stop mode debug protocol or to specify a debug interface.

Trace data generated and merged to a trace stream within the SoC can be streamed via a dedicated unidirectional trace interface off-chip to a trace analysis tool. The MIPI Debug Architecture provides specifications for both, parallel and serial trace ports.

The MIPI Parallel Trace Interface (MIPI PTI) specifies how to pass the trace data to multiple data and a clock pin (single-ended). The specification includes: signal names and functions, timing and electrical constraints. The last MIPI board adopted version of Specification for Parallel Trace Interface is version 2.0 (October 2011).

The MIPI High-Speed Trace Interface (MIPI HTI) specifies how to stream trace data over the physical layer of standard interfaces such as PCI Express, Display Port, HDMI or USB. The current version of the spec. allows one to six lanes. The specification includes:

• The LINK layer, which defines how the trace is packaged into the Aurora 8B/10B protocol.
• The PHY layer, which defines the electrical and clocking characteristics of the serial lanes.
• A programmer’s model for controlling HTI and providing status information.

HTI is a subset of the High Speed Serial Trace Port (HSSTP) specification defined by ARM Limited . The last MIPI board adopted version of Specification for High-speed Trace Interface is version 1.0 (July 2016).

Board developers and debug tools vendors benefit from standard debug connectors and standard pin mappings. The MIPI Recommendation for Debug and Trace Connectors recommends 10-/20-/34-pin board-level connectors (1.27 mm 050"). Seven different pin mappings are specified that address a wide variety of debug scenarios. They include: standard JTAG (IEEE 1149.1), cJTAG (IEEE 1149.7) and 4-bit parallel trace interface (mainly used for system traces). Supplemented by the ARM-specific standard SWD (Serial Wire Debug) MIPI10/20/34 debug connector became the standard debug connectors for ARM-based embedded designs.

Many embedded designs in the mobile space use high-speed parallel trace ports (up to 600 Mbit/s/pin). MIPI recommends a 60-pin Samtec QSH/QTH connector named MIPI60. It allows JTAG/cJTAG for run control, up to 40 trace data signals and up to 4 trace clocks. To minimize complexity, the recommendation defines four standard configurations with one, two, three or four trace channels of varying width.

The last MIPI board adopted version of MIPI Alliance Recommendation for Debug and Trace Connectors is version 1.1 (March 2011).

PHY and Pin Overlaid Interfaces

USB Type-C, USB2 pins used for SWD debug

USB Type-C Mux switches USB2 pins to SWD pins

Readily-accessible debug interfaces are not available at the product’s final form factor. This hampers the identification of bugs and performance optimization in the end product. Since the debug logic is still present in the end product, an alternative access path is needed. An effective way is to equip a mobile terminal´s standard interface with a multiplexer that allows accessing the debug logic. The switching between the interface´s native function and the debug function can be initiated by the connected debug tool or by the mobile terminal’s software. Standard debug tools can be used under the following conditions:

• A debug adapter exits that connects the debug tool to the standard interface. The debug adapter has to assist the switching protocol if required.
• A switching protocol is implemented on the debug tool and in the mobile terminal.
• A mapping from the standard interface pins to the debug pins is specified.

The MIPI Narrow Interface for Debug and Test (MIPI NIDnT) covers debugging via the following standard interfaces: microSD, USB 2.0 Micro-B/-AB receptacle, USB Type-CTM receptacle, and Display Port. The last MIPI board adopted version of Specification for Narrow Interface for Debug and Test (NIDnT^SM) is version 1.1 (January 2016).

Network Interfaces

Instead of re-using the pins, debugging can also be done via the protocol stack of a standard interface or network. Here debug traffic co-exists with the traffic of other applications using the same communication link. The MIPI Debug Working Group named this approach GigaBit Debug. Since no debug protocol existed for this approach, the MIPI Debug Working Group specified its SneakPeak debug protocol.

MIPI SneakPeek Protocol (MIPI SPP) opened up a path away from a dedicated interface for basic debug towards a protocol-driven interface.

• It translates incoming command packets into read/write accesses to memory, memory-mapped debug registers and other memory-mapped system resources.
• It translates command results (status information and read data coming from memory, memory-mapped debug registers and other memory-mapped system resources) to outgoing response packets.

Since SneakPeek accepts packets coming through an input buffer and delivers packets through an output buffer it can be easily connected to any standard I/O or network. The MIPI Alliance Specification for SneakPeek Protocol describes the basic concepts, the required infrastructure, the packets and the data flow. The last MIPI board adopted version of Specification for SneakPeek Protocol (SPP^SM) is version 1.0 (August 2015).

The MIPI Gigabit Debug Specification Family is providing details for mapping debug and trace protocols to standard I/Os or networks available in mobile terminals. These details include (not an exhaustive list): endpoint addressing, link initialization and management, data packaging, data flow management and error detection and recovery. The last MIPI board adopted version of Specification for Gigabit Debug for USB is version 1.0 (August 2015). The last MIPI board adopted version of Specification for Gigabit Debug for Internet Protocol Sockets is version 1.0 (July 2016).

I3C as Debug Bus

Current debug solutions, such as JTAG and ARM CoreSight, are statically structured which leads to limited scalability regarding the accessibility of debug components/devices. MIPI Debug for I3C specifies a scalable, 2-pin, single-ended debug solution, which has the advantage that it is available for the entire product lifetime. I3C can be used as debug bus only or can be shared between debug and its native function as data acquisition bus for sensors. Debugging via I3C works in principal as follows:

• The I3C bus is used for the physical transport and the native I3C functionality is used to configure the bus and to hot join new components.
• The debug protocol is wrapped into dedicated I3C CCC commands. Supported debug protocols are JTAG, ARM CoreSight and Intel EXI.
• The data acquisition function of the I3C Slaves is bridged to debug functionality.

Presentations

• Norbert Schulz, Intel Corporation: How MIPI Debug Specifications Help Me to Develop System SW