NAND FMD with 8 bytes ECC RRS feed

  • Question

  • Hello,

    I need to use 4bit on-die ECC of a new Micron NAND flash (x8).

    I enabled it correctly thanks to the command "SetFeatures".

    Now, my problem is that the spare area mapping (16 bytes) for one sector is set as below:

    bytes 0 and 1 : reserved -> 0 is for badblocks

    bytes 2 and 3: user metadata 2

    bytes 4 to 7: user metatdata 1

    bytes 8 to F : ECC/parity

    So I have only 6 bytes in user area to store information. And I need to store the SectorInfo whom size is 7 bytes...

    Does anyone have an idea on how I can do using the existing FAL ?


    Wednesday, January 25, 2012 4:24 PM

All replies

  • What about Byte-1? It is also reserved?

    Can I have the array organization picture of the NAND and Part number for the NAND?



    Friday, January 27, 2012 5:41 AM
  • Thanks for your answer,

    Yes, unfortunatly byte 1 is also reserved.

    The NAND I use is the MT29F2G08ABBEAH4.

    Its organization is:


    And when enabling the on-die 4-bit ECC, spare mapping is:

    Friday, January 27, 2012 7:25 AM
  • Hi,

    I see that 64 - bYtes Spare Area for 2K Size.

    For 4-Bit ECC is it requires 16-Bytes for 2K or 512 Bytes?

    Sorry, I don't have any solution other than using 1-Bit ECC.



    Friday, January 27, 2012 8:47 AM
  • From the MSDN page, it looks to me like SectorInfo is 8 bytes, not 7.  Also, the FAL makes updates to the SectorInfo.  Does the NAND device allow multiple writes between erase?

    Can you use 2KB sectors?  I think the Sector Info would be the same (8 bytes) in this case, but you could spread it across the available 24B for metadata however you want.



    Saturday, January 28, 2012 6:17 AM
  • Yes, you are right, I made a mistake, SectorInfo is 8 bytes.

    Unfortunately it is required to have 4-bit ECC for 512 bytes so using 4-bit ECC for 2KB is not in the specifications.

    What I am suspecting is:

    - the 4-bit ECC on-die is not compatible with the FAL, am-I right?

    - the way is maybe to implement the 4-bit ECC by software. In this case, where can I find some code examples ?

    Thank you again for your answer and suggestions !


    Thursday, February 2, 2012 9:52 AM
  • Hi Sandrine,

    The FAL includes a single bit correction ECC, but you don't have to use it.  Refer to the NOR flash FMDs, like FASL, to see an example of storing the SectorInfo structure without the ECC.  Does your NAND datasheet suggest a 4-bit ECC method?  Maybe Reed-Solomon codes?  Maybe your flash manufacturer provides the code on their website...

    I wasn't suggesting 4-bit ECC per 2KB, but rather you follow the datasheet recommendations to write 4-bit ECC per 512B.  I was suggesting you use 2KB sectors at the file system level to reduce the metadata overhead.  This way, you can write the 8 byte SectorInfo structure once for a 2KB page instead of once for each 512B.

    Are you writing your own FMD, or modifying an existing one?



    Thursday, February 2, 2012 4:27 PM
  • Hi Gary,

    Thank you for your feedback.

    First of all, datasheet doesn't suggest any ECC method, probably they assume that we have to use the on-die 4-bit ECC...


    Today, I have disabled the 1-bit ECC software, define a sector size of 2KB and spread the SectorInfo structure in the available spare memory.

    Unfortunately, at each reboot, my flash partition is formatted -> hive base registry is not saved and file in the partition disapperaed.

    -> Probably it comes from my spare mapping ? Have you another idea ?


    The FMD I use come from the BSP which has been developped for the evaluation kit of the AT91SAM9G45.






    Friday, February 3, 2012 4:28 PM
  • Hi Sandrine,

    I missed that the 4-bit ECC is on-die.  So does the chip automatically calculate the ECC for you?  Does it automatically correct data during reads?  EZ NAND?

    I'm not sure why your flash partition is being reformatted during each boot.  Do you have AutoFormat and/or AutoPartition registry settings set to 1?  Can you use the CE debugger to find why the disk is not detected on bootup?



    Sunday, February 5, 2012 4:08 PM
  • Hi Gary,

    Yes, the chip calculates the 4-bit ECC automatically and corrects data if possible.

    I found why my partition was formatted at each startup: I made a mistake in one of the offset I used to store SectorInfo into spare area... The system pointed in a reserved address...

    But now I face to a new issue with the flash: data written in it are corrupted.

    My test: copy in file system (via ActiveSync) an ASCII file of 13MB and then read it and compare the 2 files (the original file with the one read). Some bytes are changed... If the file is read several times (via ActiveSync) and compared, the files read are always the same. If I copy the file again in the embedded file system -> files don’t match…

    So for the moment I try modifying the flash timings since using on-die ECC modify some timings but for the moment it doesn’t work.

    Thank you again for your help and suggestions which allow me to go further.

    Let me know if you have some other ideas about the flash write issue…



    Tuesday, February 7, 2012 2:53 PM
  • Hi Sandrine,

    It sounds like you are writing a file to the target using ActiveSync and then reading it back by ActiveSync, is that right?  It sounds like if you read the file back several times, it's consistent, but different from the file you wrote initially.  So this seems to indicate a problem with the file write. 

    Can you explain your statement: "If I copy the file again in the embedded file system -> files don't match."

    Out of 13MB, how many bits are wrong?

    Do you see any patterns?

    Does the corruption seem linked to a physical location in flash?

    Can you detect the corruption consistently with a smaller file?  That might be easier for you to debug...



    Tuesday, February 7, 2012 9:07 PM
  • Hi Gary,

    Your analyse is right, it sounds like a write issue.

    What I mean by "If I copy the file again in the embedded file system -> files don't match.", is if I copy

    the file with a "copy/paste" directly on my target without using ActiveSync, the file written is not the

    same as the original, so it is not a problem due to ActiveSync. 

    Out of 13MB it dipends but it is about 30 bytes which are different.

    No I can't see any patterns.

    For the moment I don't know if it is linked to a physical location, I don't check the address of the file.

    With a really smaller file (in KB), no error occured. But I will take into account your remark and make a

    smaller file !!!

    What I think now is that when I write a page, I write the 2KB but for allowing NAND to calculate properly the ECC, I have to write partial-page of 512 bytes each. So I will split the writing in 512 bytes.

    I will keep you informed!

    Many thanks and Regards,


    Wednesday, February 8, 2012 11:01 AM