Attaching to a Running Target with Segger J-Link, GDB and Eclipse

This happens several times for me: I have a board running for a while (even for days), and then it crashes or is stuck somewhere. Yes, I usually use a watchdog do recover from that situation. But it would be good to know and debug the problem. With CodeWarrior I had the functionality in the debugger to ‘attach’ or ‘connect’ to a running (stuck/crashed) board. However, with Eclipse/Kinetis Design Studio/GDB this is a different debugger, and not possible. At connection time with the debugger the target does a reset, so I don’t know any more where the application crashed. But now I have a solution, at least with the Segger GDB :-).

Debug Hard Fault Attached Target

Debug Hard Fault Attached Target


I’m using here Kinetis Design Studio V2.0.0, but it is applicable to any Eclipse with the GNU ARM Eclipse plugins and the Segger GDB Server (e.g. with J-Link debug probe or J-Link OpenSDA firmware). The goal is to be able to connect to a running target, without overwriting the application on the board (attach/connect) so the problem on the board can be inspected with the GNU GDB debugger. That means the GDB connection shall *not* reset the target as it usually does.

Update GNU ARM Eclipse Segger Debug Plugin

Verify that you have the latest GNU ARM Eclipse plugins installed. In Eclipse/KDS, use the menu Help > Install New Software and use the following update site:

GNU ARM Eclipse Plugins
I had to update the GNU ARM C/C++ J-Link Debugging plugins to the version (see above screenshot).

Segger J-Link Debug Panel

This update comes with an important feature: the ‘Connect to running target’ option is now available (it was grayed out and not functional in earlier versions).

Connect to running target

Connect to running target

Debugging and Attach

I enable the option ‘Connect to running target’ and I’m able to attach/connect to my target. Use debug as normally, the target will be shown as running), then use the ‘Pause’/Suspend button to stop the target if the target is still running:

Connected to Running Target

Connected to Running Target

I’m able to successfully attach and debug to my boards with the J-Link (EDU). I’m able to connect the J-Link (EDU) after the crash and to attach/debug it. Using the J-Link ‘Light’ version I had at least to Power the J-Link “Lite” before attaching it to the board, otherwise the board was reset by connecting the SWD/JTAG cable. I recommend you get some practice and experience hooking up the probe. Or (if you can) keep the debug probe powered/attached so you do not risk an accidental reset of the board.


With the new update and plugin I’m able to debug a crashed application and can connect to the board after the crash to find out what the status of the board is. Thanks to Liviu (the maintainer of the GNU ARM Eclipse plugins) and Segger to make this important feature work with GDB :-).

šŸ’” I think technically the same should be possible with the OpenOCD or GDB P&E Multilink, but I have succeeded doing this only with the GDB Server from Segger.

Happy attaching šŸ™‚

PS: I apologize for being silent for a month. Being overloaded with too many stuff, with rarely time at night to work on new posts. I hope things will get better soon. Stay tuned…. šŸ˜‰


26 thoughts on “Attaching to a Running Target with Segger J-Link, GDB and Eclipse

  1. As always Erich, your post is working great and I appreciate the tips-n-tricks and workarounds.
    One note for those attaching using the Segger JLink debugger conntection above….if you have breakpoints set when you attach, the code will stop if it hits a breakpoint. If you do not want to break at a breakpoint, be sure to disable the breakpoints in the Eclispe Debug perspective before trying to grab control.
    David Seymour


  2. Pingback: Updated P&E GDB Server for Eclipse: Connect/Attach and Advanced Flash Programming | MCU on Eclipse

  3. Just an aside I was able to attach to a running process using a Freedom KL25 board with USBDM firmware as a debugger. (tl;dr you can load firmware into the K20 on freedom board to turn them into a debugger to use with gdb along with the USBDM Server)

    The trick is to start gdb server. The start gdb, I used the following commands.

    >target remote localhost:1234
    >symbol-file elf_file_name.elf

    Then on the gdb server window select halt target

    You should then be able to use the GDB print print/x commands to inspect memory set break points and look at modify peripheral registers.


      • I just use GDB via the command when I need to. In this case to try and figure out why the serial port on my KL16 based device sometimes hangs.

        Far as I know USBDM works with Eclipse. I do most of my debugging interactively via a command line interface over a serial port. Since my firmware runs a frequency hopping radio, breakpoints mess up the timing.

        Biggest issue with gdb + USBDM is it doesn’t support flash breakpoints (Segger does I think). So you only get 2 hardware break points. Probably could rework the startup code to copy the code you want to debug to RAM and then debug that way.

        PS: Your blog is probably the most concentrated source of small embedded system knowledge on the internet.


      • Yes, Segger J-Link supports ‘unlimited flash breakpoints’. P&E does not. This is a great feature especially for the M0+ devices as they have (as you say) only two HW breakpoints).

        PS: thanks šŸ™‚


  4. What is the connection procedure for debugger because usually whenever you connect a debugger, the target resets. How to avoid reset?


  5. Erich, thank you for this post, this extremely valuable.
    I’m using OpenOcd, KDS and already succeeded to debug a running target with this set up. Then, it’s possible with OpenOcd, by disabling load executable option at debugger configuration, enabling debug in RAM and disabling Initial Reset. Works great.

    However, i have a question about this:
    I’m facing a challenging situation, since i’m trying to this procedure to a running target that keeps resetting every 5s.

    So, is there a way to start a debug session in this condition? Maybe, make the lauching faster to stop at a breakpoint before it resets?

    Thank you for your help.


    • I’ve had this sort of problem before. A trick I’ve used in the past is to put a variable in the no init section in ram.

      uint32_t last_line __attribute__ ((section (“.noinit”)));

      And then in the code can set

      last_line = __LINE_;

      AT the begining of the code check if the reset is due to a normal power up or something else. If something else, jump to a safe while loop. Hopefully then you can attach and check the value in last_line. You can then perhaps see where the problem happen.

      I also have this in the fault handler. If you a bus fault, fault_pc may tell you where the illegal access was. use arm-none-eabi-addr2line.exe to find the line in the code that matches the address.

      uint32_t fault_pc __attribute__ ((section (“.noinit”)));

      // Handle hard faults: print debugging information and halt
      static void __attribute__((naked)) HardFault_Handler(void)
      // Set up arguments and invoke _HardFault_Handler()
      asm(“mov r0, lr\n” // Arg 0
      “mrs r1, psp\n” // Arg 1
      “mrs r2, msp\n” // Arg 2
      “b _HardFault_Handler\n”);

      void __attribute__((naked)) _HardFault_Handler(uint32_t lr, void *psp, void *msp)
      hw_stackframe_t *frame;

      // Find the active stack pointer (MSP or PSP)
      if(lr & 0x4)
      frame = psp;
      frame = msp;

      fault_pc = (intptr_t) frame->pc;

      // if pc is 0 likely a null function pointer
      if(fault_pc == 0)
      // get return address
      fault_pc = (intptr_t) frame->lr;


      • The system initialization at startup code need RTC to proceed?
        Thank you for your attention, Erich.


      • Hi Diogo,
        no, the startup code does not need the RTC. But if you have configured the hardware to use the RTC, the RTC needs to be properly powered (e.g. with a battery), otherwise the mikrocontroller will generate a hard fault.
        Or in other words: using the RTC without battery power and without clocking the RTC will cause a hard fault. This is expected behaviour of the Kinetis.


      • I did see an access to a RTC register at system init. This access with the RTC not powered properly could cause this fault and, hence, the reset?


    • I pretty much stopped using OpenOCD because at least for me it was extremely slow and unreliable. With P&E or Segger I can connect to a target in less than a second, so I don’t phase that problem. I’m not sure what target you are using, but I recommend you give a try with the Segger J-Link: it is available for non-commercial usage for $20 in the EDU version (J-Link MINI EDU).


      • I agree. I am now able to start a debug session in a second with Multilink probe and P&E. My target is a K64F.
        However, i believe breakpoints are not workint properly since, after the bootloader jumps to the application, it does not stops at main function. So i tried to track it down at startup code but the flow there does not make any sense.

        Gibbon1, actually this is very interesting, However, i can’t make any change in the code cause i want understand this crash that happens to a very few targets, also this its hard to reproduce. Thank you for your help even so.


      • If the code flow does not make any sense, then most likely the debug information somehow is not correct (maybe outdated binaries or it uses the wrong .elf for the debug information).
        As for the breakpoints: there is a limit of 4 to 5 in the hardare, so don’t set too many breakpoints.


      • That was actually a hardware issue. Somehow, the RTC battery is causing only the application to crash, even bootloading working fine.
        Works properly after replacing RTC battery.
        Another question yet about the debugger: Is there a configuration to trigger an initial reset for a P&E debug session? I didn’t see any.


      • Hi Diogo,
        what kind of reset? To my knowledge the P&E probe pulls down the reset line on the SWD connector at reset if you have ‘connect to running target’ disabled in the ‘Startup’ tab of the debug connection.


      • Tracking down with debugger led me to a line at start up code that is a branch instruction to system init. However, stepping into this branch does not goes to the to system init, instead it goes to a FreeRtos piece of code. I have no clue whyt this happens, also it gets into an if statement AND an else, so it should be a debug error. After this it resets again due to a hardfault i believe.
        I did the same procedure at a working running target and i was able to see the flow going to the system init.
        Now, i’m trying to figure out why this issue is related to RTC.

        Thank you, Erich!


      • Does the assembly code shown in the disassembly view make any sense? If the assembly code makes sense, it means that the debugger uses the wrong debug (DWARF) information from the .elf file, or the wrong .elf file.


      • Erich, thank you very much for all attention. Multilink debug probe and P&E saved the day!


What do you think?

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s