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,

[kweenie]

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]

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

check OpenOCD
Or wait untill ST patches CubeProgrammer.

[kweenie]

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

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

[xelus]

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

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

[Javier1]

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

[kweenie]

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

@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]

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