This may be possible or information available elsewhere, but I don't want to go sifting through the gobs of posts and would rather just ask directly. I have performed a rudimentary search already.

Our company has a use case where we are debugging an MCU using JLINK and we would like to manipulate GPIO pins of the debugger port when the JLINK halts the MCU or exits halt and goes into run. Looking at the scripting interface, something like OnBeforeHalt, OnAfterHalt, OnBeforeExitHalt, OnAfterExitHalt, etc. type of events do not exist and are not scriptable. When these events occur, we would like to write script code to write to unused GPIO pins of the JTAG / SWD port. The specifics of the code we need to write to manipulate the pins can be discussed and is not important as a start. We would just like to get something like the aforementioned events.

We have a main MCU that drives timer pins that go into a PLD drive, which ultimately drives a very large motor. What can happen is that we would like to set breakpoints, halt, and debug the code on the MCU but the MCU can be driving the timer pins at the same time that the motor is active. When you halt the code execution of the MCU, we would also like the motor to stop, otherwise it can fly away and cause damage as the timer pins are not actively being managed by the MCU code anymore (execution is halted). For our setup, we would like to manipulate an I/O pin when the debugger has halted /started the MCU. The I/O pin can go into the PLD to gate the motor drive.

The tools we are using are Segger JLINK devices (PRO, trace, etc..) and ozone.


PS. Some MCUs have the ability to "halt timers on debug". This is really not acceptable to us at all, because such a mechanism is not standardized across MCU vendors. Additionally, a lot of the time, the timer count is only stopped, but the pins can not be driven to a specific value during debug. Some chips may not have any timer debug features at all. Being able to dedicate a debug halt status GPIO that we can manipulate from the debug port would allow a standardization across all of the MCUs that we use and not have to rely on non existent vendor features. For our company, there is no guarantee we use the same MCU vendor from product to product and they all have wildly different hardware IP.

Monitor mode debugging does not fit the application. The intention is to have a failsafe way independent of software to toggle an I/O pin from a host when the chip being debugged is halted. We have given it some more thought, and based on the fact that debugging on Cortex M devices is based on polling the CPU from the debug probe, "timing can't be guaranteed". However, there is more to that story, and I think it also feeds in to how the JLINK debug mechanism is implemented.

Here is my investigation and what I think the JLINK is doing. The reason that the JLINK can support every device under the sun is because the JLINK hardware is actually very dumb. It basically only acts as a USB to SWD / JTAG converter that converts USB commands from the host into debug operations. There is no scripting capability on the debug probe itself, all of that is handled on the host side, which makes timing difficult due to host PC and USB overhead. Sure, some operations like download into RAM might be accelerated by holding more blocks of commands in an internal buffer in the JLINK hardware, but that's about it. Furthermore, 2000 new super complex cortex M devices come out from 10 manufacturers, and here we can have a 2 dollar STM32 (or other vendor) chip that has a USB interface support debugging on every one. The "smarts" are all on the PC side, where your program sizes and chip database can essentially be infinite.

If this was a case where I could reliably run a script on an MCU halt operation within say 20ms, we might still be in business, but PC overhead won't guarantee that. To that end, asking for the reporting from the chip being debugged to be timing reliable in how the JLINK operates is not going to cut it, due to the fact this application is safety critical. We are investigating a different method to do what we want that will be timing reliable without relying on the debugger.