Skip to main content
xelus
Associate
October 30, 2023
Solved

The 2.14 CubeProgrammer is slower than the 2.8 programming speed

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
Aziz BRIGUIBest answer
ST Technical Moderator
May 9, 2025

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 in thread

22 replies

kweenie
Explorer
February 25, 2025

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
    Javier1
    Principal
    February 25, 2025

    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ñoz/
    kweenie
    Explorer
    February 25, 2025

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

     

      xelusAuthor
      Associate
      February 25, 2025

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

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

        Javier1
        Javier1
        Principal
        February 25, 2025

        >>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ñoz/
        Kraal
        February 25, 2025

        @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
        Explorer
        February 25, 2025

        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

        Kraal
        February 25, 2025

        Hi @kweenie 

        Thank you for the quick test. I was really hoping that would help with the programming time, but that would have been too simple, haven't it ?

        Regarding the write protection address, it could be a real fix that has been made after v13, the only way to know is to look at the device datasheet, which is / should be the ultimate truth.

        kweenie
        Explorer
        November 21, 2025

        Hi Stevejon,

        the performance drop was aknowledged b y Aziz & his team.
        The v2.8 version was able to program in 2s.
        Then v2.15 went up to 20s (and regression was confirmed in this thread, for version 0x425).
        Now with v2.20 & v2.21 we are at 4s, but not back at 2s ?

        Same parameters, same hardware,... just different CUBE programmer. 

        Terms & ConditionsAccessibility statement