Maximum system insight
No additional hardware required
Real-time analysis and visualization
SEGGER SystemView is a real-time recording and visualization tool that reveals the true runtime behavior of an application, going far deeper than the insight provided by debuggers. This is particularly effective when developing and working with complex systems comprising multiple threads and interrupts: SystemView can ensure a system performs as designed, can track down inefficiencies, and show unintended interactions and resource conflicts.
|Download SEGGER SystemView package for Windows, Mac OS X and Linux|
|SEGGER SystemView documentation|
|Subscribe to SystemView software notification|
Analysing a system with SystemView
SystemView can record data from the target system while it is running. The recorded data is analyzed and the system behavior is visualized in different views.
All system information is sent by the application and is part of the recording. The information is shown in the window on the top right and includes the application name, the underlying OS, the target device and the timing information. Additional information about task switches and interrupt frequency provide a quick overview of the system.
With the Timeline and the Events window the whole system execution can be visually analyzed.
The Events window lists all SystemView events which were recorded from the system and displays information about the exact timestamp when the event was generated, in which task or interrupt context it happened, which event it is, and the details of the event. The type of events to be displayed can be filtered to show only events of interest.
The Timeline displays the interrupt and task activity, as well as scheduler activity and idle over the system time. Scrolling through the events and zooming in on the timeline provide an exact view on how the contexts are connected:
- How often do interrupts occur.
- Which interrupt starts which task.
- When are tasks or interrupts interrupted.
- When does the scheduler trigger a task switch.
- How long does it take for a task to run when it becomes ready.
- How long does an interrupt run.
The Contexts window provides run-time information about tasks and interrupts. For each item the frequency, run time information and CPU load is shown. This information can be used for profiling, to see whether the system runs evenly or not, and to get an overview where the CPU time is spent.
The CPU Load window displays the used CPU time by context over a time period. This enables analysis of how much CPU time is used when the system is active or idle and can provide an indicator for where the system might be inefficient, i.e. when interrupts happen too often or simple computations take too long.
What is SEGGER SystemView?
SystemView consists of two parts: The visualization application, which is available for Windows, Mac OS X and Linux, and some target-side code, collecting information on the target system.
Actually, there is a third part: J-Link and the RTT technology that enables this wonderful system with all of its capabilities. Although J-Link can be eliminated, it's best experienced with a J-Link.
The SystemView host application enables analysis and profiling of the behavior of an embedded system. It records the monitor data which is generated in the embedded system and visualizes the information in different windows. The recording can be saved to a file for analysis at a later time or for documentation of the system.
The monitor data is recorded via the debug interface, meaning that no additional hardware (especially no extra pins) is required to use SystemView. It can be used on any system that offers debug access.
With a SEGGER J-Link and its Real Time Transfer (RTT) technology SystemView can continuously record data, and analyze and visualize it 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 RTOS.
Cycle-accurate profiling can be performed and even user functionality can be timed.
SystemView should 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, and unexpected task changes. 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, needs to be included.
The SystemView module collects and formats the monitor data and passes it to RTT. The RTT module stores the data in the target buffer, which enables continuous recording with a J-Link on supported systems, as well as single-shot recording on any system.
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, in the RTT target buffer. Timestamps can be as accurate as 1 CPU cycle, which equates to 5 ns on a 200 MHz CPU.
What resources are required on the target side?
The combined ROM size of RTT and the SYSVIEW modules is less than 2 KByte. For typical systems, about 600 bytes of RAM are sufficient for continuous recording with J-Link. 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 needs less than 1 us for typical events (based on 200 MHz Cortex-M4 or Renesas RX CPUs), 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 done on any system supported by J-Link RTT technology. RTT requires the ability to reading memory via the debug interface during program execution. This especially includes ARM Cortex-M0, M0+, M1, M3, M4 and M7 processors as well as all Renesas RX devices. On systems which are not supported by the RTT technology the buffer content can be read manually when the system is halted, which enables 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 make file or project. If the operating system supports SystemSiew, then only one function needs to be called. In a system without RTOS or non-instrumented RTOS, 2 lines of code need to be added to every interrupt function which should be monitored.
That’s all and should not take more than a few minutes.
Modes of operation
With a J-Link debug probe and the SEGGER Real Time Transfer technology (RTT), SystemView can continuously record target execution in real time, while the target is running. This enables analysis of the system behaviour over a longer period of time without requiring a large target memory buffer.
When the target device does not support RTT or when no J-Link is used, SystemView can still record data into its buffer until it is filled. Single-shot recording offers insight to the startup sequence or event-triggered activity in any system for a decent amount of time.
Post-mortem analysis is similar to single-shot recording, with one difference: SystemView events are continuously recorded. When the target buffer is filled older events are overwritten and reading the buffer provides the latest recorded events. Post-mortem analysis can provide information of long-time system tests and helps analysing system crashes.
To use SystemView the SystemView target module has to be included in the target application and the OS needs to be instrumented. Currently embOS and FreeRTOS can be used with SystemView out-of-the-box. SystemView can also be used with a non-instrumented OS or without any OS at all.
For a detailed description of the target implementation, please refer to the SystemView User Manual UM08027.
Configuring embOS for SystemView
SEGGER embOS (V4.12a and later) can generate trace events for SystemView and other recording implementations when profiling is enabled. Profiling is enabled in the OS_LIBMODE_SP, OS_LIBMODE_DP and OS_LIBMODE_DT embOS library configurations (For detailed information refer to the embOS User Manual UM01001).
In addition to the SystemView and RTT core module, SEGGER_SYSVIEW_Config_embOS.c needs to be included in the application. This file allows configuration to fit the target system, like defines for the application name, the target device and the target core frequency. It initializes the SystemView module and configures embOS to send trace events to SystemView.
At the start of the application, at main, after the target is initialized, SEGGER_SYSVIEW_Conf() has to be called to enable SystemView.
Now, when the application is running, connect the SystemView App to the target and start recording events. All task, interrupt, and OS Scheduler activity, as well as embOS API calls are recorded when SystemView is connected or SEGGER_SYSVIEW_Start() has been called.
For a detailed description on how to configure embOS for SystemView, please refer to the SystemView User Manual.
Configuring FreeRTOS for SystemView
FreeRTOS can also generate trace events for SystemView and offers basic but useful analysis without modification.
For more detailed analysis, like Scheduler activity and interrupts, the FreeRTOS source and the used port have to be slightly modified.
For a detailed description on how to configure FreeRTOS for SystemView, please refer to the SystemView User Manual.
Using SystemView without an OS
SystemView can be used without any instrumented OS at all, to record interrupt activity and user events.
Integrating SystemView in such an application is as simple as adding three lines of code.
For a detailed description on how to configure the application and how to record interrupts, please refer to the SystemView User Manual.
FAQs & Troubleshooting
|Q:||Can I use SystemView while I am debugging my application?|
|A:||Yes. SystemView can run in parallel to a debugger and do continuous recording. To make sure data can be read fast enough, configure the debugger connection to a high interface speed (>= 4 MHz). Parallel connections to a target are currently only supported on Windows and Linux.|
|Q: ||Can I do continuous recording without a J-Link?|
|A:||No. Continuous recording requires the J-Link Real Time Transfer (RTT) technology to automatically read the data from the target. One-time recording can be done with any debug probe.|
|Q: ||Can I use SystemView with my J-Link LITE or J-Link OB?|
|A:||Yes. SystemView can in general be used with any J-Link. |
J-Link LITE and J-Link OB are limited in the debug interface speed, which can lead to overflow events when the RTT buffer cannot be read fast enough and the system creates too many events.
To get a full-featured J-Link, have a look at the purchase options.
|Q: ||Can I use SystemView with my old J-Link?|
|A:||Yes. SystemView can in general be used with any J-Link if the J-Link supports the target core. |
Older J-Links (V8 and older) might have limited RTT capability, which can lead to overflow events when the RTT buffer cannot be read fast enough and the system creates too many events.
To trade-in or upgrade your J-Link, have a look at our purchase options.
|Q: ||Can I do continuous recording on Cortex-A or Cortex-R devices?|
|A:||This is target device-dependent. RTT requires memory access on the target while the target is running. On cortex-A and Cortex-R this is done via the AHB-AP. If your target device has an AHB-AP you can continuously record with SystemView.|
|Q: ||Can I do continuous recording on ARM7, ARM9?|
|A:||No. RTT requires memory access on the target while the target is running. If you have one of these devices, only one-time recording can be done.|
|Q: ||I don't use embOS or FreeRTOS, can I still use SystemView for my application?|
|A:||Yes. SystemView can be used with any (RT)OS. |
For Task and OS execution recording your OS might have options to hook up trace/profiling instrumentation modules where you can add SystemView, otherwise the OS has to be instrumented to be able to do so. In case of doubt get in contact with your OS vendor.
If instrumenting the OS is not possible you can still use SystemView to record interrupt activity and user events.
|Q: ||I don't use any OS at all. Should I still use SystemView?|
|A:||Yes. Even without any OS SystemView can be used to record interrupt activity to verify interrupts occur as expected and to record user events which can be used to measure module execution times.|
|Q: ||I get overflow events when continuously recording. How can I prevent this?|
|A:||Overflow events occur when the SystemView RTT buffer is full. |
This can happen for following reasons:
|Q:||My application crashes when I connect SystemView. What might be wrong?|
|A:||Make sure ~200 Bytes of stack are available for SystemView in every context (Task, Interrupt, Scheduler) which can create SystemView events.|
|Q: ||I cannot start recording in SystemView. What might be wrong?|
|A:||Possible reasons are: |
|Q: ||SystemView cannot find the RTT Control Block, how can I configure it?|
|A:||Auto-detection of the RTT Control Block can only be done in a known RAM address range after it is initialized. Make sure the application startup has ran when starting to record. If the RTT Control Block is outside the known range for the selected device, either select 'Address' and enter the exact address of the RTT Control Block or select 'Address Range' and enter an address range in which the RTT Control Block will be.|
|Q: ||I receive invalid packets. How can this happen?|
|A:||Invalid packets are mostly generated by the target system due to either one of two reasons: |
1. SystemView does not correctly lock when recording an event and is interrupted by another event. In this case make sure SEGGER_SYSVIEW_LOCK() and SEGGER_RTT_LOCK() are configured correctly for your device.
2. The system goes into sleep or low-power mode and the J-Link cannot correctly access the RAM to read the SystemView buffer. It is recommended to not use WFI or any low-power mode while a debug probe is connected to the system.
|Q: ||Do I have to select a Target Device to start recording?|
|A:||Yes. J-Link needs to now which target device is connected. The drop-down lists the most recently used devices. To select another device simply enter its name. A list of supported devices can be found here.|
|Q: ||My question is not listed above. Where can I get more information?|
|A:||For more information and help please ask your question in the SEGGER Forum.|