The 2.14 CubeProgrammer is slower than the 2.8 programming speed

[xelus]

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,

[Kraal]

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]

I replaced the '425' files (html or stdlr) from v13 into the corresponding v18 folders for these folders:

• C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\api\Data_Base
• C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\api\lib\FlashLoader
• C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin\FastROM_Data_Base
• C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin\FlashLoader
• C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\Data_Base

AND..... bham, back at 2s ???

[kweenie]

and now ?

who can 'forward' this to ST ?

[Kraal]

Excellent, kudos for digging deeper and getting it to work !

Then again, why should it need the files scattered in 5 different places ?

[kweenie]

@Aziz BRIGUI

Hi Aziz,

did you notice this thread ?

Just to inform you that also v2.19 flashes the '425' chip (ID 425, STMicroelectronics, Cortex-M0+, STM32L03x/L04x/L010, ARM 32-bit Cortex-M0+) 10x slower than previous versions ?!
I think this was broken in v2.12...

Any comments on the STM side ?

[kweenie]

@Aziz BRIGUI 

Aziz (or anyone else), 

how/where can I open a support request for this (since you are not reacting) ?

[Aziz BRIGUI]

Hello @kweenie,

Thanks for bringing this to our attention.

We are already investigating the concerns you raised internally (Internal tracking number: 205049).

Please be patient, I will get back to you ASAP.

Aziz

[kweenie]

Hi Aziz,

no news ?

[kweenie]

@Aziz BRIGUI 

Aziz ??

[Aziz BRIGUI · Accepted solution]

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