5
\$\begingroup\$

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.

\$\endgroup\$
7
  • 1
    \$\begingroup\$ I've worked with an ST part recently (I think it was an STM32F427) which would only allow a flash write from 0xFFFF to some value, and then from that value to 0x0000. Anything else required an erase back to 0xFFFF. Even something like 0xFFFF -> 0xAAAA, then an attempt to write 0x5555 (expecting an end result of 0x0000) would be rejected. \$\endgroup\$
    – brhans
    Nov 18, 2020 at 20:41
  • \$\begingroup\$ I've worked with the ATSAM4S and it has two ratings 10k cycles @85 degrees C and 50k cycles at 50 degrees C. I've also worked with a pic16f887 where the max write cycles was 1 million. I've written to the same sector more than 1 million times and it still works fine. That rating is just a guarantee that it will last at least that many cycles. \$\endgroup\$ Nov 18, 2020 at 20:43
  • \$\begingroup\$ @brhans thanks, do you have a reference for that, or was it something you found in testing? Did you find it was a hardware limitation, or perhaps a limitation in a library you were using? Would also like to know if it would have accepted a write from 0xFFFF -> 0xFFAA -> 0xAAAA or similar, where the write would only clear bits, not attempt to set them. I wouldn't be mad at a hardware or software limit that threw an error on attempting to set a bit in flash. \$\endgroup\$
    – ajb
    Nov 18, 2020 at 22:27
  • 1
    \$\begingroup\$ I'm not sure if it's exactly what you are hitting here, but beware the ECC flash as used on some SAMD's) generally can't be overwritten and yield correct readback, and may not even be writeable at word granularity (I seem recall running into a case that required doublewords...) \$\endgroup\$ Nov 18, 2020 at 23:01
  • 1
    \$\begingroup\$ I was confused about the device - it was one of the STM32L0 family, but I can't remember which one. The behavior was particularly annoying because even trying to change something like 0xFFFA to 0xFFF8 (clearing a single bit) would fail, while 0xFFFF to anything would work fine and anything to 0x0000 would also work fine, but if any 1 or more bits was cleared then the only write which would succeed was 0x0000. \$\endgroup\$
    – brhans
    Nov 19, 2020 at 0:08

3 Answers 3

2
\$\begingroup\$

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.

\$\endgroup\$
0
\$\begingroup\$

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:

enter image description here

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.

\$\endgroup\$
3
  • \$\begingroup\$ This is NAND flash; it is drastically different from the MCU NOR flash being asked about. This really has nothing to do with the question of this page. \$\endgroup\$ Nov 20, 2020 at 2:15
  • \$\begingroup\$ The question title says nothing about the specific type of Flash, but seems to be a question about Flash in general. And there is nothing in the text of OP's question that indicates the type of Flash involved. The first time NOR shows up on this page is in your comment. \$\endgroup\$
    – SteveSh
    Nov 20, 2020 at 11:33
  • \$\begingroup\$ Untrue. The question itself speaks only and specifically of MCU built in flash. That is NOR flash. You have posted about something quite different. \$\endgroup\$ Nov 20, 2020 at 15:29
0
\$\begingroup\$

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.

\$\endgroup\$
1
  • 2
    \$\begingroup\$ Without having looked into the data sheet, I assume that the checksum (stored in flash, too) needs bits set back to 1 that are 0 from the value before the second write. You might want to research that and to extend your answer if this is the case. \$\endgroup\$ Feb 27 at 20:26

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.