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 communication links have to stay 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.
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.
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 firstname.lastname@example.org. Currently, the following CPUs are supported for 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 been 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 is available upon request from email@example.com.
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.
I Am Using SEGGER RTT, Can I Still Use it with Monitor Mode Debugging?
A: Yes, RTT works seamlessly with monitor mode debugging. No changes on the debugger nor on the application side are necessary to support it.
I Am Using CPU XXX which Incorporates a YYY Core. Can Monitor Mode Debugging Be Supported?
A: If the CPU core is not listed above, please feel free to get in touch with firstname.lastname@example.org to check if monitor mode debugging support can be added for this CPU.