Chapter 221. SystemView Recording

There are two forms of continuous recording supported. The use of a H/W debugger or a dedicated Recorder communication channel.

221.1. H/W debugger

This mechanism records data from an active H/W debugger RTT session, where the H/W debugger directly accesses the target memory to extract the SystemView events. There is no requirement for any (other than the basic core CYGPKG_SYSTEMVIEW setup) run-time code on the target being sampled, and normally would provide for the lowest overhead, highest throughput, mechanism for obtaining instrumentation data.

As with all tracing involving target side software (in this case the writing of the event information into the RTT memory buffers), there will be a cost to the performance of the system not experienced when CYGPKG_SYSTEMVIEW is not enabled.

Support for receiving RTT recorded events into the host SystemView application can take two forms. Direct J-Link/J-Trace support or a socket based TCP/IP proxy helper service.

221.1.2. svproxy

When using a H/W debugger interface that supports exposing RTT channels via TCP/IP network streams then a proxy helper application can be used to obtain the H/W debugger accessed RTT buffer data for SystemView from the debugger, and present a SystemView application IP Recorder channel to the viewer application.

The host/svproxy.c source implements a simple BSD socket interface Linux example implementation. It provides a connection between the Segger SystemView application IP Recorder support and a non-Segger H/W debugger which presents the data from RTT channel 1 "SystemView" as a network stream (for example Ronetix PEEDI, or OpenOCD).

The proxy provides a service on a specified port allowing the SystemView application to connect and wait for event data to be supplied. The proxy does not need to execute on the same host as the SystemView application.

The target H/W debugger supplied stream should be referenced using its network address and port number as presented by the H/W debugger session. NOTE: The examples below assume that the target H/W debug session has been started, and that the eCos application executed until after the SEGGER_SYSVIEW_Conf() function has completed (to initialise the data structure searched for by the H/W debugger). This can be achieved by setting a breakpoint on the function cyg_hal_invoke_constructors() as a holding place whilst the H/W debugger network server is started and the svproxy tool executed.

For example, assuming a PEEDI configured to expose the RTT channel 1 on port 19112 as follows:

rt1064evk_swd> rtt setup 0x80030000 0x10000
rt1064evk_swd> rtt start
++ info: control block found at 0x8003AD1C
rt1064evk_swd> rtt list
target -> host (max 2):
    0: 'Terminal', size 1024
    1: 'SysView', size 8192
host -> target (max 2):
    0: 'Terminal', size 16
    1: 'SysView', size 8
rt1064evk_swd> rtt server_start 19112 1

Using OpenOCD is very similar, where via the telnet server exposed via OpenOCD or using the GDB monitor command support, a RTT server can be started supplied channel 1 on a network connection. The only difference being that the rtt setup requires the Segger identification string when searching for the memory based descriptor. e.g.

rtt setup 0x24000000 0x40000 “SEGGER RTT”
rtt start
rtt server start 19112 1

221.2. I/O Communication

The SystemView application Recorder Configuration allows for UART (serial) or IP (TCP/IP socket) to be selected as sources for obtaining instrumentation events from the target device.


Currently this eCos package does not yet support the direct provision of the IP mechanism. See the proxy support for an IP Recorder access to a H/W debugger connection.

These I/O channel based mechanisms, whilst not requiring a H/W debugger to be attached, do require further resources on the target system. Support code is required to provide the necessary I/O transport. Two mutually exclusive solutions are provided.


If the target platform/variant supports the feature then this option can be configured. It is a very simple, low-level, blocking-write transport implementation that will not by itself generate Kernel instrumentation events. This makes it usable if high-frequency Kernel instrumentation is enabled (e.g. detailed ISR, thread and synchronisation object activity).

This approach assumes a UART-style interface is used. The platform supplies an initialisation routine and a pair of routines to read and write data to the host SystemView application. This means that this option is only available on targets where the HAL provides the relevant support (e.g. mimxrt1xxx_evk, stm32f746g_disco, ...).


When configured this enables a higher-level Recorder approach, where a (normally low-priority) helper thread provides the periodic upload of event data to the host SystemView application.

The UART configuration requires a dedicated eCos serial I/O (UART port or USB CDC-ACM) connection. There is a greater run-time overhead to supporting this transport option over and above the J-Link H/W debugger approach or CYGOPT_SYSTEMVIEW_RECORDER_HAL approach. At least one helper thread is created, and the eCos I/O API is used. If Kernel instrumentation is enabled then the helper code will also be instrumented, which will greatly increase the instrumentation load.

If Kernel instrumentation is not enabled then this solution is sufficient for tracing the standard eCos thread, ISR and operation activity, along with any application generated SystemView events (e.g. markers).

Support for the Recorder feature can be manually enabled in the package configuration if required.

221.2.1. Performance and Analysis

When performing analysis of data captured by the SystemView application, where a run-time I/O mechanism is in use, the user needs to be aware that the act of recording measurement events will affect the overall performance of the system. This needs to be taken into account when checking reported performance.


The following timing measurements were made against a MIMXRT1064-EVK platform (Cortex-M7 clocked at 432MHz) with a simple GPIO driven signal on J23#1 measured using a Saleae LogicPro16. The GPIO line was set and cleared as the first and last operations respectively of the Cyg_RealTimeClock::isr which is the ISR handler for the SysTick event.

For the following table the SysTick ISR was chosen as an example, since it is a high-frequency, common event that is likely to be used when analysing scheduling and thread interactions. On most systems it is configured with a 10ms period.

In the following table, the acronyms used in the headers are:

Build with Kernel Instrumentation to Memory buffer configured, with interrupt events instrumented. This form of instrumentation has a reasonably low overhead, but is limited to the size of buffer that can be set aside on the target.
Build with Kernel Instrumentation to SystemView events (RTT memory buffer), with interrupt events instrumented. This approach allows for the possibility of continuous recording over long execution runs depending on the RTT access tools used.
SystemView events delivered to the host application via an eCos SystemView HAL Recorder (low-level direct I/O) with the UART using a baud rate of 1000000 (1MHz).
SystemView events delivered to the host application via a J-Trace PRO H/W debugger directly accessing RTT memory buffers, via a 4MHz SWD connection.

Table 221.1. Example Instrumentation “cost”

















Handler function execution time captured as the sampled GPIO SET/CLR period


SystemView v3.52a reported SysTick execution time (includes ISR entry/exit code)


As can be seen there is a huge difference in the time taken to execute that single, relatively simple, ISR function depending on the compiler optimisation level, whether or not memory-buffer based Kernel-instrumentation is enabled, or whether the kernel-instrumentation is directed to a SystemView Recorder (the HAL recorder in the example above) where there is the cost of transmitting the bytes over a UART channel (where the configured baud rate of that channel will also affect the timing reported) or is accessed via H/W debugger background memory accesses. The table highlights that any software based instrumentation solution has a hit on the system throughput.

So tuning of the SystemView captures, and the speed of the underlying transport channel need to be considered when performing anaylsis based on how the data was captured for SystemView.

221.3. Overflows

Since the normal target operating mode is to perform non-blocking writes of events into the RTT capture buffer, it is possible (and expected in some cases) that the host read side (whether J-Link or communication channel based Recorder) will detect an *** Overflow ***.

This can occur if the volume/rate of events being generated is overloading the available I/O channel, in which case the target configuration can be updated to reduce the quantity of events (by disabling tracking of certain events), or by increasing the buffering available to the target-side CYGPKG_SYSTEMVIEW support.

It is also possible for overflow to occur as a side-effect of the host SystemView application not actually recording (i.e. “Start Recording” not being triggered). If the CYGPKG_SYSTEMVIEW configuration is using CYGFUN_SYSTEMVIEW_START_ON_INIT then the eCos code will be recording events from startup, which may be before the host SystemView application can actually connect to the device when using a communication channel Recorder implemented by the eCos run-time; since before SystemView can attach the eCos target has to initialise and provide the drivers/software-stack needed for the I/O access. e.g. Presenting the UART Recorder via a target USB CDC-ACM device.

When configured for CYGOPT_SYSTEMVIEW_RECORDER_HAL as the event communication channel, the option CYGOPT_SYSTEMVIEW_RECORDER_HAL_WAIT is made available. This option is normally disabled, since when enabled it will cause the run-time to disable interrupts and wait in a busy poll waiting to receive the host SystemView application “connect and start a recording” commands. This feature can be used to ensure that all captured events are made available to the SystemView application; which may be critical when instrumenting/analysising application initialisation. The caveat is that the target will appear to be “hung” until it receives a valid hello message from the SystemView application.