Attach to running target using SEGGER J-Link

Posted by Mattias Norlander on Jun 30, 2015 2:08:00 PM


Atollic technical support team are often asked how to make Atollic TrueSTUDIO connect to a running target in order to troubleshoot a crashed CPU. This article shows, step-by-step, how to connect to a running target without restting it.

This approach is useful when trying to resolve problems which occur at rare occasions, often after several days of running your embedded application, by connecting Atollic TrueSTUDIO debugger via JTAG/SWD the embedded target using a SEGGER J-Link.

Finding the root cause of the problem in case of a CPU crash is further simplified by learning how to use the Fault Analyzer view. White paper and Video tutorial is provided!


This article should be applicable to any TrueSTUDIO Lite/Pro user who has a SEGGER J-Link/Trace debugger. Before trying this approach you must consider whether halting your application in the wrong state could potentially harm your hardware (i.e. in the case of a motor controller application). Why? When GDB connects to the SEGGER J-Link GDB-server the target CPU will be halted. This behavior is currently (in TrueSTUDIO v.5.3.0) not possible to change. This behavior applies even if the GDB-server is started with the "-nohalt" option.

It is quite simple to make Atollic TrueSTUDIO connect using a SEGGER J-Link. Essentially the following three or four steps are needed:

  1. Modify the debug configuration
  2. Connect the J-Link to the embedded target
  3. Start a debug session using the modified debug configuration
  4. Optionally analyze the CPU fault condition with the fault analyzer tool


Modify the debug configuration

The default generated debug configurations in Atollic TrueSTUDIO contains the GDB commands needed to setup target communication speed, to flash and reset the device and to set some breakpoints. This is not of any use to us when we want to connect to a running system which may, or may not, have crashed. Therefore the first step is to make sure that we have a debug script that will not accidentally flash or reset your CPU, which could be very annoying when you finally have managed to trigger a crash behavior which has been difficult to track down. In order to create amodified  debug configuration perform the steps below:

  1. In the menu: Run --> Debug Configurations...
  2. In the left frame of the Debug Configurations GUI, select the debug configuration associated to the project/application that you want to debug and make a copy of this by right-clicking it and click Duplicate.
  3. Give the duplicate Debug Configuration a name
  4. Go to the tab called Startup Script --> Target Software Startup Script --> Debug
  5. Use the "#" (hash-key) to comment out all GDB-commands or simply delete all commands. See picture below:


All GDB-commands are commented out.

Step 2: Connect the J-Link to the embedded target

Connect the J-link to your computer. Then connect it to your embedded target. No reset should be issued.

Step 3: Start a debug session using the modified debug configuration

Important! Do not make the mistake of launching the debug session using the wrong debug configuration, that will probably flash and reset your target. Instead the safest way to launch a debug session with with full control of which debug configuration is applied (and thereby preventing a potential reset) is by using the Run menu --> Debug Configurations... Select the modified debug configuration in the left frame and an click Debug.

Voilà - the debugger should now be connected to the embedded target which is automatically halted for you. At this point you can investigate different status registers and variable in your application. If your CPU har crashed, then also look into the next step which will help you understand what went wrong, why and where.

Step 4: Analysis of fault condition (optional step only for Cortex-M)

If the CPU has hard faulted then open the Fault Analyzer view. Menu: Window --> Show View --> Fault Analyzer

The Fault Analyzer should automatically show you information about the CPU fault condition as well as which C statement as assembly instruction that drove the CPU to crash. The view automatically polls information from the target each time the CPU is suspended.

The Fault Analyzer view shows easy to interpret information about the CPU fault and essentially answers the three fundamental questions WHAT happened, WHY and WHERE.


The Fault Analyzer view, provides easy-to-read information on the encountered CPU fault condition as well as hyper linking to the offending C-statement and assembly instruction.


I hope this explanation is sufficient on how to connect the J-Link + TrueSTUDIO debugger to a running ARM device. This is especially useful when running into problems that only occurs after several hours or days of running your system. Anyone who is interested in learning more about Fault Analysis on Cortex-M and how to use the Fault Analyzer view is recommended to read our white paper on this topic which is linked below.

To learn more about Fault Analysis on Cortex-M please read this white paper:

Read our hard fault crash analysis whitepaper

To learn how to use the Fault Analyzer view, please watch this video tutorial

Watch the hard fault analysis video tutorial!


Topics: ARM Cortex, Debugging, Atollic TrueSTUDIO, SEGGER J-Link