This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

What is the real nRF52840 max writes to a flash block?

The nRF52840 OPS 0.5.1, describes nWRITE,BLOCK as the amount of writes allowed in a block between erases, and lists nWRITE,BLOCK = 403 Maximum.

It looks like 8 blocks are in a 4 kB page, so each block is 512 Bytes.

Does this mean that only 403 of the 512 bytes in a page can be written? Or does the 403 number mean something else?

Parents
  • Ah, the NVMC only supports 32 bit write operations, so it takes 128 write operations to write the entire 512 byte block. That leaves 275 additional writes available to overwrite individual addresses within that block.

    So the entire block can be written without violating the nWRITE, BLOCK spec. And there are enough additional writes to allow the entire block to be overwritten a second time.

  • For nRF52832, nWRITE,BLOCK is specified as 181.

    The reason why we have a nWRITE,BLOCK limit is because flash memory is made up of floating-gate transistors, where each bit is stored as a charge on an isolated floating gate of a transistor. Writing to a block may affect all charges inside that block, which means bits will eventually start flipping inadvertently. The restriction of nWRITE,BLOCK writes within the block ensures safe operation. The full block becomes "fresh" again on erase, at which point the write counter is reset to nWRITE,BLOCK

Reply
  • For nRF52832, nWRITE,BLOCK is specified as 181.

    The reason why we have a nWRITE,BLOCK limit is because flash memory is made up of floating-gate transistors, where each bit is stored as a charge on an isolated floating gate of a transistor. Writing to a block may affect all charges inside that block, which means bits will eventually start flipping inadvertently. The restriction of nWRITE,BLOCK writes within the block ensures safe operation. The full block becomes "fresh" again on erase, at which point the write counter is reset to nWRITE,BLOCK

Children
  • Hello, looking to revive this older thread instead of starting a new thread since my question directly builds off this response. We are finding this limit to be quite restrictive when trying to use status bits or keep any type of count going before requiring a full page erase for a single bit changing. 

    When you say "bits will eventually start flipping inadvertently" does this mean during write time or volatilely? If bits only flipped at write time then this issue could be navigated easier by doing a sanity check after every write beyond the 2nd. Whereas if the bits could volatilely change at any indeterminate time after a write beyond the 2nd, this would make it considerably more difficult to do a sanity check on.

    Thank you.  

  • It’s out-of-scope, so the behavior is not defined. But I believe that it could potentially happen at both write time and volatility.

Related