2023-12-19 12:00 AM
I am using STM32CubeIDE V1.11.0
I have exactly the same issue which was described in this post:
https://community.st.com/t5/stm32-mcus-boards-and-hardware/st-link-gdb-server-issues/m-p/64010#M623
Multiple weeks everything works fine. But suddenly it stops working and i always get this error message when I try to Debug my code in CubeIDE:
Failed to bind to port 61235, error code -1: No error
Failure starting SWV server on TCP port: 61235
Failed to bind to port 61234, error code -1: No error
Failure starting GDB server: TCP port 61234 not available.
Shutting down...
Exit.
I tried multiple things:
I enabled the "log file" option in the debugger settings. This file says:
COM frequency = 4000 kHz
Target connection mode: Attach
Reading ROM table for AP 0 @0xe00fefd0
Hardware watchpoint supported by the target
ST-LINK Firmware version : V2J40S7
Device ID: 0x450
PC: 0x79fb70
ST-LINK device status: LOCKUP
Enter STM32_SystemReset() function
ST-LINK detects target voltage = 3.24 V
Device in lock up state, possibly "read and debug" protected. Use monitor commands to remove the protection
ST-LINK device initialization OK
Stm32Device, pollAndNotify running...
ST-LINK device status: HALT_MODE
Failed to bind to port 61235, error code -1: No error
Failure starting SWV server on TCP port: 61235
Failed to bind to port 61234, error code -1: No error
Failure starting GDB server: TCP port 61234 not available.
GdbSrv, deInit entry.
Shutting down...
GdbSessionManager, deInit entry.
GdbSessionManager, deInit exit
SwvSrv deInit entry
SwvSrv deInit exit
Stm32Device, closeDevice() entry
Stm32Device, pollAndNotify stopped
Stm32Device, closeDevice() exit
Stm32Device, deInit success
GdbSrv, deInit exit.
Exit.
What does it mean with "Device in lock up state"? There are no lock fuses set in the target. And the CubeProgrammer can read and write the target without any problems.
I am completly stucked with this problem. And everything I read in the Internet about this error does not helped. Maybe some one here can help me?
Solved! Go to Solution.
2024-01-31 11:14 AM
Any idea?
GDB Server still not working.
2024-01-31 11:38 AM
I think, i would not try to play around with this sick...
Update or better : install new version of IDE , should work with the new. (you can have more > 1 IDE same time).
2024-01-31 12:06 PM
Okay, I did a new Installation of STM32CubeIDE. Now the GDB Server works again. :thumbs_up:
2025-12-23 1:49 AM
Suddently, after 6 months using the STM32CubeIde software, I got the same error:
...
STMicroelectronics ST-LINK GDB server. Version 7.12.0
Copyright (c) 2025, STMicroelectronics. All rights reserved.
Starting server with the following options:
Persistent Mode : Disabled
Logging Level : 1
Listen Port Number : 61234
Status Refresh Delay : 15s
Verbose Mode : Disabled
SWD Debug : Enabled
Failed to bind to port 61235, error code -1: No error
Failure starting SWV server on TCP port: 61235
Failed to bind to port 61234, error code -1: No error
Failure starting GDB server: TCP port 61234 not available. Shutting down...
Exit. "
...
I didn't know what could be happening. I thought that It could be something related to the GDBServer. I wanted to reinstall GDBserver or STLINK but as I didn't know how to only reinstall that components I uninstalled and reinstalled all the applications to the latest versions ( STM32CubeIde and STM32CubeMx ) but the problem persisted. After reinstalling I got the same error.
So with all the software updated to the latest version I checked with another STM32 board I have and the problem persisted I also checked other USB cable and the same.... So it seemed something related to the ports accesss or process executions permissions.
Finally I solved the problem changing the Debugger settings in "Run > Debug Configurations" of the project. In the "Debugger" tab, I changed port number from 61234 to 50000. Then I tried to debug again, the Windows Firewall asked me to provide access permissions to ST-LINK to the network and I accepted. Then everything started to work correctly. So despite I initially checked on Windows Firewall, it seems that it was all an problem of port access persmissions.