STM32CubeIDE fails loading "big" software in Flash. Mass-erase the flash as workaround but not stabl

[Pecre.1]

HI,

We have an STM32L55CC with 256k flash on our board.

Debugging was OK with a first version of 75Kb flash. A current test version tops at 204kB. And then the troubles began.

Quite often the download in flash failed. I dind't find any soution on google and elsewhere.

Seeing that I upgraded my CubeIDE and the driver of the ST/LINK V2.It works for some times and afterward stopped working. As I was working on the memory map I was messing all around modifying my map back and forth.

Finally after having seen this

https://community.st.com/t5/stm32-mcus-products/can-t-enter-into-debug-mode-after-writing-to-the-stm32l073/m-p/659060#M240303

I tried to mass-erase the flash from the STM32CubeProgrammer. After that I can reload the software and debug.But it is not stable. After a few downloads it breaks again, I mass-erase the flash and it restarts.

Any ideas? Thanks in advance

[SofLit]

Hello,

Just to unblock the situation: if you add mass erase command before to upload the application:

add: monitor flash mass_erase command as startup command.

Go to the startup tab in the debug configuration and add "monitor flash mass_erase" as an Initialization command like the following:

Does at least workaround the issue?

[Tesla DeLorean · Accepted solution]

Are we sure this is a bug, or a design failure on the board and power supply?

Flash programming can be impacted by voltage, voltage stability, and temperature.

For ST-LINK, I'd be wary using it though hubs, and docking stations, and use quality cables.

You could do a verification pass, and you could do integrity checks of the images downloaded onto the device. In critical systems it is typical to checksum or CRC the firmware to ensure it was written completely and correctly.

STM32L55CC ?? You mean the STM32WL55CC