The ITM stimulus registers are standardized by ARM and found on address 0圎0000000 (port 0) through 0圎000007C (port 31). In that case, the ITM writes took just 7 clock cycles, every single time! Very nice! However, at slightly lower data rates, there was no ITM blocking at all. In this case there was some ITM blocking but not much – the average write time (including the blocking) was only 20 clock cycles (119 ns 168 MHz) and the longest blocking being around 100 cycles. This data rate required us to “hammer” the ITM port in a tight loop on a fairly fast ARM Cortex-M4 MCU at 168 MHz and with optimized code. Our host-side test application verified the received data continuously and the data transfer was 100% reliable even at maximum speed. Our test application managed to write over 2 MByte/s over ITM, many times more than required for typical Tracealyzer RTOS tracing. Recently we did an ITM experiment with a Keil ULINKpro. Leading debug probes including SEGGER J-Link, the high-end Keil ULINK models and IAR I-Jet allow SWO sampling rates of 60-100 MHz and cost around €300-€600, money well spent according to me! With a probe like this, you can typically use the ITM ports with no risk of blocking or data loss. This way may however cause a significant impact on the timing of your system, if your debug probe is too slow in receiving the data.Ī better way to avoid data loss and blocking is to use a fast debug probe.
HOW COST IAR ARM CODE
This can be prevented by checking if the ITM FIFO has room for additional data before writing it and delay the write in case there is no room (see the below code example for “fputc”). The ITM FIFO buffer is pretty small, only 10 bytes, so if using a slow debug probe some data might be lost if writing too frequently to the ITM ports. The SWO interface is supported by most debug probes targeting ARM MCUs.
HOW COST IAR ARM SERIAL
The ITM data is included with the instruction trace (ETM) if using the full trace port together with an advanced trace debugger, but it is also available via the commonly available Serial Wire Out (SWO) interface in the debug port. For instance, ARM recommends channel 0 for text data (e.g., from printf) and channel 31 for RTOS events, while the other channels can be used for whatever purpose you like. The ITM channels share a common FIFO buffer in the ITM unit, that in turn is connected to one or two output ports. These channels allow for separating the diagnostic data into different categories. The ITM unit provides 32 logical channels for SWIT events, each with a corresponding stimulus register where it accepts input. The data can be character-by-character text data (e.g, from printf) but it is also possible to send binary data as ITM supports up to 32 bits of data per write. Many IDE’s allows you to view this data in a debug window or to write the data to a file for later analysis. This can be very fast with a proper debug probe, just a few clock cycles, and ITM even supports automatic time-stamping done by the hardware.
HOW COST IAR ARM PC
Using ITM you can transmit any kind of data to the host PC as SWIT events, simply by writing the data to a memory-mapped register on your ARM-based MCU.
HOW COST IAR ARM SOFTWARE
Software instrumentation (SWIT) events, i.e., custom data logged by your code.Debug events generated by the DWT unit, such as exception events and data watchpoint events.ITM is a hardware unit that can transfer diagnostic data of two main types: There might however be an excellent solution built in to your MCU already, at least if using an MCU with an ARM Cortex-M3, M4 or M7 core, namely ITM – Instrumentation Trace Macrocell. But if using plain “printf” calls over a traditional serial port, the overhead is often many milliseconds per logging call, which disturbs the application behavior and is unacceptable in time critical code such as exception handlers or fast control loops. Having some form of diagnostic logging/tracing is necessary in most firmware development. At Percepio we develop the Tracealyzer tools for RTOS trace visualization, but this post is about a related technology from ARM that we believe is of general interest to any developer using ARM-based MCUs. When developing embedded software, a good understanding of the real-time behavior is vital.
0 kommentar(er)
