[SOLVED] Manipulate JLINK GPIO on debug halt / exit / initialization

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] Manipulate JLINK GPIO on debug halt / exit / initialization

    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.

    The post was edited 1 time, last by LostTime77 ().

  • Assuming that you are using a Cortex-M based MCU, did you ever consider “monitor mode debugging”?
    segger.com/products/debug-prob…y/monitor-mode-debugging/

    You could have certain things up and running while debugging another part of your apllication.
    Might be a lot easier than messing around with the OnHalt() stuff where there is absolutely no timing guaranteed for the operations.


    BR
    Alex
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • 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.
  • Hi,

    Wow, this is the most inaccurate analysis I have ever seen…

    What you are describing is how all the cheap probes work (CMSIS-DAP, ST-LINK, …) and even some of the expensive ones. They are basically dumb converters and all the stuff is on the PC side.

    The smart logic INSIDE J-Link is what it distinguishes from others + the fact that some very capable people are working on it and the concepts, which makes the flash programming super fast and the out-of-the-box experience as good as it is.

    Seriously, you got the WHOLE thing completely wrong in your analysis.

    There actually IS scripting available to run on the probe itself. However, it is not really documented, as there are many constraints and you need to know exactly(!) what you are doing, as you can easily mess up your whole session with this.

    Periodic scripts that run on the probe in the background is something that is on the list.
    If you are seriously interested in this, we recommend to get in touch with SEGGER via sales / support, instead of a community forum where there is not even a guarantee to get an answer from an actual SEGGER employee.
    If there is a business case for SEGGER, we can prioritize the “background script execution” for sure. In this case, a background “IsHalted()” check that J-Link does on its own and then calls your “OnHalt()” function ASAP (whatever your timing requirements are, as you never specified them)

    So feel free to get in touch with SEGGER directly.

    BR
    Alex
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.