2026-02-17 12:37 PM - last edited on 2026-02-18 2:47 AM by Andrew Neil
Title edited to note that this is a clone ST-Link.
Using a WeAct mini STM32H723 Core board which seems to be working fine via SWD and a gold STLInkV2 USB stick. (STLinkV2 firmware V2j46S7).
Using STM32CubeProgrammer v2.21.0 seems to work ok, connected under SWD, 4kHz, Normal mode, S/w reset, reliable speed, non shared (my usual settings that work with all the other STM32 boards I have).
But when I tried the "Full chip erase" (or erase selected sectors), it merely reports erase successful with no errors. However the flash remains unchanged.
Using STM32CubeIDE 2.0.0 however, I can successfully download my code to the board (which proves the flash can be erased using the STLinkV2 h/w).
Not sure where the problem lies as yet, but have put this issue up here in case others have the same problem with STM32CubeProgrammer.
Will post an update here or on the WeAct github site if I make progress to finding why its not working.
Solved! Go to Solution.
2026-02-18 12:42 PM
Well with the use of the backend API, I can confirm that
"STM32_Programmer_CLI -c port=SWD -e all" and "STM32_Programmer_CLI -c port=SWD -blankcheck" both work with no errors, and if I then check the results using STM32CubeProgrammer, that the GUI does now display the flash area as now reading all FFs.
So that indicates a possible bug hiding in the STM32Programmer GUI for the erase functionality, having ruled out everything else.
2026-02-17 12:56 PM - edited 2026-02-17 12:57 PM
A golden ST-LINK/V2, i.e. one of those colourful tin cans? This cannot work (reliably); see also this article.
Get a genuine ST-LINK from an authorised dealer and work properly, not just be angry.
Good luck!
Regards
/Peter
2026-02-18 1:31 AM
Why on earth would I be angry?
I'm finding enough bugs in your software applications to keep your engineers busy for the next year, and this issue appears to be another one.
The only thing I ask is that you keep up and fix your bugs faster than I am finding them.
2026-02-18 2:48 AM
It's not actually a bug if you're not using a genuine, supported ST-Link.
2026-02-18 3:17 AM
If you can explain why STM32CubeIDE quite happily programs the MCU using the exact same hardware, whereas the STM32CubeProgrammer doesn't, then I would agree is might be down to the alternative STLinkV2 I am using.
If STM32CubeProgrammer isn't using the same underlying subsystem as STM32CubeIDE for target communications I would find that somewhat non optimal for design and support.
Is there a CLI for STM32CubeProgrammer? I have found some articles online for using the Windows variant in a command line mode but not for linux OSs.
2026-02-18 4:18 AM
STMicroelectronics cannot (and don't want to) comment on your “alternative” ST-LINK/V2. You would need to ask its manufacturer, who is using illegally copied firmware.
The topic of CLI should actually be dealt with in a separate thread, but suffice it to say: yes, a CLI should also be visible under Linux when installing the STM32CubeProgrammer (at least I can find in the package under bin/STM32_Programmer_CLI). If the installation path has been added to your path, the following commands should work in bash, for example:
Regards
/Peter
2026-02-18 12:42 PM
Well with the use of the backend API, I can confirm that
"STM32_Programmer_CLI -c port=SWD -e all" and "STM32_Programmer_CLI -c port=SWD -blankcheck" both work with no errors, and if I then check the results using STM32CubeProgrammer, that the GUI does now display the flash area as now reading all FFs.
So that indicates a possible bug hiding in the STM32Programmer GUI for the erase functionality, having ruled out everything else.