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…. šŸ˜‰


11 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?


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