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.

emCrypt

emLib

Internet of Things

Secure, connected, embedded devices build with SEGGER solutions

Software IP components from SEGGER such as emSSL, emSSH, emSecure Crypto libraries, HTTP Web server, and embOS/IP to name a few, can be used as foundations for your securely, connected IoT device. Our software works on any MCU.

Flasher ST7

Flasher ATE

Flasher ATE is an in-circuit-programmer for high volume mass production. The interfaces to start and monitor the programming tasks have been designed with the implementer of the production system in mind.

Monitor Mode Debugging

Monitor mode debugging describes the capability of the CPU to maintain essential functionality while being debugged.

Monitor mode debugging describes the capability of the CPU to maintain essential functionality while being debugged. This is particularly important when hardware such as a motor has to keep running, or to keep communication links connected. The default debug mode for most common CPUs is "halt mode debugging" where the CPU halts on a debug request, causing the user application and, depending on the CPU, also peripherals to stop execution. However, for certain applications and environments it may be necessary that parts of the user application continue execution while the CPU is in debug mode and the user is debugging another part of the application. This is where the new feature monitor mode debugging provides essential improvement.

Resources

Sample Scenarios

There are several use-cases where monitor mode is the only convenient way to debug an application:

Target application has a motor control part which makes use of Pulse-width modulation (PWM), and the PWM units also stop when the CPU is halted, possibly leaving the PWM unit and motor control in an undefined or even dangerous state. Monitor mode debugging allows the PWM part of the application to keep running while the rest of the application is halted and can be debugged.

Target application has a Bluetooth part where halting the complete target application would cause the Bluetooth communication to break down. Monitor mode debugging allows the Bluetooth "keep-alive" interrupt(s) to run and handle the low-level Bluetooth communication while the rest of the application is halted and can be debugged.

Target application has an Ethernet part where halting the CPU would cause the IP stack etc. to become totally unresponsive, so packets cannot be received anymore, even keep-alive packets etc. Monitor mode debugging allows the developer to debug in this scenario, too.

How it Works

In contrast to halt mode debugging, in monitor mode debugging the target CPU does not halt on a debug request but takes a debug interrupt instead and jumps to a specific debug interrupt handler which then handles the communication with J-Link and also some low-level application maintenance that may be needed to be done while the application is halted. So technically, the CPU is still running and executing the code while the application itself is halted, allowing it to still handle some interrupts as well as some synchronous maintenance operation that can be done within the monitor code.

The monitor code consists of the following parts:

A generic monitor that handles communication with J-Link. This part is delivered by SEGGER and should not be modified by the user.

A custom monitor part providing some functions that can be filled in by the user. SEGGER delivers a template for this part.

The custom monitor part provides the following functions where the user can add functionality/maintenance which needs to be done in debug mode:

JLINK_MONITOR_OnExit(): Called once just before leaving the monitor and restarting the target application.

JLINK_MONITOR_OnEnter(): Called once just before entering the monitor. Target application is already stopped at this point.

JLINK_MONITOR_OnPoll(): Called periodically while the CPU is in debug mode.

The monitor modules simply need to be compiled, linked and downloaded with the application. For limitations to what can be done in the different functions of the custom monitor part, please refer to the J-Link User Guide.

Supported CPUs

Whether monitor mode debugging can be supported for a specific device depends on whether the CPU architecture defines monitor mode support or not. In case of doubt if a specific CPU is or can be supported, please get in touch with supportsegger.com. Currently, the following CPUs are supported for monitor mode debugging:

Cortex-M3

Cortex-M4

Cortex-M7

The Debugger / IDE Side

On the debugger / IDE side, no changes are necessary to support the monitor mode debugging. The IDE will recognize no difference between the default halt mode debugging and monitor mode debugging.

Considerations / Limitations

There are some considerations / limitations that need to be taken account of when using monitor mode debugging, for example that the monitor itself as well as the periodic actions it performs cannot be debugged. For a more detailed description of considerations in monitor mode debugging, please refer to the J-Link User Guide UM08001.

Monitor for Other IDEs Than SEGGER Embedded Studio

As the monitor is written in assembly, it slightly differs from compiler to compiler. It has ported to the following compilers/IDEs so far:

SEGGER Embedded Studio (GCC)

Any GCC based environment (GCC)

IAR EWARM (IAR ARM compiler)

Keil MDK-ARM (ARM compiler)

The monitor for SEGGER Embedded Studio is available via the sample project above. The monitor port for other compilers / IDEs than SEGGER Embedded Studio are available upon request from supportsegger.com.

Sample Project

In the following, a sample project for SEGGER Embedded Studio can be downloaded that demonstrates:

How to use monitor mode in Embedded Studio

How to have a specific interrupt keep firing while the main application is halted and the monitor is active

For more detailed explanations how to bring the project up and running on a specific hardware, please refer to the readme that comes with the project.