Skip to main content
Associate III
February 17, 2026
Solved

CubeProgrammer + Clone STLinkV2 Full chip erase fails; OK in CubeIDE

  • February 17, 2026
  • 3 replies
  • 341 views

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.

Best answer by Bags

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.

 

 

 

3 replies

Peter BENSCH
Technical Moderator
February 17, 2026

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

BagsAuthor
Associate III
February 18, 2026

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.

 

Andrew Neil
Super User
February 18, 2026

It's not actually a bug if you're not using a genuine, supported ST-Link.

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.
BagsAuthor
Associate III
February 18, 2026

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.

 

 

Peter BENSCH
Technical Moderator
February 18, 2026

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:

  • STM32_Programmer_CLI --help
  • STM32_Programmer_CLI -c port=SWD mode=UR reset=HWrst

Regards
/Peter

BagsAuthorBest answer
Associate III
February 18, 2026

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.