While talking to our TrueSTUDIO customers, as well as many other Cortex-M developers, it has become clear to me that many developers are not aware of the powerful system analysis and debugging mechanisms available in Cortex-M devices. By better utilizing the capabilities that are already in their possession, embedded developers could easily become a lot more efficient in their debugging efforts.
I touched upon this subject in my earlier blog post on Hard fault system crash analysis on Cortex-M devices, and I will continue with a series of blog posts on real-time event- and data tracing using the Serial Wire Viewer (SWV) debug interface, which is available in Cortex-M cores and hence in popular devices like STM32, Kinetis, LPC or EFM32. This is the first blog post in the article series; several more will come in the next couple of weeks.
With SWV, it is now possible to have greater visibility into the dynamics of complex real-time embedded applications than ever before. This visibility is extremely useful, not only in the increasingly complex applications typically found in today’s products, but in applications that cannot be halted for the debugging process
Serial Wire Viewer (SWV) provides real-time event and memory access tracing with little- or no processor overhead while the application executes at full speed. This is made possible by the internal architecture of the devices, and does not require software support such as low priority daemons or monitor code that must linked with the application. The Instrumentation Trace Macro cell (ITM) is a minimally intrusive way to transmit data via one of the 32 ITM ports as the application executes. This for example enables printf() style debugging without a physical UART, USB, Ethernet or other type of communication channel.
I wrote this blog post to give a brief background to the Serial Wire Viewer (SWV) and Instrumentation Trace Macro cell (ITM) technology. It also outlines how advanced debuggers can exploit the SWV and ITM technology to deliver powerful debug capabilities to developers. Many embedded developers continue to use “tried and true” methods of debugging such as blinking LED and printf() outputs. When the ease of use, information content and the cost efficiency of modern debugging technology is considered, I think it is well worth a developer’s while to devote the relatively small amount of effort to becoming familiar with these methodologies as the payback in time savings in debugging and testing will be considerable.
Serial Wire Viewer overview
To use system analysis and real-time tracing in compatible ARM processors, a number of different technologies interact; Serial Wire Viewer (SWV), Serial Wire Debug (SWD), Serial Wire Output (SWO) and Instrumentation Trace Macrocell (ITM). Their respective roles will be explained below.
Serial Wire Debug (SWD)
Serial Wire Debug (SWD) is a debug port similar to JTAG, and provides the same debug capabilities (run, stop on breakpoints, single-step) but with fewer pins. It replaces the JTAG connector with a 2-pin interface (one clock pin and one bi-directional data pin). The SWD port itself does not provide for real-time tracing.
Serial Wire Output (SWO)
The Serial Wire Output (SWO) pin can be used in combination with SWD and is used by the processor to emit real-time trace data, thus extending the two SWD pins with a third pin. The combination of the two SWD pins and the SWO pin enables Serial Wire Viewer (SWV) real-time tracing in compatible ARM processors.
Serial Wire Viewer (SWV)
Serial Wire Viewer is a real-time trace technology that uses the Serial Wire Debugger (SWD) port and the Serial Wire Output (SWO) pin. Serial Wire Viewer provides advanced system analysis and real-time tracing without the need to halt the processor to extract certain types of debug information.
Serial Wire Viewer (SWV) can provide the following types of target information:
- Periodic samples of program counter (PC) values
- Event notification on memory accesses (such as reading/writing C variables)
- Event notification on exception entry and exit
- Event counters
- Timestamp and CPU cycle information
Based on this trace data, modern debuggers can provide developers with a wealth of advanced debugger capabilities.
The developer can configure SWV in many different ways, to make it emit various combinations of information, e.g. values of memory locations, exception events, PC values etc. As more types of trace data are enabled for transmission, the more trace packages are needed to be sent from the CPU to the PC debugger. It is possible in certain circumstances that all of the data may not be received by the front end debugging software on the PC.
There are several reasons for this. The target CPU running at full speed can exceed bandwidth on the one-pin SWO output. In addition, trace data makes its way to the SWO via internal buffers which are limited in depth. If the CPU generates more trace packages than the SWO pin can transmit, there will be resulting packet loss. This is normal.
The reason is that Cortex-M microcontrollers are designed to meet aggressive cost targets. The resource limitation is a byproduct of the tradeoff between resources and cost, and is to some extent, “by design”. While this imposes minor limitations on what can be done, it is also true that SWV and ITM, used with care, are capable of providing very powerful debug information that in some cases are otherwise unobtainable information without very expensive debug hardware.
Instrumentation Trace Macro cell (ITM)
The Instrumentation Trace Macro cell (ITM) enables applications to write arbitrary data to the SWO pin, which can then be interpreted and visualized in the debugger in various ways. For example, ITM can be used to redirect printf() output to a console view in the debugger.
In my mind, this is highly desirable and useful for several reasons. First, the overhead is very low as a memory location can be transferred in a single clock cycle. Second, there is no requirement for an on-board resource such as a UART or USB connection, as the data is transmitted using the debug probe hardware. Third, the ITM port has 32 channels, and by writing different types of data to different ITM channels, the debugger can interpret or visualize the data on various channels differently.
Since writing a byte to the ITM port only takes one clock cycle, applications can thus keep the ITM trace instrumentation when the product ships. It is then not needed to rebuild and retest a product build with instrumentation removed. Leaving this kind of instrumentation in the shipped code also provides the capability of connecting a debugger to a live system in-the-field for detailed analysis in deployed products.
Limitations of SWV
I have now spent some time highlighting benefits with SWV. But what are the disadvantages of SWV? I think there are mostly two limitations worth mentioning . First, SWV handles event-, data- and software instrumentation trace, but it does not support instruction tracing to record the execution history of each machine code instruction executed. To do that, any of the instruction trace technologies ETM/ETB/MTB must be used on Cortex-M devices. Secondly, the limited bandwidth may result in packet loss if too many trace packages are sent in a short period of time (i.e. the SWV use is “over configured”).
On the other hand, very advanced debugger capabilities are enabled by SWV at low extra H/W cost so these are reasonable tradeoffs.
Developers using low-end ECLIPSE IDE’s (typically using gcc and gdb GNU tools) will in most cases not be able to use SWV, and this goes for some proprietary IDEs too.
Even though our Atollic TrueSTUDIO IDE is built using Eclipse and GCC/GDB, we fully support SWV tracing (including SWD, SWO and ITM) using proprietary extensions to both the debugger frontend and debugger backend. In terms of JTAG probes, we support SWV tracing using both SEGGER J-Link and ST-LINK from STMicroelectronics.
As this article has been a short introduction to the technologies forming Serial Wire Viewer tracing (SWV, SWD, SWO and ITM), it has mostly provided a technical background, and not touched so much on the actual debugger features enabled by SWV. In the coming blog posts in this article series, I will explain what actual capabilities this provides to Cortex-M developers.
For example, Atollic TrueSTUDIO provides developers with these debugger capabilities built on top of SWV:
- Event trace (log and timeline graph)
- Exception trace (log and timeline graph)
- Exception nesting analysis
- Interrupt statistics graph
- Real-time data and memory watch
- Data trace and memory access history log
- Data trace graph (real-time “oscilloscope plot” visualizations of data)
- Speed performance analysis (statistical profiling graph)
- Execution time measurement
- Printf() output re-directed into debugger console
- Custom ITM trace instrumentation
If you are interested to learn more on how you can improve your Cortex-M debugging capabilities visit our summary blog post:
You can also read this whitepaper for more information on event- and data tracing using SWV: