I am using a SPI-connected NOR flash (AT25DF321a) to protect data against loss during power failure.
But how is flash protected against power loss? What would happen if the power turned off during erase or programming? Is it possible to detect such cases programmatically? (checksums and so on)
For example, if an erase was interrupted, are there all "1"s on the beginning of the erased block? On the end? Or is it totally undefined?
I have the same question about programming: are bits programmed in some order?
Best Answer
Generally speaking, flash memory works by providing an erase operation that unconditionally sets bits to one state (e.g., all ones), and a separate program operation that selectively sets bits to the other state (e.g., zeros).
If a power failure occurs during either operation, it may have changed none of the bits, some of the bits, or all of the bits, and the bits might be in a partially-changed state. In other words, you pretty much have to assume that the contents are undefined.
When you know that a power failure has occurred (or any other unexpected reset), you need to do integrity checks on the affected areas of memory (assuming you know which ones they are) and restart the interrupted operation in order to make sure all of the bits get fully changed.
One way to manage this is to take advantage of the fact that you can erase a page of memory, and then selectively program bits in that page one at a time. This can be used to create a "status scoreboard" in which you record your intentions before doing a major operation on a block of memory. If a power failure occurs, you just need to look at this scoreboard page to determine which blocks of memory might be suspect and what operation needs to be repeated on them.
I once designed am embedded system that could have its firmware updated remotely. In order to make this as robust (and foolproof) as possible, I set aside two areas of flash memory that could each hold a full copy of the firmware. One area could be erased and programmed with an updated version while the other held the existing working version. The "trick" was that I kept the status byte for each area in the other area. On every reset, the boot code would examine both status bytes in order to determine which area held a valid copy of the firmware, and whether there were any partial operations that needed to be completed on either area.