I am implementing an emulated EEPROM in flash memory on a STM32 microprocessor, mostly based on the Application Note by ST (AN2594 - EEPROM emulation in STM32F10x microcontrollers).

The basics outline there and in the respective Datasheet and Programming manual (PM0075) are quite clear. However, I am unsure regarding the implications of power-out/system reset on flash programming and page erasure operations. The AppNote considers this case, too but does not clarify what exactly happens when a programming (write) operations is interrupted:

  1. Does the address have a arbitrary (random) value? OR
  2. Are only part of the bits written? OR
  3. Does it have the default erase value 0xFF?

Thanks for hints or pointers to the relevant documentation.

  • \$\begingroup\$ It's good to develop an understanding of this problem, but have you considered a software solution? Transactional databases have ACID properties designed to solve this problem as it presents itself on magnetic and Flash media. You may want to read up on that topic and explore solutions like the implementation in SQLITE. \$\endgroup\$ Jan 23, 2012 at 13:52
  • \$\begingroup\$ Is it even possible to run SQLite on most STM32s? I also don't see how ACID compliant software is going to compensate for reliability concerns writing to flash on a micro controller. Regardless of the higher level software being used, the data has to be written to flash at some point... An atomic commit in SQL is not the same as an atomic write in hardware... \$\endgroup\$
    – radix07
    Apr 2, 2015 at 17:14

2 Answers 2


The short answer is that hardware is inherently unreliable. Something can always in theory go wrong that interrupts the write process or causes the wrong bit to be written.

The long answer is that Flash circuits are usually designed for maximum reliability. A sudden power loss on write will probably not cause corruption because the driver circuit may have enough capacitance or the capability to operate under a low-voltage condition long enough to finish draining the charge as necessary. A power loss on erasure might be trickier, because the high-voltage charge pump needs to complete its job. You really need to consult the manufacturer. The solution is probably just a sufficiently large power supply capacitor.

For a "soft" system reset with no power interruption, it would be pretty surprising if the hardware didn't always completely erase whatever bytes it was immediately working on. Usually the bytes are erased in a predefined order, so you can use the first or last ones to indicate whether a page is full or empty.

Are you trying to maintain integrity of the data with some external entity (for example, if the widget is active then its data is written), or just self-consistency of the data itself? In the latter, more reasonable case, you should focus on marking the successful completion of each write and erase operation within the Flash data stream, so incomplete operations get retried/ignored on reboot no matter the cause of failure.

  • \$\begingroup\$ Detection of incomplete writes/erasures (self-consistency?) are paramount. That is there will always be reasonable default value when corruption is detected. \$\endgroup\$
    – Arne
    Jan 23, 2012 at 9:12
  • \$\begingroup\$ @Arne: That is what your question asks for, right? But the question seems to be referring to hardware, not software. As for software, just ensure that the beginning and end of each erase and write operation have some identifiable effect, so there is a record upon reboot. \$\endgroup\$ Jan 24, 2012 at 2:44
  • \$\begingroup\$ well it's kind of hardware since there is not much software in between me, the registers and the MCDU... anyway I found a software solution although it wastes another address for writing a marker. The fact that the STM32 allows to write a arbitrary value to an erased address and later reset that to zero makes this possible. \$\endgroup\$
    – Arne
    Jan 24, 2012 at 20:15

In many flash devices, erasing a page/block/sector/whatever will require internally programming all bits to zero() and then performing an erase cycle on all bits simultaneously. Occasionally, it might be necessary to repeat this process(*). If it is required, such action would be performed automatically within the chip; the only visible consequence would be that an erase cycle would take unusually long.

(*) STM seems to use the opposite of normal convention; erased bits in its micros read "0", while programmed bits read "1".

(**) I've written software for a controller which had to perform all the steps "manually"; if some bits were "less thoroughly programmed" than others and finished erasing first, they could prevent the other bits from being properly erased, but reprogramming and re-erasing the bits would supposedly solve the problem. I don't know to what extent more recent flash devices deal with the same issues.

Because erasing a block first requires programming it to all zeroes (or, for ST, ones) one should not expect any particular behavior from a partially-erased block unless or until one has performed another erase cycle on it, and the latter cycle has been run to completion. Even if the page appears to be blank, one shouldn't trust it.. It is possible for bits which are partially programmed to sometimes read as blank but sometimes read as programmed. Writing to a seemingly-blank page may cause data loss if bits which appeared blank, and were supposed to be blank, were to start reading as though they had been programmed.

To avoid this problem, define your in-memory data format such that any time a page is in the process of being erased, one will be able to discern this by the content of other pages, without regard for the content of the page being erased. This can generally be declaring that a page should be considered partially erased if two other pages agree on that fact, and arranging things so that when a page is being erased, two pages will be fingering it, and no page is fingering any other which could also be fingered by the page being erased; once the erasure is complete, at least one of the pages that was fingering it should be programmed not to do so. Then, on startup, one will be able to identify that partially-erased page exists, regardless of the apparent contents of that page, and repeat the erase command to ensure a clean erasure.

  • \$\begingroup\$ Some STM32s erase to 0xFF and some erase to 0x00. The STM32F1xx series, the STM32F2xx and STM32F4xx all erase to 0xFF. The STM32L1xx series (low power) erases to 0x00. \$\endgroup\$ Aug 27, 2013 at 17:38
  • \$\begingroup\$ @MarkLakata: Any idea why ST decided to do that? From a hardware perspective, I would think it should be no more expensive to call the erased state FF and non-erased 00 than vice versa, and there's a pretty strong convention that memories that are programmed through charge implantation (as opposed to physically destroying fuses) have FF as the default state. \$\endgroup\$
    – supercat
    Aug 27, 2013 at 19:35
  • \$\begingroup\$ No idea why ST did this. It is annoying. It is also not just negated, it has a totally different flash interface, so you can't write 16 bits, you have to write 32, and you can't overwrite a memory location to all 0xFFFFFFFF (ie to fully obliterate it). There is some ECC mechanism that thwarts that, and randomly gives you a zero bit somewhere in your word, sometimes. I'll post updates if I discover why. \$\endgroup\$ Aug 27, 2013 at 22:05
  • \$\begingroup\$ See my posting here to continue the STM32L discussion: electronics.stackexchange.com/q/80412/15757 \$\endgroup\$ Aug 27, 2013 at 22:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.