• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 101 subscribers
  • Views 203 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM3354: AM3354 NAND flash typical ECC correction rate

siangming foo
Prodigy 20 points
Part Number: AM3354

May I know if anyone has done a study on their NAND ECC correction rate? What is an acceptable correction rate?

I am getting ECC correction rate of around 50% - 75% across 2 different NAND manufacturers. i.e. 50-70% of the NAND sector reads will result in an ECC correction taking place.

This does not look normal.

thanks.

  • 0
    TI__Mastermind 29180 points

    Hi,

    50% - 75% rate of ECC errors feels quite high, unless there is a reason. They are all 1-bit errors (correctable)?

    I found one related paper but they study MLC NAND instead of SLC NAND that is supported by AM335x.
    https://ieeexplore.ieee.org/document/4558857

    AM335x only supports SLC NAND since MLC NAND usually requires more ECC bits than GPMC supports.
            
    I am assuming SLC NAND is used. What are the ECC requirements of each NAND and what ECC scheme is used by the processor (BCH8, BCH16?)
    Can you isolate if the errors are write or read errors?
    Do you see any 2-bit errors as well as 1-bit errors? This could be a problem if your NAND management software sets the bad block marker. The available capacity of the NAND will get smaller with each block that is flagged as bad.

    Is it possible to populate the NAND on a TI EVM to reproduce? It could rule out any board issue.

    Regards,
    Mark

  • 0
    Prodigy 20 points
    1. We are using the BCH8 scheme on the processor. Our NAND has a layout of 4096 blocks, 64 sectors / block, 2048bytes + 64bytes (spare) / sector. The NAND datasheet says minimum required ECC is 4-bit per 528.
    2. Yes, we are able to determine that the high ECC occurrences are due to sector reads.
    3. For the ECC reported during each sector read, the errors are spread out i.e. combinations of 1-bit to 8-bit errors per 512bytes.
    4. Yes, we could try that out.