STM32CubeIDE hangs at “Performing pre-launch check”

[bugiii]

I'm experiencing an issue when attempting to debug a project in STM32CubeIDE v1.19.0 using a NUCLEO-H753ZI board and ST-LINK V3 (FW: V3J16M9). The debugger appears to hang during the early initialization phase and fails to proceed with device enumeration commands.

---

Behavior

When I launch a debug session, the IDE displays:

Launching: Performing pre-launch check...

It remains stuck at this message indefinitely. The only way to cancel is to terminate the stlinkserver.exe process manually using Task Manager. Once the server is killed, the IDE regains control and exits the debug attempt.

To investigate further, I manually started stlinkserver.exe using:

stlinkserver.exe -a -p 7184 -d 5

The server successfully detects the ST-LINK device:

STLK: Add to stlink USB list: VID 0x0483, PID 0x3754, serial [REDACTED_SN]
...
TCPCMD REFRESH_DEVICE_LIST : return 1

However, no subsequent commands are issued — GET_NB_DEV, GET_DEV_INFO, and OPEN_DEV are all missing. The server enters an idle state and repeats "No connections/data in the last 30 seconds."

---

Verification

I’ve confirmed the ST-LINK and target MCU are working correctly:

• STM32_Programmer_CLI.exe connects successfully and reports correct voltage, device ID, and memory size.

• I can also connect via arm-none-eabi-gdb using:

target remote :7184

This works without issues, which suggests:

• USB and driver layers are functioning

• stlinkserver is operating correctly

• GDB remote protocol is working end-to-end

This leads me to believe the problem is isolated to CubeIDE's internal debugger initialization sequence, which appears to fail immediately after establishing the initial TCP connection.

I am currently working around this issue by manually launching the ST-LINK GDB server in a separate command prompt using the following loop:

for /L %i in (0,0,1) do C:\ST\STM32CubeIDE_1.19.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.win32_2.2.200.202505060755\tools\bin\ST-LINK_gdbserver.exe -p 61234 -l 1 -d -s -cp C:\ST\STM32CubeIDE_1.19.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.2.200.202503041107\tools\bin -m 0 -g

This command repeatedly launches ST-LINK_gdbserver.exe whenever it exits, as a workaround for CubeIDE's failure to properly manage the ST-LINK server lifecycle during debug session startup.

---

System Environment

• CPU: AMD Ryzen 9 3950X (16 cores, 32 threads)

• Chipset: X580-based motherboard

• RAM: 64GB

• OS: Windows 11 Pro 23H2 (clean installation, not upgraded)

• All drivers and firmware are up to date.

Importantly, I tested the exact same board and project on another laptop with an Intel CPU, and there the issue does not occur. The debug session starts normally, and stlinkserver proceeds with the expected command sequence.

This raises the question of whether the issue could be related to USB host controller compatibility, driver timing differences, or chipset-level interactions on AMD platforms.

---

Attempts and Workarounds

• Clean workspace in CubeIDE

• Fresh install of STM32CubeIDE and STM32CubeProgrammer

• Tried multiple reset modes (software, hardware, connect-under-reset)

• Verified use of correct internal stlinkserver.exe in the plugin directory

• Attempted external ST-LINK server mode on 127.0.0.1:7184

• Replaced stlinkserver.exe with version from CubeProgrammer v2.20 — no change

• Reproduced the same issue even after OS reinstall

---

Expected Behavior

Normally, after REFRESH_DEVICE_LIST, the following should occur:

GET_NB_DEV GET_DEV_INFO OPEN_DEV ...

None of these appear in the log when using CubeIDE on the Ryzen-based system.

---

Questions

1. Is this a known issue in CubeIDE v1.19.0 or with ST-LINK server integration?

2. Could this be caused by USB compatibility issues on certain chipsets (e.g., AMD X580)?

3. Is there any debug flag or configuration to force enumeration or provide verbose output from the debugger layer?

4. Would rolling back to an earlier version of CubeIDE or CubeProgrammer help?

I'm happy to provide logs or additional test results if needed. Any insight into this behavior would be appreciated.

Thank you.

[JoLo]

Hi all, 

we have the same issue since Friday! Did anyone found a solution? 

[Imen.D]

Hello @JoLo,

First let me welcome you to the ST Community and thank you for posting.

Try re-install STM32CubeIDE and ST-Link Server. You can follow the guide and instructions described at UM2563, in "STM32CubeIDE installation" section depends on your operating system.

[JoLo]

Hi Imen, 

thanks, I did, but it didn't help. I have the problem across multiple CubeIDE Versions, also tried to delete ST-Link Server manually, did not help. 

[JoLo]

Hi Imen, 

could it be that my problem is related to this Windows Update: https://www.windowslatest.com/2025/10/18/microsoft-confirms-windows-11-kb5066835-issues-localhost-file-explorer-preview-install-errors/

Best Jonas

[JoLo]

Hi all, 

so I tested a lot now and removed all Windows updates and did workarounds mentioned in the post linked above. Nothing helps. 

I also tried to start the GDB Server manually and then connect via the remote setting. It does not work, I get a following error: 

Error in final launch sequence: Failed to execute MI command: target remote localhost:61234 Error message from debugger back end: Remote replied unexpectedly to 'vMustReplyEmpty': timeout Failed to execute MI command: target remote localhost:61234 Error message from debugger back end: Remote replied unexpectedly to 'vMustReplyEmpty': timeout Remote replied unexpectedly to 'vMustReplyEmpty': timeout

I also tried to use OpenOCD, I get the same error from IDE. Following I give you the logs from cmd: 

C:\ST\STM32CubeIDE_1.18.1\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.openocd.win32_2.4.100.202501161620\tools\bin\openocd.exe "-f" "p22-001_firmware_main_STM32L451 Debug (2).cfg" "-s" "C:/Git/P22-001_PS3/p22-001_firmware_main_stm32l451_other" "-s" "C:/ST/STM32CubeIDE_1.18.1/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.debug.openocd_2.3.100.202501240831/resources/openocd/st_scripts" "-s" "C:/ST/STM32CubeIDE_1.18.1/STM32CubeIDE/plugins/com.st.stm32cube.ide.mpu.debug.openocd_2.2.0.202409171044/resources/openocd/st_scripts" "-c" "gdb_report_data_abort enable" "-c" "gdb_port 3333" "-c" "tcl_port 6666" "-c" "telnet_port 4444"
Open On-Chip Debugger 0.12.0+dev-00608-gd8ed48fef (2025-02-06-11:17) [https://github.com/STMicroelectronics/OpenOCD]
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : STLINK V3J16M7 (API v3) VID:PID 0483:3754
Info : Target voltage: 3.329239
Info : clock speed 8000 kHz
Info : stlink_dap_op_connect(connect)
Info : SWD DPIDR 0x2ba01477
Info : [STM32L451VETx.cpu] Cortex-M4 r0p1 processor detected
Info : [STM32L451VETx.cpu] target has 6 breakpoints, 4 watchpoints
Info : [STM32L451VETx.cpu] Examination succeed
Info : starting gdb server for STM32L451VETx.cpu on 3333
Info : Listening on port 3333 for gdb connections
Info : [STM32L451VETx.cpu] external reset detected
Info : accepting 'gdb' connection on tcp/3333
[STM32L451VETx.cpu] halted due to breakpoint, current mode: Thread
xPSR: 0x01000000 pc: 0x08000de8 msp: 0x20028000
Info : device idcode = 0x20016462 (STM32L45/L46xx - Rev Y : 0x2001)
Info : RDP level 0 (0xAA)
Info : flash size = 512 KiB
Info : flash mode : single-bank
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1392 ms). Workaround: increase "set remotetimeout" in GDB
Warn : negative acknowledgment, but no packet pending
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1513 ms). Workaround: increase "set remotetimeout" in GDB
Warn : negative acknowledgment, but no packet pending
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1517 ms). Workaround: increase "set remotetimeout" in GDB
Warn : negative acknowledgment, but no packet pending
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1513 ms). Workaround: increase "set remotetimeout" in GDB
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1015 ms). Workaround: increase "set remotetimeout" in GDB
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1002 ms). Workaround: increase "set remotetimeout" in GDB
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1508 ms). Workaround: increase "set remotetimeout" in GDB
Warn : negative acknowledgment, but no packet pending
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1491 ms). Workaround: increase "set remotetimeout" in GDB
Warn : negative acknowledgment, but no packet pending
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1015 ms). Workaround: increase "set remotetimeout" in GDB
Warn : negative acknowledgment, but no packet pending
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1015 ms). Workaround: increase "set remotetimeout" in GDB
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1484 ms). Workaround: increase "set remotetimeout" in GDB
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1502 ms). Workaround: increase "set remotetimeout" in GDB
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1487 ms). Workaround: increase "set remotetimeout" in GDB
Warn : negative acknowledgment, but no packet pending
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1493 ms). Workaround: increase "set remotetimeout" in GDB
Warn : negative acknowledgment, but no packet pending
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1513 ms). Workaround: increase "set remotetimeout" in GDB
Warn : negative acknowledgment, but no packet pending
shutdown command invoked
Info : dropped 'gdb' connection

Does anyone have an idea what is going on? 

Thank you and all the best
Jonas

[JoLo]

Problem solved.

It was a problem with a network configuration and Windows update which leads to localhost problems

Best Jonas