Cannot debug with STM32CubeIDE and ST-LINK/V2, but CubeProgrammer works.

[LOrozco]

I am using STM32CubeIDE version 1.13.2 and an ST-LINK/V2.

I have a custom board with an STM32G031CU86 and I am connecting via SWD.

When I try to either Run or Debug from the IDE, I get an error from the ST-LINK (see below).  However, using the STM32CubeProgrammer, I can connect to the ST-LINK, load up the .elf file and program the board just fine.

This makes me think the board and programmer are working correctly, but I'm missing a setting somewhere to make this work.  Based on the errors below, it sure smells like a Windows firewall issue, but I can't find anything blocking anything called 'gdb' or 'stlink'.  Any ideas?

The Error Message:

 

Failed to execute MI Command:
target remote localhost:61234

Error message from debugger back end:
localhost:61234: Connection timed out

 

The following is the console output:

 

 

Starting server with the following options:
 Persistent Mode : Disabled
 LogFile Name : C:\Gitclones\usb-c-cable-tester\Firmware\Debug\st-link_gdbserver_log.txt
 Logging Level : 31
 Listen Port Number : 61234
 Status Refresh Delay : 15s
 Verbose Mode : Enabled
 SWD Debug : Enabled
COM frequency = 4000 kHz
Target connection mode: Attach
Reading ROM table for AP 0 @0xf0000fd0
Hardware watchpoint supported by the target 
ST-LINK Firmware version : V2J43S7
Device ID: 0x466
PC: 0xa
ST-LINK device status: RUN_MODE
ST-LINK detects target voltage = 3.21 V
ST-LINK device status: RUN_MODE
ST-LINK device initialization OK
Stm32Device, pollAndNotify running...
SwvSrv state change: 0 -> 1
Waiting for debugger connection...
Waiting for connection on port 61234...
Waiting for connection on port 61235...
Accepted connection on port 61234...
Debugger connected
Waiting for debugger connection...
Waiting for connection on port 61234...
GDB session thread running
GdbSessionManager, session started: 1
Try halt...
GDB session terminated: Client connection lost
GdbSessionManager, session terminated: 1
GdbSrv, last session terminated, signal dispose
Stopping port 61234
Cleanup session: 1
GDB session disposed: 1
ST-LINK device status: HALT_MODE
Received stop for port 61234, not accepting new connections.
GdbSrv, deInit entry.
Shutting down...
GdbSessionManager, deInit entry.
GdbSessionManager, deInit exit
SwvSrv deInit entry
Stopping port 61235
Stopping port 61234
Received stop for port 61235, not accepting new connections.
SwvSrv deInit exit
Stm32Device, closeDevice() entry
Stm32Device, pollAndNotify stopped
Stm32Device, closeDevice() exit
Stm32Device, deInit success
GdbSrv, deInit exit.
Exit.

 

I'm also attaching my debug configuration in case it helps.

 

[TDK]

Counterfeit programmers don't work with the newer releases of STM32CubeIDE (but still work with STM32CubeProgrammer). Genuine programmers should work okay.

Does it work with a new project generated from CubeMX?

[LOrozco]

Is there a way to tell if I have a counterfeit programmer?  This thing has the ST logo on the front and an ST-branded label on the back with a serial number and all of the compliance agency marks, etc.  Seems like a lot of effort for a $50 programmer (but I guess I've seen worse...)

In case this means anything, the serial number on the label is B 2018 41

Also,

* This project was started with CubeMx (just a blinky light and all of the peripheral configuration functions generated by CubeMx at the moment)

* I disabled all of the Windows Defender firewall settings (Domain Network/Private Network/Public Network) and it still didn't work...

[TDK]

> Is there a way to tell if I have a counterfeit programmer?

There's no perfect test, but if it looks like this one and you bought it from a reputable seller, it's probably real:

https://www.st.com/en/development-tools/st-link-v2.html

As opposed to the "ST-LINK V2" or "ST Link V2" ones on amazon with the 10-pin header which are all counterfeit to some degree.

 

 

> I disabled all of the Windows Defender firewall settings (Domain Network/Private Network/Public Network) and it still didn't work...

That would have been my next guess. Could still be the reason if there's a setting you missed somewhere, or some other program at work, but I'm kind of grasping at straws at this point. I'll post again if I think of something else.