I was tinkering around some NAND flash memories and found out that some of them (not sure if it's all of them) have a few "redundant bytes" that are something of a mystery. (See related questions here and here.)

This part is from the TC58NVG0: TC58NVG0 nand flash

I'm wondering what the "other uses" are. What could we do with this part of memory which we can't do with the other part?

There is another one which is a SPI NANF flash gd5f1gq:

GF5F1 SPI NAND flash

What is this added 128 byte memory? Is it usable normally?

  • \$\begingroup\$ wear levelling? \$\endgroup\$
    – 2e0byo
    Commented Oct 4, 2022 at 22:11
  • 4
    \$\begingroup\$ The extra bytes are used for error correcting codes. NAND flash is not reliable. The extra bytes are required to correct for the expected errors. \$\endgroup\$
    – user57037
    Commented Oct 5, 2022 at 4:47

3 Answers 3


The redundant bytes are intended for use by file systems to hold metadata ('data about data').

A common metadata is an Error Correction Code (ECC), calculated on the 2048 data bytes. The ECC is used to detect and correct multi-bit errors within the data bytes. In very large flash storage ICs, bit error occurrence is likely and ECC is required.

Another example from the YAFFS file system is a write sequence number, which is an incrementing count used to identify the latest data block of a file for use.


The redundant cell array is not normally usable, as mentioned in the other answer by TonyM it is used for metadata about memory cell usage and for ECC.

Also it can be used to store timestamps to allow the data to be refreshed into a new block after a certain time to meet guaranteed retention time limits for the NAND memory cell, https://www.macronix.com/Lists/ApplicationNote/Attachments/1920/AN0339V1-Endurance%20and%20Retention%20of%20NAND%20Flash.pdf

And it is used for wear-leveling and further for differential wear-leveling were metadata about total tolerable error bit rate (which changes during the PE cycling lifetime) is kept and the wear-leveling is applied so that a maximum ECC rate is always implemented instead of the minimum ECC rate being used by default, https://www.usenix.org/legacy/event/fast11/tech/full_papers/Pan.pdf


The only way to erase and reuse a portion of a NAND flash array is to erase all of the pages in a rather large block. If one wanted to treat a "32 megabyte" flash array as holding 65,000 pages of 512 bytes each that could be written and rewritten, individually, in any order, but the hardware only allowed pages to be erased in groups of 64, one could, without using any extra storage on each page, process each page write by reading from the associated block the contents of the 63 pages one wasn't writing, then erasing the block, and writing the new page along with the contents of the 63 old ones. While this would work, it would be very slow and would quickly wear out the flash.

An alternative approach would be to use the "extra" storage associated with each page in the flash use two bytes to hold a two-byte logical sector number and a six-byte count of how many page writes had been performed during the lifetime of the flash. If there have been 1,234,567 page writes performed on the flash and one wants to replace the contents of page 1234, software could identify a blank flash page, and write the new contents of page 1234 along with an indication that the page which was written was page 1234, and it was the 1,234,568th write performed. At any moment in time, the correct contents of page 1234 would be held in whichever page identified itself as page 1234 and had the highest sequence number.

After one has performed about 65,000 sector writes, there may be a shortage of unused pages. When that happens, one could identify a block that holds relatively few if any "useful" pages of data (e.g. because of the pages it holds have been obsoleted by newer pages), copy the contents to some of the remaining blank areas in other pages, updating the sequence numbers so as to render the old pages obsolete. Once a block contains nothing but blank or obsolete pages, the block may be safely erased, thus allowing the pages on it to be reused.

From a practical standpoint, having to search through the entire memory array to find the most recent version of each page would be absurdly slow. This difficulty can be overcome by caching page locations, but the mechanics of doing this efficiently would be beyond the scope of this answer. The key point is that the "extra" storage associated with each page can be used to accommodate an arbitrary mapping between pages in flash and logical pages seen by the application.


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.