MIPI Alliance Debug Architecture provides a standardized infrastructure for debugging deeply embedded systems in the mobile and mobile-influenced space. The MIPI Alliance MIPI Debug Working Group has released a portfolio of specifications; their objective is to provide standard debug protocols and standard interfaces from a system on a chip (SoC) to the debug tool. The whitepaper Architecture Overview for Debug summarizes all the efforts. In recent years, the group focused on specifying protocols that improve the visibility of the internal operations of deeply embedded systems, standardizing debug solutions via the functional interfaces of form factor devices, and specifying the use of I3C as debugging bus.
The term "debug" The term "debug" encompasses the various methods used to detect, triage, trace, and potentially eliminate mistakes, or bugs, in hardware and software. Debug includes control/configure methods, stop/step mode debugging, and various forms of tracing.
Control/configure methods Debug can be used to control and configure components, including embedded systems, of a given target system. Standard functions include setting up hardware breakpoints, 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 and then "single-stepped" through the code by executing instructions one at a time. If the other cores/microcontrollers of the SoC have finished synchronously, the overall state of the system can be examined. Stop/step mode debugging includes control/configure techniques, run control of a core/microcontroller, start/stop synchronization with other cores, memory and register access, and additional debug features such as performance counter and run-time memory access.
Tracing Traces allow an in-depth analysis of the behavior and the timing characteristics of an embedded system. The following traces are typical:
A "core trace" provides full visibility of program execution on an embedded core. Trace data are created for the instruction execution sequence (sometimes referred to as an instruction trace) and data transfers (sometimes referred to as a data trace). An SoC may generate several core traces. A "bus trace" provides complete visibility of the data transfers across a specific bus. A "system trace" provides visibility of various events/states inside the embedded system. Trace data can be generated by instrument application code and by hardware modules within the SoC. An SoC may generate several system traces.
Visibility of SoC-internal operations
Tracing is the tool of choice to monitor and analyze what is going on in a complex SoC. There are several well established non-MIPI core-trace and bus-trace standards for the embedded market. Thus, there was no need for the MIPI Debug Working Group to specify new ones. But no standard existed for a "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 the 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 MIPI System Software Trace (MIPI SyS-T) is to define a reusable, general-purpose data protocol and instrumentation API for debugging. The specification defines message formats that allow a trace-analysis tool to decode the debug messages, either into human-readable text or to signals optimized for automated analysis. Since verbose textual messages stress bandwidth limits for debugging, so-called "catalog messages" are provided. Catalog messages are compact binary messages that replace strings with numeric values. The translation from the numeric value to a message string is done by the trace analysis tool, with the help of collateral XML information. This information is provided during 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 such as those defined by the MIPI System Trace Protocol. SyS-T protocol features such as timestamping or data-integrity checksums can be disabled if the transport link already provides such capabilities. The use of other transport links—such as UART, USB, or TCP/IP—is 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 (MIPI STP) specifies a generic protocol that allows the merging of 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 additionally provides 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 trace RAM, directly exported off-chip, or can be routed to a trace wrapper protocol (TWP) module to merge 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 (STPSM) is version 2.2 (February 2016).
… excerpt ends here. Continue reading the full article.






