The 2.14 CubeProgrammer is slower than the 2.8 programming speed

xelus · ‎2023-10-30

Hi, I was using CubeProgrammer version 2.8 to program the STM32L552 microcontroller, using the ‘STM32_Programmer_CLI’ file. After updating to version 2.14, I have noticed a significantly longer programming time. For example, before the update, it took 1.8 seconds to program approximately 20kB; after the update, it takes over 10 seconds. My programming settings are as follows:
call "%programmer%" -c port=swd freq=1000 -w "%hexfile%" -v

I have tried different SWD frequencies, 3300 and 24000, but no luck. Does anyone else have this issue and know the solution?

I also have one more question - if a verification error occurs, why does STM32_Programmer_CLI return 0 as the exit code? Shouldn’t it be a different value that indicates an error?
Best regards,

Aziz BRIGUI · ‎2025-05-09

Hello @kweenie & All,

I apologize for the late reply, as you might suspect addressing all what has been discussed in this thread with proper analysis can take some time.

1- Let me address the first point on STM32L552 (0x472):

I confirm there was a regression in performance in v2.14, however, this has been already fixed for that device in the recent releases, below you'll find the detailed benchmark:

HW used: STM32L562-DK, BL.bin is a 26 KB binary.
PS C:\Users\briguiah> Measure-Command {& "C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer 2.8\bin\STM32_Programmer_CLI.exe" -c port=SWD -d "C:\Users\briguiah\OneDrive - STMicroelectronics\Desktop\Projects\PRG_Projects\binaries\BL.bin" 0x08000000}


Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 950
Ticks             : 9504560
TotalDays         : 1.10006481481481E-05
TotalHours        : 0.000264015555555556
TotalMinutes      : 0.0158409333333333
TotalSeconds      : 0.950456
TotalMilliseconds : 950.456



PS C:\Users\briguiah> Measure-Command {& "C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer 2.14\bin\STM32_Programmer_CLI.exe" -c port=SWD -d "C:\Users\briguiah\OneDrive - STMicroelectronics\Desktop\Projects\PRG_Projects\binaries\BL.bin" 0x08000000}


Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 3
Milliseconds      : 228
Ticks             : 32284463
TotalDays         : 3.73662766203704E-05
TotalHours        : 0.000896790638888889
TotalMinutes      : 0.0538074383333333
TotalSeconds      : 3.2284463
TotalMilliseconds : 3228.4463



PS C:\Users\briguiah> Measure-Command {& "C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer v2.19 S\bin\STM32_Programmer_CLI.exe" -c port=SWD -d "C:\Users\briguiah\OneDrive - STMicroelectronics\Desktop\Projects\PRG_Projects\binaries\BL.bin" 0x08000000}


Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 902
Ticks             : 9027665
TotalDays         : 1.04486863425926E-05
TotalHours        : 0.000250768472222222
TotalMinutes      : 0.0150461083333333
TotalSeconds      : 0.9027665
TotalMilliseconds : 902.7665

As you can see, best programming performance is with the latest version of STM32CubeProgrammer (v2.19).

2- For the 0x425 (STM32L03x/L04x/L010):

I confirm the 10x performance regression. Regression happened in v2.15 and is STRICTLY a Flashloader issue => The correct workaround is to only replace 0x425.stldr from v2.14 to v2.19 (I've attached the loader for convenience, it needs to be replaced in "STM32Cube\STM32CubeProgrammer\bin\FlashLoader").

Below the detailed benchmark:

HW used: Nucleo-L031, BL.bin is a 26 KB binary.
PS C:\Users\briguiah> Measure-Command {& "C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer 2.15\bin\STM32_Programmer_CLI.exe" -c port=SWD -d "C:\Users\briguiah\OneDrive - STMicroelectronics\Desktop\Projects\PRG_Projects\binaries\BL.bin" 0x08000000}


Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 24
Milliseconds      : 171
Ticks             : 241714877
TotalDays         : 0.00027976258912037
TotalHours        : 0.00671430213888889
TotalMinutes      : 0.402858128333333
TotalSeconds      : 24.1714877
TotalMilliseconds : 24171.4877



PS C:\Users\briguiah> Measure-Command {& "C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer 2.14\bin\STM32_Programmer_CLI.exe" -c port=SWD -d "C:\Users\briguiah\OneDrive - STMicroelectronics\Desktop\Projects\PRG_Projects\binaries\BL.bin" 0x08000000}


Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 2
Milliseconds      : 518
Ticks             : 25182709
TotalDays         : 2.91466539351852E-05
TotalHours        : 0.000699519694444444
TotalMinutes      : 0.0419711816666667
TotalSeconds      : 2.5182709
TotalMilliseconds : 2518.2709

I can assure you our Flashloader team is working hard to investigate further and fix this issue for a future release.

3- @Kraal, to address your enquiry on why the tools needs the files scattered in 5 places:

It's 2 different places actually (CubeProgrammer base path & CubeProgrammer API path). This is done because customers will not develop their CubeProgrammer based application inside the CubeProgrammer installation path => For customer convenience, copying only the API path should work out of the box, that brings the need for bundling Flashloader and Database in the API folder.

PS: FastROM_Data_Base is not the same as the database in base path (It's needed for a specific purpose which is the ST FastROM procedure).

I've tried to address as many points as I could, please let me know via PM or comment if any points where missed.

Thanks for your efforts in pre-analyzing these issues.

Aziz

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.

View solution in original post

kweenie · ‎2025-02-25

same here...

I had a setup which programmed a hex file in 2s using STM Cube Programmer v2.13.
(following comment of 'xelus', the 'delay' was introduced since v2.14...)

Upon upgrading to Cube Programmer v2.18 same setup suddenly needs 20s ?!
Upgrading firmware of ST-Link to latest version (V2J45S7) did not solve anything..

Running on W10, fully patched, 64-bit version of Cube programmer.
If I downgrade e.g. to Cube Programmer v2.8, I'm back at 2s programming time (same ST-Link, same MCU, same hex) ??

Any suggestions WHERE to start looking ?

Javier1 · ‎2025-02-25

did you try using cubeProgrammerCLI? is the same issue happening there?

check OpenOCD
Or wait untill ST patches CubeProgrammer.

hit me up in https://www.linkedin.com/in/javiermu%C3%B1oz/

kweenie · ‎2025-02-25

>>did you try using cubeProgrammerCLI? is the same issue happening there?

yes, both cli and gui have same issue.

>>Or wait untill ST patches CubeProgrammer.

original post from 'xelus' dates from 2 years back.. no fix/patch for this issue since then...

>>check OpenOCD
'heavy' that native tools from manufacturer need to be 'bypassed' using open source tools; seems odd to me.
I will check anyhow.

Javier1 · ‎2025-02-25

>>'heavy' that native tools from manufacturer need to be 'bypassed' using open source tools.
It makes me sad but is the way it is.....

hit me up in https://www.linkedin.com/in/javiermu%C3%B1oz/

xelus · ‎2025-02-25

kweenie, let me know when you check if OpenOCD programs faster.

Javier1 - do you think OpenOCD can be used for 'production' programming?

Javier1 · ‎2025-02-25

>>do you think OpenOCD can be used for 'production' programming?

Depends of what are your "production" requirements.

I have used it in the past, before cubeprogrammerCLI was a thing, i ran a bash script in a battery powered raspi zero and voila you got yourself a magic programming pen for your palls upstairs flashing devices in the production line.

Nowadays i use cubeprogrammerCLI , i didnt see those 20s delay youre talking about

hit me up in https://www.linkedin.com/in/javiermu%C3%B1oz/

kweenie · ‎2025-02-25

>>did you try using cubeProgrammerCLI? is the same issue happening there?

problem of programming time x 10 occurs in my case with a device ID 425, STMicroelectronics, Cortex-M0+, STM32L03x/L04x/L010, ARM 32-bit Cortex-M0+ based device.

Maybe there's an issue with this MCU ?

Kraal · ‎2025-02-25

@kweenieif you still have the 2.13 installed on your computer, can you try to copy the file STM32_Prog_DB_0x425.xml from the folder STM32CubeProgrammer\api\Data_Base as well as the file 0x425.stldr from folder STM32CubeProgrammer\api\lib\FlashLoader and past both in the installation of 2.18, in their repsective places ? And see if you come back to 2s with 2.18 ?

I have the impression that every update of CubeProgrammer induces some regressions for some devices.

Best regards.

kweenie · ‎2025-02-25

Hi Kraal,

I also (already) noticed a difference between v13 and v18 for the file STM32_Prog_DB_0x425.xml from the folder STM32CubeProgrammer\api\Data_Base: on line 537, the 'write protection' addresses are different, which seems odd, since the chip stays the same ?!

I followed your suggestion and also copied the 0x425.stldr file from v13 into v18... same result: 20s in stead of 2s.

I'll keep searching.... thanks for the suggestion