I've encountered a systematic problem with the STM32L151 which I'm finding hard to debug.
We write a bootloader and main image to the flash memory using the ST-Link CLI, and at the same time write some individual configuration data to the internal EEPROM memory. The command usually looks something like this :
C:\Program Files (x86)\STMicroelectronics\STM32 ST-LINK Utility\ST-LINK Utility\ST-LINK_CLI.exe -c
-w32 0x8080000 0xaf000c -w32 0x8080004 0x18 -w32 0x8080498 0x0 -w32 0x80804a0 0x0
-P firmwares\bootloader-v1.3.hex -P firmwares\firmware-v0.8.12.hex
-V after_programming -Q 1>&2
All four operations complete successfully, and after a reset, everything performs as expected (this is what we've been doing on thousands of devices). In some cases though, the MCU gets reprogrammed in-system and it doesn't get powered down before use. It then remains powered on 24/7. The problem here is that in this state, the MCU is unable to write to its own internal EEPROM unless we force a reset. (after that, it works fine).
Obviously, the simple solution is "do a reset after programming them", but I'd like to know what's actually causing this, since I'm pretty sure some systems are getting stuck in this state on their own, regardless of how they were programmed initially. Is there something in the MCU registers that indicates that the EEPROM is badly initialized, or something like that? Or should I do a test read-modify-check on boot and reset the MCU if that fails?
I'm using the StdPeriph library, v1.3.1 and calling DATA_EEPROM_Unlock() before every write, and DATA_EEPROM_Lock() when finished.