"Could not verify ST device" when Debugging with RTOS Proxy; OK without

xuky765 · ‎2026-01-28

Hi,

I’m working on an STM32H7S78‑DK project that uses FreeRTOS, with STM32CubeIDE v2.0.0 on Windows. The ST‑LINK debugger works normally as long as RTOS Proxy is disabled, but cannot be launched once I enable RTOS Proxy. Error message and Console prints as below:

My debugger configuration:

The exact same project used to run fine with RTOS Proxy enabled, but it suddenly started failing one day without any changes to my debug settings. The board itself should be good, as it works normally on another development setup.

Has anyone seen this issue before, or is there any known limitation with RTOS Proxy on the H7S series? Any pointers would be appreciated.

Souhaib MAZHOUD · ‎2026-01-29

Hello @xuky765

What ST‑LINK debugger are you using? probably these kinds of errors occurred with fake debugger as mentioned here.

see also How to recognize a genuine ST-LINK/V2 versus a clo... - STMicroelectronics Community

BR, Souhaib

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Andrew Neil · ‎2026-01-29

@Souhaib MAZHOUD wrote:
these kinds of errors occurred with fake debugger as mentioned here.

That thread relates to a fake STM32F103 chip ("Blue Pill") - not a fake ST-Link.

Also, would that explain why it fails with the RTOS Proxy, but not without ?

@xuky765 possibly related thread: Could not verify ST device when attempting to debug ?

Edit: Link fixed.

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

mƎALLEm · ‎2026-01-29

@Andrew Neil

@xuky765 possibly related thread: Could not verify ST device when attempting to debug ?

That link is not working.

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.

Andrew Neil · ‎2026-01-29

@mƎALLEm wrote:
That link is not working.

Oops - Now fixed.

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

xuky765 · ‎2026-01-29

Hi @Souhaib MAZHOUD,

I am using the on-board embedded STLINK-V3E of STM32H7S78-DK.

xuky765 · ‎2026-01-29

Hi @Andrew Neil,

Thank you for the pointer. Different from the other thread, I'm using the on‑board embedded ST‑LINK/V3E of the STM32H7S78‑DK, not an external ST‑Link/V2 probe.

Another detail that I don't know if will help: that thread mentioned that the debugger works from time to time. My debugger also worked intermittently at first, but eventually stopped connecting entirely.

xuky765 · ‎2026-02-02

Updates:

We found that the issue is FreeRTOS thread-related. When the creation call osThreadNew() for a specific thread is commented out, the program runs normally under the debugger.

However, we got different behaviors with different debugger host PCs. The issue reproduces on one Ubuntu 24.04 LTS machine and one Windows machine. On another Ubuntu 24.04 LTS machine, the project runs normally even with RTOS proxy enabled and without disabling the thread creation.

Both Ubuntu machines are using STM32CubeIDE 2.0.0. Multiple target boards were tested with consistent results.

Has anyone encountered RTOS proxy behavior that depends on the host PC environment like this?

Thank you,

K