SEGGER SystemView User Guide
Recording and analyzing runtime behavior of embedded systems.
SEGGER SystemView 3.54, June 3, 2024
Overview
This section describes SEGGER SystemView in general.
What is SEGGER SystemView?
SystemView is a toolkit for visual analysis of any embedded system. SystemView
gives complete insight into an application, to gain a deep understanding of the
runtime behavior, going far beyond what a debugger is offering.
This is particularly advantageous when developing and working in complex
systems with multiple tasks and events.
SystemView consists of two parts:
- The PC visualization SystemView Application,
- Code that gathers telemetry data on the target system.
The SystemView application allows analysis and profiling of the behavior
of an embedded system. It records the telemetry data generated by the
embedded system and visualizes that information in a variety of ways. The
recording can be saved to a file for later analysis or for documentation
of the system.
The telemtery data is recorded through the debug interface, through a network
connection, or over a serial line. When recording through the debug interface,
no additional hardware (and additional pinning) is required to use SystemView.
It can be used on any system that allows debug access.
With a SEGGER J-Link and its Real Time Transfer (RTT) technology,
SystemView can continuously record, analyze, and visualize data in real time.
SystemView makes it possible to analyze which interrupts, tasks, and software
timers have executed, how often, when exactly and how much time they have used.
It sheds light on what exactly happened, in which order, which interrupt has
triggered which task switch, which interrupt and task has called which API
function of the underlying modules.
Cycle-accurate profiling can be performed and performance markers can be
added in the system to measure timings.
SystemView can be used to verify that the embedded system behaves as
expected and can be used to find problems and inefficiencies, such as
superfluous and spurious interrupts, unexpected task changes, or badly-chosen
task priorities. It can be used with any (RT)OS which is instrumented to call
SystemView event functions, but also in systems without an instrumented RTOS
or without any RTOS at all, to analyze interrupt execution and to time user
functionality like time-critical subroutines.
How does it work?
On the target side a small software module, containing SYSTEMVIEW and RTT, must
be included. The SYSTEMVIEW module collects and formats the monitor data and
passes it to RTT.
The target system calls SYSTEMVIEW functions in certain situations, such as
interrupt start and interrupt end, to monitor events. SystemView stores these
events together with a configurable, high-accuracy timestamp.
Timestamps can be as accurate as 1 CPU cycle, which equates to 5 ns on a
200 MHz CPU.
The RTT module stores the data in the target buffer, which enables continuous
recording, as well as single-shot recording and post-mortem analysis.
The recorder interface reads the data from the RTT buffer and sends it to the
SystemView Application.
What resources are required on the target side?
The combined ROM size of RTT and the SYSTEMVIEW modules is less than 2 KByte.
For typical systems, about 600 bytes of RAM are sufficient for continuous
recording.
For system-triggered recording the buffer size is determined by the time to be
recorded and the amount of events. No other hardware is required.
The CPU requires less than 1 us for typical events (based on a 200 MHz Cortex-M4
CPU), which results in less than 1% overhead in a system with 10,000 events
per second.
Since the debug interface (JTAG, SWD, FINE, …) is used to transfer the data,
no additional pins are required.
On which CPUs can SystemView be used?
SystemView can be used on any CPU.
Continuous real-time recording can be carried out on any system supported by
J-Link RTT technology or using a network connection or serial line.
RTT requires the ability to read memory via the debug interface during program
execution which is generally supported in ARM Cortex-M0, M0+, M1, M3, M4, M7, M23, M33
processors as well as all Renesas RX devices.
On systems which are not supported by the RTT technology the buffer content
can also be read manually through the debug probe
when the system is halted, which allows single-shot recording until the buffer
is filled and post-mortem analysis to capture the latest recorded data.
Single-shot and post-mortem recording can be triggered
by the system to be able to control when a recording starts and stops.
How much work is it to add it to a target system?
Not very much.
A small number of files need to be added to the makefile or project.
If the operating system supports SystemView, then only one function needs to
be called.
In a system without RTOS or non-instrumented RTOS, two lines of code need
to be added to every interrupt or function which should be monitored.
That’s all and should not take more than a few minutes.
The SEGGER SystemView package
The following sections describe how to install the SEGGER SystemView package and
its contents.
Download and installation
The SEGGER SystemView package is available for Windows, macOS and Linux as an
installer setup and a portable archive.
Download the latest package for your operation system from
https://www.segger.com/systemview.
In order to do live recording the current J-Link Software and Documentation
Package must be installed. Download and instructions are available at
https://www.segger.com/jlink.
Windows Installer
Download the latest setup from http://www.segger.com/systemview and
execute it.
The setup wizard guides through the installation.
After installation the package content can be accessed through the Windows Start
menu or from the file explorer.
Windows Portable Package
Download the latest zip from http://www.segger.com/systemview and
extract it to any directory on the file system.
No installation is required, after extraction the package content can be used
directly.
macOS Installer
Download the latest pkg installer from http://www.segger.com/systemview and
execute it.
The package installer guides through the installation.
After installation the SystemView Application can be accessed through Launchpad.
Linux Requirements
To run SystemView on Linux the Qt V4.8 libraries have to be installed on
the system.
Linux Installer
Download the latest DEB or RPM installer for your Linux from
http://www.segger.com/systemview and execute it.
The software installer guides through the installation.
Linux Portable Package
Download the latest archive for your Linux from
http://www.segger.com/systemview and extract it to any directory on
the file system.
No installation is required, after extraction the package content can be used
directly.
Target Sources
Download the latest sources to be included in the embedded application from http://www.segger.com/systemview and
extract it to a folder of your choice.
Sources to interface with SEGGER software, such as embOS are also included.
Package content
The SEGGER SystemView package includes everything needed for application tracing
— the host PC visualization SystemView Application and sample trace files
for a quick and easy start.
The following tables list the package content.
SystemView package
File | Description |
./SystemView* | The SystemView analysis and visualization tool. |
./Doc/UM08027_SystemView.pdf | This documentation. |
./Doc/Release_SystemView.html | Release notes and revision history. |
./Description/SYSVIEW_*.txt | SystemView API description files. |
./Sample/FS_DeviceActivity.SVDat | Demonstrates the usage of the callback invoked on each device operation. |
./Sample/FS_Performance.SVDat | SystemView Sample recording of SEGGER emFile, testing read and write performance of the Macronix NAND Flash (MX30LF1GE8ABTI) on the SEGGER emPower board (Freescale MK66FN2M0VMD18) |
./Sample/OS_IP_WebServer.SVDat | SystemView sample trace file of a web server application. |
./Sample/OS_Start_LEDBlink.SVDat | SystemView sample trace file of a simple embOS application. |
./Sample/Sample_Overflow.SVDat | SystemView sample recording showing SystemView buffer overflows. |
./Sample/uCOS_Start.SVDat | SystemView sample trace file of a simple uC/OS-III application. |
Target source package
File | Description |
./Src/Config/Global.h | Global data types for SystemView. |
./Src/Config/SEGGER_RTT_Conf.h | SEGGER Real Time Transfer (RTT) configuration file. |
./Src/Config/SEGGER_SYSVIEW_Conf.h | SEGGER SYSTEMVIEW configuration file. |
./Src/Sample/COMM | Recorder via network connection using embOS and emNet. |
./Src/Sample/embOS | Initialization and configuration of SystemView with embOS. |
./Src/Sample/FreeRTOSV8 | Initialization and configuration of SystemView with FreeRTOS V8. |
./Src/Sample/FreeRTOSV9 | Initialization and configuration of SystemView with FreeRTOS V9. |
./Src/Sample/FreeRTOSV10 | Initialization and configuration of SystemView with FreeRTOS V10. |
./Src/Sample/MicriumOSKernel | Initialization and configuration of SystemView with the Micrium OS Kernel. |
./Src/Sample/NoOS | Initialization and configuration of SystemView with no OS. |
./Src/Sample/uCOS-II | Initialization and configuration of SystemView with uC/OS-II. |
./Src/Sample/uCOS-III | Initialization and configuration of SystemView with uC/OS-III. |
./Src/SEGGER/SEGGER.h | Global types & general purpose utility functions. |
./Src/SEGGER/SEGGER_RTT.c | SEGGER RTT module source. |
./Src/SEGGER/SEGGER_RTT.h | SEGGER RTT module header. |
./Src/SEGGER/SEGGER_RTT_ASM_ARMv7M.S | Optimized RTT routines for Cortex-M. |
./Src/SEGGER/SEGGER_SYSVIEW.c | SEGGER SYSTEMVIEW module source. |
./Src/SEGGER/SEGGER_SYSVIEW.h | SEGGER SYSTEMVIEW module header. |
./Src/SEGGER/SEGGER_SYSVIEW_ConfDefaults.h | SEGGER SYSTEMVIEW configuration fallback. |
./Src/SEGGER/SEGGER_SYSVIEW_Int.h | SEGGER SYSTEMVIEW internal header. |
./Src/SEGGER/Syscalls/SEGGER_RTT_Syscalls_*.c | Sources for toolchain dependent low level routines for I/O via RTT. |
Licensing
SystemView can be used free of charge for non-commercial purposes under SEGGER’s Friendly License (https://www.segger.com/license-sfl).
For any other use a commercial-use license is required.
There are no feature limitations with a non-commercial license.
SystemView enables unlimited recording and comes with features for better
analysis, search, and filtering.
Commercial-use licenses for SystemView are available as single-user licenses
as well as group or company-wide licenses.
For more information refer to SEGGER’s Commercial-use License (https://www.segger.com/license-cul).
Non-commercial license
SystemView may be used with a non-commercial license for evaluation,
educational and hobbyist purposes.
When you use SystemView under the non-commercial license, no activation is required.
On start of the SystemView Application, a popup is presented.
Click continue to accept the license terms.
Getting started with the SystemView Application
This section describes how to get started with SEGGER SystemView.
It explains how to analyze an application based on monitored data.
This chapter refers to the sample data file OS_IP_WebServer.SVDat which
is part of the SEGGER SystemView package.
The sample data file shows the behavior of a target system running the
embOS RTOS, the emNet TCP/IP stack and a web server application.
We are going to analyze what the application is doing with the information from
SEGGER SystemView.
Starting SystemView and loading data
SystemView can monitor data live from the target application.
The monitored data can be saved to a file for later work with it.
Saved data can analyzed without a J-Link and even without the target
hardware or the target application.
This enables analysis of the system by developers who do not have physical
access to it.
- Start the SystemView Application (SystemView.exe) from the Windows Start menu or the installation directory.
- On the first start of SystemView it will open the sample recording.
- On further starts select File → Recent Files → $PackageInstallationDir$/Sample/OS_IP_WebServer.SVdat.
SystemView loads and analyzes the data, shows the system information of the
loaded recording, and should now look like this:
The recording was done for an application that creates a web server that delivers
the embOS/IP demo web page, when accessed by a web-browser.
The sample data has been gathered while the web server was running and the browser
loaded the web page multiple times.
A first look at the system
We will take a first look at the data to get some information about the
monitored system.
System Information
The System Information dialog, shown after loading the data, provides a first
overview on the recording.
It displays information about the target system, the recording and statistical
information of tasks, interrupts, and events.
The system information is reported by the application, therefore SystemView does not
require any additional configuration to analyze and display the system behavior.
Timeline
The Timeline window shows the complete monitored data.
In the Events list, scroll to the first item to get started.
The Timeline window visualizes the system activity by context
(task, interrupt, scheduler and idle) over the system time.
Each row refers to one context item and we can see all items which have been
used in the application while it has been monitored.
At the beginning we can see that there are two tasks, IP_Task and IP_WebServer,
indicated by the light background in the context row.
Zoom in to a timeline width of 2.0 ms and double-click on the vertical line
below ’+1. 0 ms’ to center and select the item.
(Use the mouse wheel or the [+]/[-] keys to zoom,
or use the menu or context menu to set the zoom level to a distinct value.)
There is some system activity every millisecond from the SysTick interrupt.
Move the mouse over a context name to get more information about the context
type and run time information.
Click on the right arrow button of the IP_Task context to jump to its next
execution.
Zoom in or out to show the activity in detail.
We can see the SysTick interrupt returned to the OS Scheduler, which makes the
IP_Task ready, indicated by the grey bar in the IP_Task’s row, and lets it run.
The IP_Task returns from the embOS API function OS_TASKEVENT_GetTimed with return
value 0, which indicates that no event has been signaled in time.
The IP_Task calls three other embOS API functions which quickly return and
OS_TASKEVENT_GetTimed, which activates the scheduler, deactivates the task, and puts
the system into idle. IP_Task will be activated again when the event
(EventMask = 1) occurs or after the timeout of 10 ticks (i.e. 10.0 ms, as a tick occures every 1.0 ms).
Recorded function calls are visualized in the timeline as small bars in the
context row.
The vertical peak line indicates the call of a function, the bar shows the
length of the call. Stacked bars visualize nested function calls.
Move the mouse over the context activity to get more information about context
runtime, events and function calls.
Conclusion
We have got some first information about the monitored system.
From the Timeline we know which tasks and interrupts are used by the
application, that it is controlled by the 1 kHz SysTick interrupt,
and the IP_Task is activated at least every 10 ms.
Analysing system activity
After getting some information of the system we will analyze how the system is
activated.
Events list
The Events list shows all events as they are reported from the system and displays
their information, including timestamp of the event, active context,
type of event and event details. It is synchronized with the Timeline.
We have seen that every millisecond the SysTick ISR enters and exits
and that it activates the IP_Task every 10 ms because its timeout occurred.
Go to event #66 with Go → Goto Event…
(Keyboard shortcut: Ctrl+G). It is a call of OS_TASKEVENT_GetTimed with a
timeout of 10 ms from the IP_Task at 00.016 052 607. The timeout would happen
at 00.026 052 607.
Set a time reference on the event (View → Toggle Reference,
Right-Click → Toggle Reference, or (Keyboard shortcut R).
All following timestamps in the Events list are measured from the latest
reference.
To now see whether the IP_Task runs because of the timeout or because of the
event it waits for, go to the next activity of IP_Task with
Go → Forward (Keyboard shortcut: F).
The timestamp is 00.003 467 857, so 3 ms after the last reference and clearly
before the 10 ms timeout. So the task has been activated by the event it
waited for.
We can see the ETH_Rx interrupt happened before. We received a packet via
ethernet (60 Bytes on interface 0). Therefore the ETH_Rx interrupt signaled the
event, which marked the task as ready as indicated in the timeline.
The ETH_Rx interrupt returns to the Scheduler.
IP_Task runs and returns from OS_TASKEVENT_GetTimed with return value 0b1,
indicating that this event happened.
Conclusion
Going further through the events, we can see that the IP_Task is activated
after the 10 ms timeout occurred or after we received something and the
ETH_Rx interrupt occurred.
Further analysis of the application core
We now know that the system is mainly controlled by the ETH_Rx interrupt.
The next step is to see what the system does when it is more active.
Timeline, Events list, Terminal and Contexts window
The windows of SystemView are synchronized and provide the best
possibilities for system analysis when used together.
The Log output of the web-server application has also been sent through SystemView
and is displayed in the Terminal window along with the timestamp it has been logged
and the active context.
Select a message in the Terminal to also select it in the Events list and the
Timeline. The Timeline also indicates all Terminal output.
Go through the messages to see the system initialization when the Ethernet
connection is established and select “WebS: Get /”,
which is the request from the browser to get the root index webpage.
Go to event #12894, right before the message for detailed analysis.
Here we see that an ETH_Rx interrupt occurred, which calls the embOS/IP function
_ReadPacketsSingleIF and receives the packet. Upon reception the embOS event is
signaled as seen before, and the interrupt exits into the scheduler which
activates the IP_Task.
The IP_Task sets the system event which signals the IP_WebServer Task to become
ready. Another packet is received immediately and handled by the IP_Task.
When IP_WebServer starts running it is in accept() which calls some OS
functions and then returns. It then checks if the Webserver Child task exists
and creates it since it did not.
On creation of the task it is added to the contexts and marked with a light
background in the timeline while it is not active.
IP_WebServer waits for another connection in accept() and the Webserver Child
handles the received HTTP request and serves the webpage.
While Webserver Child is active, it may be interrupted by other ETH_Rx
interrupts, which cause a preemptive task switch to the IP_Task, because the
IP_Task has a higher priority than the Webserver Child.
Note: Tasks are ordered by priority in the Timeline, the exact task
priority can be seen in the Contexts window.
Analysis conclusion
We analyzed what a system does without insight into the application code.
With the application source we can check with SEGGER SystemView that the system does
what it is supposed to do.
SEGGER SystemView can actively help developing applications, since it not only shows
what the system does, but also allows exact time measurement and visualizes
the influence of interrupts and events on the application flow.
This provides advanced possibilities to find problems and to improve the system.
The SystemView Application
This section describes the SystemView analysis and visualization tool.
Introduction