STM32 L0 Flash Writing issues.

[MCocke.1]

Hi ST Community,

I have inherited a product that runs on a stm32L051k8 mcu, and I am having difficulty with using the onboard flash memory. On boot, the product checks a certain location in flash to see if there are some configuration settings stored there, and if the flash storage is in an erased state, the mcu saves some default values to that configuration settings location.

What is happening is that sometimes after the first boot, those default configuration settings are not getting saved correctly, which causes the product itself to malfunction.

The only things we have found to fix a board that had a bad first time boot would be to re-flash the board with the UART boot-loader (we do not program the board using ST-LINK). Unfortunately, this is not a guaranteed fix as the board might have another faulty first time boot and still have corrupted config settings. Something else that we have tried that helps mitigate (but not solve) this issue is to add a ~100ms delay between power up and when we try to write to flash, to let the voltage to the micro-controller rise to the right value. But even with this delay, we are still seeing around 15% of all the boards we program have corrupted configuration settings.

Any help would be greatly appreciated.

Best,

Matthew Cocke.

[Tesla DeLorean]

Can it provide some interaction via the UART? Can it check or checksum the value written as a confirmation before ploughing onward? Can you use the UART to erase, or retry the write? Something that doesn't require a complete reprogramming to remediate..

Writes need to be to 64-bit aligned words, as I recall. You don't get a do-over. Could you use the EEPROM instead?

You say a 100ms delay helps. What if you put a thresholding MCP120 across reset monitoring the supply? Not saying as a solution, but to confirm or eliminate a possible cause.

[Danish1]

Writing to FLASH is a slow process (milliseconds) and consumes significant power.

How many bytes need to be written in these config settings? What would happen if power were lost part-way through writing the “default” config settings?

Could you alter your test-to-see-if-settings-are-present to check if the whole lot are present? Or perhaps alter the order in which settings are written (not necessarily their order in memory) so that the last write is the flag to say “settings are present”? (You’ll need to respect the physical size of FLASH writes for your STM32 to avoid trying to write to the same FLASH-word twice).