STLINK-V3MINIE not handling breakpoints correctly

julianf20 · ‎2025-08-26

I created a support ticket for this issue but haven't heard back yet, but I wondered if anyone else has seen this issue before.

I have been having an issue with my STLINK-V3MINIE for some time now. When I set and hit a breakpoint, the program will often not start again no matter what I do. I am using arm-none-eabi-gdb with OpenOCD to debug a STM32H750, and will set a breakpoint or watchpoint in my code, and once it is hit, I am not able to get the target to continue again using "continue" or "step" commands in gdb. Even after deleting the breakpoint, the issue will remain and the only way to get the target to respond normally again is to reset the program with "monitor reset halt". The image I attached shows hitting a breakpoint, deleting the breakpoint, then not being able to continue

I tried upgrading the firmware on my STLINK-V3MINIE, this did not fix it. It is an official STLINK-V3MINIE that I bought from ST, not a clone.

Things that I tried that did not work as advised by ST support last time I tried to fix this were turning off optimizations (they were on -O3) which did not fix it. Running my program out of flash instead of SRAM, which did not fix it. Disabling CPU cache, did not fix it. I also tried using STM32CubeIde to create a debugging environment but this did not work, and it actually seemed to work worse.

I'm sure there is something wrong with my debugging setup/environment that is causing this issue, but I can't figure out what. I need to fix this so I can execute code after hitting breakpoints as it's making development really difficult. If anyone has any ideas, I would appreciate it. Thanks

Amel NASRI · ‎2025-10-14

Hi @julianf20 ,

I come back to this old question to confirm that your issue was fixed based on the support ticket you created.

For others who may face a similar issue, I think that you installed the latest STM32CubeProgrammer version to get the issue fixed.

-Amel

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.

julianf20 · ‎2025-10-14

No it was not fixed but it doesn't matter. I finished the project without full use of the debugger

Andrew Neil · ‎2025-10-14

What else was going on in the system while you were debugging?

If real-time processes are still running while a CPU is halted at a breakpoint, I have seen that lead to problems with restarting - because the system is no longer in a valid state.

Not specific to STM32

In these kind of situations, you need non-blocking debug techniques...

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.