I may be a microcontroller guy myself, but there are times where you need the power of a microprocessor. Having an operating system handle the memory, peripherals and events just saves time, and some applications really do need the power a microprocessor provides.

Atmel’s SAMA5D3 family has some impressive devices. Based on ARM’s A5 architecture, they has an impressive amount of peripherals and I/O lines. To name just a few, the SAMA5D36 has 3 I2C ports, 6 SPI ports, 12 12-bit ADC channels, and something you don’t see every day, 7 UART ports. This is impressive enough, but to add to that, the SAMA5D3 also has up to 160 I/O pins, each with its own interrupt. The SAMA5 series is geared towards industrial environments, automotive devices, and with Atmel’s implementation of capacitive touch peripherals, it can be used on just about any application where a user must input data.

With all that power, it isn’t surprising that the German manufacturer emtrionused this processor for one of their development boards, the SBC-SAMA5D36. They not only went with the SAMA5D36 device for its power and reliability, but also for Atmel’s reactivity when it comes to support. Atmel has worked hard on Linux implementation, and so the Linux kernel has everything you need to access every part of the processor, but I’ll get into that later on.

System configuration

With the amount of peripherals on the SAMA5D3, Emtrion spent a lot of time thinking about what to place on their board. Their approach is an industrial system that can be used on a wide range of applications. It has 2 CAN ports, 3 I2C ports, one SPI and 5 UARTs. It also has 2 Ethernet connectors (one 100Base-TX and one 1000BaseT), 2 USB host ports, and one USB device port. It also has 5 PWM outputs, and 52 digital GPIO lines.

To access the serial port, an FDTI connector is available, placed just outside the expansion board location. Basic debugging won’t be a problem, but for more advanced debugging, a debug port is also present on the board. Video output is also available in the form of an HDMI connector, and a separate TFT connector is also present beneath the board.

Unfortunately, the LCD screens I had weren’t compatible, since they are all fairly specific designs, but it isn’t hard to find a screen for the SBC-SAMA5D36, it uses the EDT specification. Currently, there are no EDT displays with a resolution higher than 800×480.

One very nice addition is the LiPo charger. It is possible to power the entire board from a LiPo battery, and to charge it when main power is present.

Hands on

I received a parcel, and I was excited, because I knew what was in it. Slight irony of this story, the parcel actually arrived damaged; the transporter had “technical difficulties” (nothing to do with emtrion). Since the parcel was waterlogged, I was considering refusing delivery and requesting a new sample to try out; after all, I wanted to be able to test this beast under the best conditions possible. Still, I was too excited, so I decided to try it out anyway. I wasn’t disappointed.

The board itself is professionally built. It is solid, it feels great in your hand, and doesn’t have any rough edges. The board is neatly cut, not snapped off a larger structure. That might sound strange, but embedded engineers know all too well the joys of snapped boards creating short circuits and strange behaviour when placed in a metal box. That won’t happen. The components are very well soldered, and everything just feels robust. This is a board I wouldn’t hesitate to put in an industrial environment.

Two connectors are available on the board, placed in parallel. Using standard 2.54mm spacing, it is easy to create your own extension board, or to place ribbon cables to another board. The layout is well thought, and offers quite a few possibilities. Emtrion have just released their first expansion board, the SBC-EXT1, offering a way to access the impressive amount of serial I/O.


The board itself booted up perfectly, despite rough handling. It took just a few seconds to get a Linux console, and full access to the system. The Debian based system that came pre-installed isn’t the fastest system available, but is an excellent way to familiarize yourself with the system. It was very complete, not just a barebones system that offers little in the way of debugging and profiling. Need a new package? Just install it.

Since the board also comes with a micro-SD slot underneath, it seems logical that you can also place a Linux distribution on an SD card. On the Emtrion download page, another Linux distribution is available, and this one is much faster, and boots in a fraction of the time. When you need the support of a full Linux distribution, you have it, and when the time has come to test your code in a more embedded-based distribution, it takes minutes to set up. Both environments come with a fully populated /dev folder, you don’t need to spend time developing drivers for the on-board hardware; everything is included. Everything seems to have been designed around ease of use and fast development time.

Power consumption

Based on Atmel’s SAMA5D3 range of Cortex-A5 processors, the ARM architecture means that this device is very energy efficient. According to emtrion, the maximum current usage is 160mA with no LCD screen, and when the Ethernet ports are disconnected. While running very inefficient code, I got typical readings of anywhere between 120 and 140mA. It shouldn’t be too hard to make a very efficient device.

When using an LCD screen and Ethernet ports, the maximum consumption is estimated at 300mA, but I was unable to test this.

The processor integrates a Power Management Controller, allowing the programmer to modify or stop clocks to various peripherals, saving energy. The processor can also be put to sleep, and can wake up on an external interrupt, or an RTC alarm.


One aspect of embedded systems that is often neglected is security. If your project requires months (or years) of R&D, then you must protect that somehow. The SBC-SAMA5D36 can boot from a large amount of peripherals, starting from on-board NOR, then from a micro-SD slot, then NAND. If this isn’t sufficient, it can also boot from SPI, or an I2C EEPROM. While nice to have, this is typically a problem when attempting to secure designs. Fortunately, emtrion have also thought about this, and have clearly documented the way to accomplish this by writing data to a CPU register.

The processor also includes three peripherals for boot security. On-board AES and Triple DES allow for fast encrypting and decrypting of data, and a True Random Number Generator allows random number generation that does not depend on any algorithm, enhancing security.

Finally, the SBC-SAMA5D36 also has a fuse box, 192 of which are available to developers.


emtrion, the designers and makers of the board, have done an excellent job with the hardware, but that is only part of the project. They work hard to create an entire Linux based system, and offer a complete development environment already installed, not a set of tools that takes hours to configure correctly because of system dependencies. Your development team will be up and running in no time, using a virtual machine image available for developers. They also provide a complete set of documents for the board itself, from electrical characteristics to marketing support.

fit-400x320 (1)

emtrion goes a step further with the SBC-SAMA5D36. Looking on their website, some details were slightly vague; the SDRAM is listed as 256-512MB, and the NAND chip even more so, 512-2048MB. I soon understood why. emtrion’s question to its clients is simple: what do you need? We can help. If you need more NAND, we can do that. It isn’t just a simple option, but a dialogue. They even go beyond that – do you need more I/O? Need a change to the board? Let’s talk, we can find a solution together.


I’ve had this board for a few weeks now, and I’ve had a lot of fun with it. The SBC-SAMA5D36 is just begging to be used. The robust build, the excellent component layout, and the impressive I/O that the board offers makes it an ideal system for industrial systems.

The build is robust, and I wouldn’t hesitate a second before putting it into an industrial environment.The standard version of this board can operate in temperatures from 0 to 70°C, but an even more robust version is available, without HDMI, and able to operate at -20 to 85°C.That’s nice to have; I’ve worked on embedded systems that were to be deployed in rough terrain, one of the missions was in Alaska. This board can handle that without any problem. In fact, apart from one mission where a quad-core processor was required, I don’t think I’ve worked on a project that this board couldn’t have handled.

The choice of processor is an excellent one. The SAMA5D3 has an impressive amount of peripherals, and has a good balance between peripherals and energy efficiency. The Cortex-A5 is a great processor for industrial systems, and while it isn’t the fastest ARM design available, that isn’t what is required here; it is the smallest ARMv7 chip. It is still fast though, supporting ARM NEON and including an FPU.

The emtrion SBC-SAMA5D36 has an impressive amount of communication channels, and I’ve worked on some industrial systems where we were limited by the amount of serial input and output, and I would have loved to have this board to help out. No more switching between SPI and UART just to be able to communicate with the devices, this board can handle just about anything. And once again, if you do need more I/O, emtrion is always ready to talk to see how they can help out.

About the author

James A. Langbridge is an R&D Engineering consultant. In his role as an embedded systems consultant, he helps people and companies develop ARM-based systems and optimize code. He has been working in embedded systems for over 10 years in the aviation, defence, industry, and telecom sectors. His expertise includes bootloader coding, system initialization, and code optimization. When not on contract, he can be found creating new gizmos, much to the dismay of his partner, and scribbling notes for a new book project. He is the author of Professional Embedded ARM Development, and Arduino Sketches: Tools and Techniques for Programming Wizardry.


embOS-MPU offers memory protection on top of the well-proven real-time operating system embOS. It significantly enhances both stability and safety of your embedded applications and thereby also simplifies any certification process. Due to a fully compatible API, existing embOS applications may be adapted to embOS-MPU with minimal effort.

embOS-MPU can be used in any application from battery-powered, single chip products to systems demanding ultra-fast response, flexibility and multiple tasks. Typical fields include, but are not limited to medical equipment, automation, avionics, and further safety-critical applications.


  • Comprehensive memory protection
  • Suitable for any safety-critical application
  • Available for any microcontroller containing a hardware memory protection unit or memory management unit
  • Simple and straightforward runtime configuration
  • Easy to integrate in both new and existing products
  • Supports device drivers for full control of peripheral accesses
  • MISRA-C:2012 compliant

pdf Documentation download

Subscribe to embOS software notification


HTML Release Notes

Basic concepts of embOS-MPU

What is memory protection?

Memory protection is a prevalent mechanism to control memory access rights and is part of most modern processor architectures and operating systems. The main purpose of memory protection is to avert specific tasks from accessing memory that has not been allocated to them, thus preventing possible bugs or even malware contained in one task from affecting the entire system.

In order to achieve this, application tasks that could possibly affect other tasks or the OS itself must be restricted from accessing the whole memory, special function registers and the OS’s control structures. For example, tasks that execute third-party code may be considered unsafe and should be restricted accordingly. Such application tasks must not run on the same privilege state as the OS, which runs in fully privileged mode and has access to all memory, peripheral and CPU features. Instead, these tasks must run in unprivileged state and have restricted access to specific memory locations only.

What is embOS-MPU?

embOS-MPU uses the hardware’s memory protection unit as well as additional software mechanisms implemented with embOS-MPU to prevent one task from affecting the entirety of the system. This guarantees that even in case a bug occurs in one task, all other tasks and the operating system itself continue execution.

With embOS-MPU, all privileged tasks have full access to the whole memory. An unprivileged task, however, has specific access permissions to each distinct memory region. In order to access peripherals, additional memory locations and OS control structures, device drivers as well as specific embOS API may be called from within an unpriviliged task.

An application based on embOS-MPU therefore consists of two distinct parts:

  • The first part runs in privileged state: it initializes the MPU settings and includes the device drivers.
    This part contains critical code and must be verified for full reliability.
  • The second part is the application itself, which does not need to or in some cases even cannot be verified for full reliability.
    As it runs in unprivileged state, this part cannot affect the complete system.

Working with unprivileged tasks

By default, a newly created unprivileged task has read access to RAM and ROM, but may execute code in ROM only, while write access is restricted to its own task stack. In order to access peripherals, additional memory locations and OS control structures, device drivers as well as specific embOS API may be called from within an unpriviliged task.
Access to peripherals

In a default configuration, an unprivileged task has no access to any peripheral. A specific device driver is necessary to access peripherals from within such task, e.g. for using a UART, SPI, or port pins. Device drivers can be provided by SEGGER, but in most cases will be implemented by the user.

With embOS-MPU, a device driver consists of two parts: one part runs in privileged state and the other part runs in unprivileged state. The actual peripheral access is performed in the privileged part only, and embOS-MPU ensures that there is only one explicit and safe way to switch from the unprivileged part to the privileged one.

Access to further memory regions

An unprivileged task may be granted access to additional memory regions, e.g. when a task needs to write LCD data to a framebuffer in RAM and a device driver is deemed inefficient for this purpose. Access permissions are fully configurable in regards to read access, write access and code execution.

Access to OS objects

An unprivileged task has no direct or indirect write access to embOS objects. However, indirect write access to these objects via embOS-MPU API may be granted for each individual object. This requires all objects to be created in privileged state.

MPU violation management

In case an unprivileged task violates its access restrictions or otherwise triggers a fault exception, it is automatically suspended and an optional user callback function is executed to inform the application about this. This callback may also perform further actions in regards to that task, e.g. restarting it or even terminating it completely.


Supported cores and compiler

The following list gives an overview on cores and compilers which are currently supported by embOS-MPU. We are continously adding new targets. However, if your device is not in the list, we are able to port the system to your target, ensuring high quality and extensive testing. Please feel free to contact us at info@segger.com.

Core Compiler / IDE embOS
 Cortex-M Segger Embedded Studio embOS-MPU Cortex-M ES

Trial version

Download an embOS-MPU trial version and get your first application running within a few minutes!.

embOS-MPU API functions

The table below lists the available embOS-MPU API functions.

 Function Description
OS_MPU_Enable() Enables embOS-MPU.
OS_MPU_EnableEx() Enables embOS-MPU and sets the MPU API list.
OS_MPU_ConfigMem() Configures RAM/ROM and OS regions.
OS_MPU_SetAllowedObjects() Sets a list of allowed OS objects.
OS_MPU_AddRegion() Adds an additonal memory region.
OS_MPU_SetErrorCallback() Sets the error callback function.
OS_MPU_SwitchToUnprivState() Switches a task to unprivileged state.
OS_MPU_SetDeviceDriverList() Sets the device driver list.
OS_MPU_CallDeviceDriver() Calls a device driver.
OS_MPU_GetThreadState() Returns the privilege state.
OS_MPU_ExtendTaskContext() Extends the task context for MPU registers.

emlib-crc.html Detailed descriptions of all functions can be found in the embOS-MPU documentation.

Example application

The following example shows the ease of use of embOS-MPU. Furhermore, it provides a good starting point for your application.

#include "RTOS.h"
#include "BSP.h"
#include <stdio.h>

*       Static data

// Task-control-blocks.
// Task stacks. With Cortex-M MPU, stack for unprivileged tasks
// requires alignment.
static OS_STACKPTR int StackHP[128];
static OS_STACKPTR int StackLP[128] __attribute__ ((aligned (512)));
// Linker symbols to get section addresses. embOS-MPU needs to know
// where RAM, ROM and the OS section are located.
extern unsigned int __FLASH_segment_start__;
extern unsigned int __FLASH_segment_size__;
extern unsigned int __RAM_segment_start__;
extern unsigned int __RAM_segment_size__;
extern unsigned int __os_start__;
extern unsigned int __os_size__;
// User callback function which is called when an unprivileged
// task violates its access permissions.
static void _ErrorCallback(OS_TASK* pTask, OS_MPU_ERRORCODE ErrorCode) {
  printf("%s has been stopped due to error %d\n", pTask->Name, ErrorCode);
  OS_TerminateTask(pTask);  // Terminate the violating task

*       Local functions

static void _HPTask(void) {
  while (1) {

static void _LPTask(void) {
  OS_MPU_SwitchToUnprivState();  // Switch task to unprivileged state
  while (1) {

*       Global functions

int main(void) {
  OS_IncDI();                      /* Initially disable interrupts  */
  OS_InitKern();                   /* Initialize OS                 */
  OS_InitHW();                     /* Initialize Hardware for OS    */
  BSP_Init();                      /* Initialize LED ports          */
  // Setup embOS-MPU:
  // 1. Configure memory information, must be done before first task is created.
  // 2. Set optional error callback function.
  // 3. Enable embOS MPU support.
  OS_MPU_ConfigMem((OS_U32)&__FLASH_segment_start__, (OS_U32)&__FLASH_segment_size__,
                   (OS_U32)&__RAM_segment_start__,   (OS_U32)&__RAM_segment_size__,
                   (OS_U32)&__os_start__,            (OS_U32)&__os_size__);
  /* You need to create at least one task before calling OS_Start() */
  OS_CREATETASK(&TCBHP, "HP Task", _HPTask, 100, StackHP);
  OS_CREATETASK(&TCBLP, "LP Task", _LPTask,  50, StackLP);
  OS_Start();                      /* Start multitasking            */
  return 0;

SEGGER SystemView

Real-time analysis and visualization

SEGGER SystemView is a real-time recording and visualization tool that exposes 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.


  • Minimal intrusive.
  • Free tool. No license costs, no hidden fees.
  • RTOS task, resource, and API tracing.
  • Interrupt tracing for bare metal systems without an RTOS.
  • Continuous real-time recording and live analysis with J-Link and SEGGER RTT technology.
  • Live analysis of captured data — view responses to stimuli in real time without stopping the target!
  • embOS, embOS/IP, and FreeRTOS API call tracing as standard.
  • Can be adapted to other RTOS using a fully documented API.
  • Works on any CPU.
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 SystemViewer, 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 SystemViewer 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 SystemViewer 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 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 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

Continuous recording

With a J-Link debug probe and the SEGGER Real Time Transfer technology (RTT), SystemViewer 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.

Read more…

Single-Shot recording

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.

Read more…

Post-Mortem Mode

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.

Read more…


Supported (RT)OSes

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, SystemViewer can connect to the target and start recording events. All task, interrupt, and OS Scheduler activity, as well as embOS API calls are recorded when SystemViewer 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 SystemViewer while I am debugging my application?
A: Yes. SystemViewer 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).
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.
Can I use SystemViewer with my J-Link LITE or J-Link OB?
A: Yes. SystemViewer 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.
Can I use SystemViewer with my old J-Link?
A: Yes. SystemViewer 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.
Can I do continuous recording on Cortex-A, Cortex-R or 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.
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.
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.
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:

  • J-Link is kept busy by a debugger and cannot read the data fast enough.
  • The target interface speed is too low to read the data fast enough.
  • The application generates too many events to fit into the buffer.

To prevent this:

  • Minimize the interactions of the debugger with J-Link while the target is running. (i.e. disable live watches)
  • Select a higher interface speed in all instances connected to J-Link. (i.e. The debugger and SystemViewer)
  • Choose a larger buffer for SystemView. (1 – 4 kByte)
  • Run SystemViewer stand-alone without a debugger.
Q: My application crashes when I connect SystemViewer. 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.
I cannot start recording in SystemViewer. What might be wrong?
A: Possible reasons are:

  • J-Link or target is not connected: Make sure all connections are okay.
  • The target is not running: Make sure the target is running, otherwise connection might fail or the RTT Control Block can not be found.
  • The SystemView module is not configured: Make sure the SystemView module is included in your application and SEGGER_SYSVIEW_Conf() is called at the start of the application.
  • The J-Link Software is out-of-date: Make sure you have the latest J-Link Software and Documentation Package installed.
SystemViewer 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.
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.
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.

SEGGER J-Links are the most widely used line of debug probes available today. They’ve proven their worth for more than 10 years with over 400,000 units sold, including OEM versions and on-board solutions. This popularity stems from the unparalleled performance, extensive feature set, large number of supported CPUs, and compatibility with all popular development environments.

Following strict, yet efficient coding and documentation standards, we created and developed a feature-rich, high-performance family of middleware with a very small footprint and outstanding documentation.

Firmware for ST-LINK on-board

SEGGER offers a firmware upgrading the ST-LINK on-board on the Nucleo and Discovery Boards. This firmware makes the ST-LINK on-board compatible to J-Link OB, allowing users to take advantage of most J-Link features like the ultra fast flash download and debugging speed or the free-to-use GDBServer.


  • Fully compatible to and same features as J-Link OB
  • Wide range of IDEs are supported
  • Virtual COM port (VCOM) support


SEGGER created a firmware which runs on the ST-LINK on-board, making it J-Link compatible. In order to make use of this firmware, the following Terms Of Use must be accepted:

  • The firmware is only to be used with ST target devices. Using it with other devices is prohibited and illegal.
  • The firmware is for use with evaluation boards only. It is not for use with custom hardware.
  • The firmware may only be used for development and/or evaluation purposes. It may not be used for production purposes.
  • The firmware is made available without any warranty and without support.

If there is any doubt if a certain use may be considered within the foregoing scope it is strongly recommended to consult SEGGER prior to use.
When starting a debug session, the following license dialog shows up which must be accepted in order to be able to work with ST-LINK on-board:


The firmware making the ST-LINK on-board J-Link compatible has some limitations in contrast to an original, industry leading SEGGER J-Link:

  • May be used with ARM based ST devices only
  • Only debugging on evaluation boards is allowed. Debugging on custom hardware is not supported and not allowed
  • No production flash programming support
  • Unlimited breakpoints in flash available for evaluation only
  • No support is given

By using an original SEGGER J-Link PROJ-Link ULTRA+ or J-Link PLUS, all these limitations will be gone. Learn more about J-Link.

Compatible Evaluation Boards

The following eval boards have been tested with the J-Link OB firmware and are known to be working. Other eval board may work as well but are not guaranteed to do so. In case of doubt, please consult SEGGER.

  • NUCLEO-F030R8
  • NUCLEO-F031K6
  • NUCLEO-F042K6
  • NUCLEO-F302R8
  • NUCLEO-F303K8
  • NUCLEO-F334R8
  • NUCLEO-L031K6
  • NUCLEO-L053R8
  • STM32F0308-DISCO
  • STM32F3348-DISCO (32F3348DISCOVERY)
  • STM32F411E-DISCO
  • STM32F429I-DISCO
  • STM32F469I-DISCO
  • STM32F746G-DISCO
  • STM32L0538-DISCO (32L0538DISCOVERY)
  • STM32L100C-DISCO
  • STM32L476-DISCO

Getting started with ST-LINK on-board

In order to get started with ST-LINK on-board and upgrade it to a J-Link OB, just a few steps are necessary:

  • Make sure that the ST-LINK USB drivers are installed: Download
  • Make sure that the J-Link software package V5.12b or later is installed: Download
  • Download the SEGGER STLinkReflash utility: Download
  • Start the STLinkReflash utility
  • Agree to the license terms

  • Connect ST-LINK on-board to PC
  • Select “Upgrade to J-Link”
  • Wait for operation to complete

  • Quit the STLinkReflash utility


Restore ST-LINK on-board firmware

If, for whatever reason, the original ST-LINK firmware shall be restored and the ST-LINK on-board is already running the J-Link firmware, this can be achieved via the STLinkReflash utility:

  • Start the STLinkReflash utility
  • Agree to the license terms

  • Connect ST-LINK on-board to PC
  • Select “Restore ST-Link”
  • Wait for operation to complete

  • Quit the STLinkReflash utility

Our auxiliary converters can be configured and observed through a flexible webserver application running on keil rtx. The user interfaces are created dynamically from the target. All firmwares can be updated via the browser and no further or special software is neccessary for maintenance and diagnosis.

The controller hardware consists of multiple embedded systems that are connected by a proprietary CAN protocol. The STM32 controllers may also have additional external FPGAs for high performance control alogrithms and data analysis. The ARM arhitecture is a reliable and proven hardware basis and allows fast and reliable software solutions for complex and flexible tasks.