STM32L4 fails to boot after the battery ran out

[mehrdad mir shafiei]

We had a sensor based on STM32L4 installed in the field for a few days. It worked fine until the battery died and the device turned off. The problem is the MCU could not boot up after connecting it back to power. After connecting via SWD, STLink indicated that the device had become read protected. We set RDP=0, and noticed that the flash contained 0xFFFFFFFF meaning that somehow the program got wiped out. Reprogramming the device solved the problem but this is unacceptable since clients cannot do this.

My only guess is that BOR was LEVEL 0 and maybe when battery was low voltage the flash got corrupted.

Any ideas about the reason and how to resolve this problem?

Thank you!

[Tesla DeLorean]

Well changing the RDP to an unprotected state WILL erase the memory.

Does your code erase/write FLASH in normal operation?

[mehrdad mir shafiei]

Thank you for the prompt reply!

Yes, we can reprogram it under normal operation.

[Jack Peacock_2]

There is a minimum voltage needed to program internal flash. You may be lower than this threshold when writing. Also, since you're running on a battery, you have to remember that battery chemistry is important at low voltage. If you check the battery (i.e. sample VBAT pin or derive Vdd from Vrefint voltage) the voltage may seem to be above the threshold, but the current demand increases dramatically when you erase/update flash, which can cause the battery to droop into unreliable range.

Set your PVD threshold above the flash minimum voltage (should be in datasheet for your IC). That way you'll get a notification if the flash erase/update will fail.

Jack Peacock

[Tesla DeLorean]

That wasn't the question. Does your code modify the flash content whilst running?

[mehrdad mir shafiei]

No, we do not modify/write anything to the flash while it is running.

[waclawek.jan]

You've said it yourself: use BOR, or, if the voltage levels provided by the built-in BOR won't suit your application, an external voltage supervisor/reset circuit.

JW

PS. I know it's not a very appropriate comment, but reading

> STM32L4 installed in the field

I instantly imagined an agricultural application, a device built around an STM32 literally sitting on a field...

[Danish1]

When you supply your device, do you leave it at RDP level 0 (so that anyone, including your competitors, can read out your code) or do you protect it by putting it at RDP level 1 or level 2? Looking at your question, you imply that it should have been at level 0 but you found it to be level 1.

Another way to protect code is to store "magic" numbers in RAM. Such values will be lost if power is removed for all but the shortest duration. This is true even for the "backup" RAM in the Real-Time Clock and SRAM2 (both of which can be made to retain their values when the rest of the microcontroller is powered-down -- but ONLY if VBat is still powered).

STM32L4 does not have any EEPROM for storing values that must survive loss-of-power. (But it is possible to use some pages of FLASH to emulate EEPROM, and ST have an application note showing one way to do this).

Hope this helps,

Danish

[Tesla DeLorean]

So probably not errant code execution then. I'm not aware of a specific issue with flash or options being unlocked, erased or written simply due to low power conditions.

If you get a device in this condition probably best to examine, but not alter the part, so there is some chance of getting an FAE or someone at ST to do fault/failure analysis. Definitely report and query your FAE as to other instances where this has been seen, or documented.