Skip to main content
AMaxs.1
AMaxs.1
Associate
April 25, 2021
Solved

Problem with Running code execution and Quiting Debug using SEGGER JLink and STM32CubeIDE. Debugger requested to halt target......Target halted

  • April 25, 2021
  • 3 replies
  • 5469 views

Hi everybody! I am using Windows10, STM32CubeIDE v1.5.1 and SEGGER JLink debugger, HW is STM32F103C8T6, Firmware is default Blink using HAL(But its occurs in all projects)

I Have 2 problems:

1) Running code execution:

When I try to run the code, the MCU is flashed successfully, but at the end I see a message about halting MCU and I need to press Reset button on PCB to run the code.

When problem occurs log looks like this 

SEGGER J-Link GDB Server V6.82g Command Line Version
 
JLinkARM.dll V6.82g (DLL compiled Aug 28 2020 16:57:23)
 
Command line: -port 2331 -s -device STM32F103C8 -endian little -speed 4000 -if swd -vd
-----GDB Server start settings-----
GDBInit file: none
GDB Server Listening port: 2331
SWO raw output listening port: 2332
Terminal I/O port: 2333
Accept remote connection: localhost only
Generate logfile: off
Verify download: on
Init regs on start: off
Silent mode: off
Single run mode: on
Target connection timeout: 0 ms
------J-Link related settings------
J-Link Host interface: USB
J-Link script: none
J-Link settings file: none
------Target related settings------
Target device: STM32F103C8
Target interface: SWD
Target interface speed: 4000kHz
Target endian: little
 
Connecting to J-Link...
J-Link is connected.
Firmware: J-Link V9 compiled Dec 13 2019 11:14:50
Hardware: V9.60
S/N: XXXXXXXXX
Feature(s): GDB, RDI, FlashBP, FlashDL, JFlash, RDDI
Checking target voltage...
Target voltage: 3.28 V
Listening on TCP/IP port 2331
Connecting to target...
Connected to target
Waiting for GDB connection...Connected to 127.0.0.1
Reading all registers
Read 4 bytes @ address 0x0800048E (Data = 0x002C4770)
Read 2 bytes @ address 0x0800048E (Data = 0x4770)
Connected to 127.0.0.1
Reading all registers
Read 4 bytes @ address 0x0800048E (Data = 0x002C4770)
Received monitor command: WriteDP 0x2 0xF0
O.K.
Received monitor command: ReadAP 0x2
O.K.:0xE00FF003
Reading 32 bytes @ address 0xE00FFFD0
Received monitor command: reset
Resetting target
Downloading 268 bytes @ address 0x08000000 - Verified OK
Downloading 4368 bytes @ address 0x0800010C - Verified OK
Downloading 32 bytes @ address 0x0800121C - Verified OK
Downloading 4 bytes @ address 0x0800123C - Verified OK
Downloading 4 bytes @ address 0x08001240 - Verified OK
Downloading 12 bytes @ address 0x08001244 - Verified OK
Writing register (PC = 0x 8000384)
Starting target CPU...
GDB closed TCP/IP connection (Socket 1008)
Debugger requested to halt target...
...Target halted (PC = 0x08000486)
GDB closed TCP/IP connection (Socket 1036)

Sometimes it runs without halting and no need to press Reset button.

Then log looks like this:

SEGGER J-Link GDB Server V6.82g Command Line Version
 
JLinkARM.dll V6.82g (DLL compiled Aug 28 2020 16:57:23)
 
Command line: -port 2331 -s -device STM32F103C8 -endian little -speed 4000 -if swd -vd
-----GDB Server start settings-----
GDBInit file: none
GDB Server Listening port: 2331
SWO raw output listening port: 2332
Terminal I/O port: 2333
Accept remote connection: localhost only
Generate logfile: off
Verify download: on
Init regs on start: off
Silent mode: off
Single run mode: on
Target connection timeout: 0 ms
------J-Link related settings------
J-Link Host interface: USB
J-Link script: none
J-Link settings file: none
------Target related settings------
Target device: STM32F103C8
Target interface: SWD
Target interface speed: 4000kHz
Target endian: little
 
Connecting to J-Link...
J-Link is connected.
Firmware: J-Link V9 compiled Dec 13 2019 11:14:50
Hardware: V9.60
S/N: XXXXXXXXX
Feature(s): GDB, RDI, FlashBP, FlashDL, JFlash, RDDI
Checking target voltage...
Target voltage: 3.28 V
Listening on TCP/IP port 2331
Connecting to target...
Connected to target
Waiting for GDB connection...Connected to 127.0.0.1
Reading all registers
Read 4 bytes @ address 0x08000486 (Data = 0x4618681B)
Read 2 bytes @ address 0x08000486 (Data = 0x681B)
Connected to 127.0.0.1
Reading all registers
Read 4 bytes @ address 0x08000486 (Data = 0x4618681B)
Received monitor command: WriteDP 0x2 0xF0
O.K.
Received monitor command: ReadAP 0x2
O.K.:0xE00FF003
Reading 32 bytes @ address 0xE00FFFD0
Received monitor command: reset
Resetting target
Downloading 268 bytes @ address 0x08000000 - Verified OK
Downloading 4368 bytes @ address 0x0800010C - Verified OK
Downloading 32 bytes @ address 0x0800121C - Verified OK
Downloading 4 bytes @ address 0x0800123C - Verified OK
Downloading 4 bytes @ address 0x08001240 - Verified OK
Downloading 12 bytes @ address 0x08001244 - Verified OK
Writing register (PC = 0x 8000384)
Starting target CPU...
GDB closed TCP/IP connection (Socket 1008)
GDB closed TCP/IP connection (Socket 1044)

2) Second problem is about quiting debugger mode, press "Terminate" Button, MCU isn't starting, it is in Halt mode, but sometimes it starts.

When MCU starts log looks like this:

Bla, bla, bla...
GDB closed TCP/IP connection (Socket 916)
GDB closed TCP/IP connection (Socket 1016)
Restoring target state and closing J-Link connection...
Shutting down...

When MCU is Halted log looks like this:

Bla, bla, bla...
GDB closed TCP/IP connection (Socket 916)
GDB closed TCP/IP connection (Socket 1016)

It occurs only in CubeIDE, when i am using VS + VisualGDB or Keil uVision 5 i don't have thesee problems.

Help me please!

This topic has been closed for replies.
Best answer by mattias norlander

Hi @AMaxs.1​, @Lk.2​,

The problem you are experiencing may stem from an issue in CDT. You are using Windows machines right?

On Windows, when CDT is terminating debug sessions it uses a utility known as starter.exe. This utility is not shutting down processes in a good way resulting in that SEGGER and actually any other GDB-server may exit in a not so graceful way. We believe that this is what you are experiencing.

You could actually work-around this by launching the GDB-server remotely in persistent mode. Then CubeIDE would only launch the GDB-client. Consequently starter.exe is not allowed to manage the GDB-server thread(s).

If you want to try this work-around, modify your debug config like this:

  1. Switch to connect to remote instead of auto-start, and set the port...
  2. You now have to launch SEGGER GDB-server via command-line. You can of course also automate the launch with an external tools configuration in CubeIDE if you want...
    1. If you open your debug configuration > Debugger > Show command Line. You will now see the parameters we use when launching SEGGER GDB-server. Copy paste that into your invocation of SEGGER GDV-server or your external tools config.

Let us know if that lead to a more reliable experience when clicking the "Terminate" button...

3 replies

AMaxs.1
AMaxs.1Author
Associate
April 25, 2021

I also tried to change JLink software versions, change SWD Speed,change Debugger settings, nothing happens!

Update: Tried CubeIDE 1.6.1 clearly installed on NEW Win7 x64 System, same problem.

Lk.2
Lk.2
Visitor II
June 24, 2021

I have same problem. Sometime runs sometime halted!

AMaxs.1
AMaxs.1Author
Associate
June 24, 2021

Hi! I bought STLINK v3mini, now all is working like a charm!

Didn't find any solution with JLink.​

Lk.2
Lk.2
Visitor II
June 24, 2021

Thanks for information. But I still want to find a solution for SEGGER JLink.

mattias norlander
mattias norlanderBest answer
ST Employee
October 8, 2021

Hi @AMaxs.1​, @Lk.2​,

The problem you are experiencing may stem from an issue in CDT. You are using Windows machines right?

On Windows, when CDT is terminating debug sessions it uses a utility known as starter.exe. This utility is not shutting down processes in a good way resulting in that SEGGER and actually any other GDB-server may exit in a not so graceful way. We believe that this is what you are experiencing.

You could actually work-around this by launching the GDB-server remotely in persistent mode. Then CubeIDE would only launch the GDB-client. Consequently starter.exe is not allowed to manage the GDB-server thread(s).

If you want to try this work-around, modify your debug config like this:

  1. Switch to connect to remote instead of auto-start, and set the port...
  2. You now have to launch SEGGER GDB-server via command-line. You can of course also automate the launch with an external tools configuration in CubeIDE if you want...
    1. If you open your debug configuration > Debugger > Show command Line. You will now see the parameters we use when launching SEGGER GDB-server. Copy paste that into your invocation of SEGGER GDV-server or your external tools config.

Let us know if that lead to a more reliable experience when clicking the "Terminate" button...

Terms & ConditionsAccessibility statement