Connecting to target by any jlink utility while debugging disables breakpoints

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

  • Connecting to target by any jlink utility while debugging disables breakpoints

    When target running under GDB Server session (with breakpoints set) I connect to target by any JLink utility (for example, just launch JLink Commander). This causes breakpoints not hit anymore until I do something with debugger (for example, just pause and continue running).

    DLL version V4.80g, compiled Feb 13 2014 20:50:02
    Firmware: J-Link ARM-Pro V3.x compiled Sep 19 2013 20:11:52
    Hardware: V3.00

    STM3220G-EVAL Rev.B board (ARM Cortex-M3)
    Windows 7 Pro SP1 64-bit
  • Hi,

    Hard to believe...
    Usually, for most Cortex-M targets having multiple connections to the same target opened at the same time should work correctly (with some limitations).
    We will check if we can reproduce this in any way.

    For reproduction:
    Could you please provide the steps we need to do?

    - Starting GDBServer session
    - Set breakpoints in GDBServer session at ... ... ...
    - Start CPU and let it hit a breakpoint
    - Start J-Link Commander in parallel
    - Start CPU in GDB session again => Next breakpoint is not hit (?)

    Correct so far?


    Best regards
    Alex
  • Correct steps to reproduce:
    - start GDBServer session
    - set breakpoints in GDBServer session (they must be triggered by timer or external events you may generate)
    - start CPU
    - let it hit a breakpoint (CPU paused)
    - continue CPU
    - start J-Link Commander in parallel
    - let breakpoint hit again (here is the problem - it will not hit)
    - pause and continue CPU
    - let breakpoint hit again (this time it succeeds)
  • Similar issue with PIC32

    This may be the same or related bug: On the Pic32 I have to do a pause and continue to get breakpoints to work at all. I guess I just got used to it since for quite a long time I've been just habitually doing this every debug session. I have many other showstoppers that prevent me from debugging (like viewing unmapped memory crashing my program) that I ignore issues like this since there's the stop/continue workaround.

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

  • I used same workaround until there was a need to perform connection by jlink software very often. It become extremely annoying.
    Right now I'm implementing dirty workaround with gdb python scripting and software breakpoint in order to automate "stop/continue" action. (It still be possible to miss breakpoints in very rare cases, but at least debugging process becomes smoother...)