Chapter 221. SystemView Recording
Table of Contents
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
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
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.
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.
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
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
cyg_hal_invoke_constructors() as a
holding place whilst the H/W debugger network server is started and
svproxy tool executed.
For example, assuming a PEEDI configured to expose the RTT channel 1 on port 19112 as follows:
rtt setup 0x80030000 0x10000rt1064evk_swd>
rtt start++ info: control block found at 0x8003AD1C rt1064evk_swd>
rtt listtarget -> 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
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
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.
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.
UARTconfiguration 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_HALapproach. 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
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
- 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
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.
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
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
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
|2023-08-15||eCosPro Non-Commercial Public License|