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.

  • 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

1 Answer 1


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.

  • \$\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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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