Monitor Mode Debug (MMD) ?

STLink is only slightly more than a USB-JTAG/SWD converter, think of USB-SPI converter. So the answer is, it can, but whether it does depends on the PC-side software.

JW

From description, looks like it requires cooperation from the software on the target: the host debugger sends some request to the target to enter that mode.

-- pa

Yes, it does require some code on the Target.

Segger's page says, "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."

https://www.segger.com/products/debug-probes/j-link/technology/monitor-mode-debugging/

So, presumably, there must be some "smarts" in the JLink itself ... ?

Andy,

(To avoid confusion what is "debugger", I'll call the hardware which is usually USB-to-SWD, "gadget").

Segger needs selling points for their "gadgets", ST needs not, so ST-Link is fine with rudimentary functionality.

And JLinks are not created equal, either:

> Do all J-Links support Monitor Mode Debugging?

> A: No, Monitor Mode Debugging is only supported by J-Link PLUS, PRO, ULTRA+, and J-Trace.

> J-Link BASE and on-board J-Links cannot be used for Monitor Mode Debugging.

Technically, there are layers of communication in the whole debugging shebang - think of raw SPI; then device with registers and a protocol in SPI to read and write from/to thoser registers; then sequences of reads and writes to achieve a certain functions of that device; then a layer for a GUI to be able to perform sequences of those functions.

Normally, the on-chip debugger stops the processor core and talks to its peripherals (buses) through a handful of registers. In monitors, the core is not stopped (the debug ISR, i.e. code executed on a running mcu) and that code talks to PC. You can write your own monitor, talking to PC e.g. through an UART - the Cortex-M have enough on-chip hardware to support breakpointing and single-stepping using just that debug ISR.

So, in this MMD, it's the same debug ISR, except that the code from Segger added to your application talks somehow to the debugger - I guess through mailboxes in the memory (I don't have time to investigate the details). Both the "stop core and access internals through buses" and "talk to monitor through mailbox" can be implemented in the "gadget's" mcu, and merge them to a single protocol on the PC-side of the "gadget".

But this is not the only way to do things. That where is the dividing point and how much of this layered cake is in the PC/IDE side and how much in the "gadget", is upon the system's designer. I am not an expert, but in the open-source world tools attached to ST-LINK I would expect that the functionality you describe can be implemented in OpenOCD. Now if you don't want to do that yourself and want to consult and/or are willing to pay $$$$ this may take to implement, contact me off-forum and I'll get you into touch with a friend of mine who has extensive experience with various debugging arrangements, including STLink and the open-source toolchain; and has written monitors in the past, among others also for pre-Cortex ARMs. But I guess you'll be better off, both time- and money-wise, by simply using the other debugging methods.

Jan

As Keil are also in the $$$ range for both the "gadget" and its associated tools, it seems surprising to see that they don't seem to have anything like this ...

Allegedly, the ST-Link v3 does have it

:smiling_face_with_smiling_eyes:

though ST seem strangely reluctant to give any details

:unamused_face:

https://blog.st.com/stlink-v3set-in-circuit-debugger-programmer/#comment-4552578664