cancel
Showing results for 
Search instead for 
Did you mean: 

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

Bags
Associate III

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.

1 ACCEPTED SOLUTION

Accepted Solutions

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.

 

 

 

View solution in original post

6 REPLIES 6
Peter BENSCH
ST Employee

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

In order 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.

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.

 

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.
Bags
Associate III

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
ST Employee

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

In order 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.

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.