Monitor mode debugging

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.

• Target application has a CAN bus part where halting the CPU would cause messages to get lost. In monitor mode, the CPU is able to handle incoming messages while the main application is halted.

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.

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.

For the best debug experience we recommend using Embedded Studio or Ozone.

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.