• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 97 subscribers
  • Views 292 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

OMAP35x - ROM code's behavior with on-die 4-bit ECC enabled

Sebastien Ronsse
Prodigy 20 points
Other Parts Discussed in Thread: OMAP3530

Hello,

We are working on an OMAP3530 design which uses the MT29C4G48MAZAPAKQ-5_IT nandflash + RAM POP part.

As you know, this nand flash requires a 4-bit ECC correction for block 1 and above and 1-bit ECC for block 0.

When the board is turned on, the on-die engine is off at that time and the BOOTROM reads block 0 that was flashed with 1-bit ECC with no issue. However, as it mentioned in NAND ECC related wiki: http://processors.wiki.ti.com/index.php/Raw_NAND_ECC, there might be an issue after a warm reset because the ECC engine is still enabled. This is something that we cannot control in software (for instance after a watchdog reset).

Even in this specific use case, the board still boots after a warm reset - from the link above the following is stated : "Because of this the system will either fail to boot because the ROM code will try to correct the "errors" that it sees from the conflicting data, or it will boot because there are too many errors so it will just send the raw data without correcting. ". We assume that there is still a chance that the boot can fail, but the probability is extremely small. For this to happen, the actual data representing the 4-bit ECC in the spare area would have to somehow be able to falsely "correct" block 0, and the chances for this would roughly be one out of millions. Is that a fair statement and do we have a clear understanding of this use case?

Furthermore, when no correction can be made, the NAND flash should return an error after sending a  READ STATUS command. Since the board is actually booting, could you confirm that the ROM code does NOT take this status into account?

Regards,

Sebastien

  • 0
    TI__Genius 9190 points

    Hello Sebastien,

    To avoid this reset issue if you can cycle power to the NAND whenever you get a reset then you will not have to worry about this.  Is this an option for your system?  When you cycle power to the NAND it defaults back to external ECC. 

  • 0 in reply to Jeff Culverhouse
    Prodigy 20 points

    Hi Jeff,

    Thank you for your answer.

    I understand the problem can be solved by power cycling the NAND but this is not an option for us at the moment unfortunately. We want to make sure that our observation is correct : it seems the ROM code is not reading the NAND status or at least doesn't fail loading XLDR when 4-bit ECC is enabled, but we would like confirmation by TI.

    We also would like some feedback on the statement we made earlier about the fact that the chances of "wrongly correcting" block 0 tend to zero. If we understand correctly, it is also possible to prove that such a case won't happen by calculating all the possible ECC computations when XLDR has 1-bit modified and compare those to what is currently stored into our NAND spare area. The chance of those matching is almost impossible, but Micron still states that resetting with on-die ECC enabled  should be avoided. As we don't have have clear numbers, we would like confirmation by TI that this thought process is correct.

    Regards,

    Sebastien