Writing Flash on STM32

Question

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.

Answer 1

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.

Answer 2

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.