How many times can flash be rewritten before an erase is required?

Question

With flash memory, it's only possible to write by clearing bits from their erased (set) state, and the only way to set a bit is to erase the region containing it. If you only need to clear bits, then you can hypothetically rewrite a section of flash up to as many times as there are bits in that section before needing to erase it. However I've noticed that Atmel's SAM-D parts specify a stricter limit on this. Section 37-12 of the SAM D21/DA1 family datasheet:

Note that on this flash technology, a max number of 8 consecutive write is allowed per row. Once this number is reached, a row erase is mandatory.

I've looked through a few other datasheets for other MCUs and some flash memory ICs, and so far the SAM D21 datasheet is the only place I've seen a limit like this specified. Since the Atmel datasheet gives this only as a note and not as a qualified specification, I'm not sure if this limit is based on worst-case conditions (such as voltage, temperature, or number of cycles). I suppose that this limit can vary with the specific technology used (hence the mention in the Atmel note), but in that case I don't know what specific characteristics of the D21 flash imposes this limit.

I don't expect it's reasonable to expect that you can actually clear every single bit in a region individually, but if there is a general limit on the number of rewrites before an erase is required I've not been able to find a reference for it.

There is clearly a lower bound on this, which is imposed by the way that flash is generally organized: specifically the fact that the minimum size that can be erased at once is generally a multiple of the minimum size that can be written at once. For example, the aforementioned SAM D21 writes per "page", but erases per "row", and since there are four pages per row, it must be possible to write to a given row at least four times before an erase is required if all of the flash is going to be used at once.

Beyond this lower bound, in the absence of a clear datasheet specification, is there a general rule or guideline for the minimum or maximum number of times a portion of flash can be safely rewritten between erases? What if any, specific characteristics of the memory technology would influence this limit?

Edit to clarify: I'm not concerned with overall write/erase endurance here, that's typically well specified and separate from the rewrites-per-erase spec I'm asking for. And for the purposes of this question, we can assume that any rewrites are within whatever write size the flash supports.

Answer 1

Whether the datasheet mentions it or not, cell clearing in usual MCU flash blocks tends to "smear" across adjacent cells a bit, so if you clear a cell repeatedly, the cell will be cleared, but other cells that were set will drift towards the threshold. In other words, the byte/row writes are somewhat fuzzy, and you can be writing exact same contents repeatedly and it will degrade said contents. Some flash IP limits this with extra transistors and larger geometry so that cells that are not being cleared are made inert and are not affected by what's going on. But this costs die area, so it often won't find its way into the primary program flash.

Sometimes repeated clearing of a cell without intervening erase cycles will change the properties of the cell, permanently degrading it. Some datasheets make a point of mentioning it, others don't but if you face problems and get a reply from product support, they'll tell you "oh, by the way, you are not supposed to do that" (BTDT).

If there's a special memory area for use as a "built-in EEPROM", it may use such more resilient circuitry, since the global space penalty is low as there are much fewer bits in that small EEPROM than they are in code flash. If that EEPROM is resilient against repeated writes, it's usually a marketable feature, so will figure prominently on the datasheet. Sometimes it is a design intent but production yields are too low to keep it in the final product, and a memory area may get "de-specified". Then you will find that some batches are better than others. But it's then a gamble of your own doing.

Most generally speaking you are guaranteed one good write. That's just for the flash to be functional. Two writes are a typical limit unless the datasheet specifically mentions otherwise. If it doesn't mention it, you must assume that one good write is assured, and the second one usually works. Beyond that - who knows.

Answer 2

I've had recent experience with the Samsung K9F8G08UXm. This is an 8 Gbit device organized as follows:

1 page = 4096 main + 128 extra = 4224 bytes

1 block = 64 pages

1 device 4096 blocks

Looks sort of like this:

The device is erased on a block basis, or 64 pages at a time.

Once a block has been erased, each page within that block can be written to one time. A page cannot be re-written unless the entire block is erased. You can write to different pages within a block at different times; that is, all pages within a block do not have to be written at the same time.

Answer 3

Just stumbled on this question while troubleshooting some errors I'm encountering on a SAMD51. In my case, I'm doing repeated writes to the same Flash location in a bootloader, to increment a counter. The counter values written are chosen to only clear bits, so that I don't have to erase the row every time. This bootloader is based on one I wrote for SAM21, which works well, but on SAMD51 I get into trouble after two writes to the same flash location. No error flags are set when the second write is performed, but subsequent reads of that Flash location trigger ECC errors. Once the flash location has been written twice, the problem persists across power cycles and resets, that is, I get ECC errors no matter how many times I read and clear the ECC errors. I found this interesting, because the SAMD51 data sheet does not have the same warning about limiting writes per row to 8 as the SAMD21 datasheet. By chance, the old SAMD21 bootloader that I wrote doesn't try to do more than 8 writes to the same location, and it has never given a problem.