• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 1400 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.

AM3874 + NAND FLASH(MT29F2G16ABAEA) bit flip

Carl Ko
Intellectual 340 points
Other Parts Discussed in Thread: AM3874

AM3874 + NAND FLASH(MT29F2G16ABAEA) bit flip

 

Proceeds in conditions of AM3874 + NAND FLASH(MT29F2G16ABAEA), a phenomenon called "bit flip" is Baruse.

 

1. Development environment

     1)  H/W:

       CPU AM3874 + MT29F2G16ABAEA (NAND Flash memory)

    => H/W design was refer to TI-DM814xEVM of Mistral Solution. 

2)  SDK:

       EZSDK 5_05_01_04 for DM814x

3)  S/W configuration

        It was customizing using bootloader+kernel+ubifs rootfs that is released by the above SDK.

  2. Current problems

    1)  After the initial operating the B'D, bit flip phenomenon appears past one week, over time, to be appeared in most the samples.

2)   The result of investigation until now, Corruption bit data is changed from 0 to 1.

3)  In some of the nand flash, unstable bit phenomenon is also appeared.

4) File system is read-only of state, H/W is write protect, are either during storage after Power off or during operation after Power on, incidence of bit flip has no difference.

  3. Question

     - ECC limitations in omap2.c

      : In the omap_read_page_bch () function of the omap2.c official release, the if (! (chip-> ops.len & 0x7ff)) was to check the ECC only size that align with demand.

      However, looking at the recent history, it seems to delete this ECC limitations.

      Perhaps, seems to be changed from customers problems. There are a few questions about this.( This problem should be reported to the end customer.)

    Q1) ECC limitations is the reason been set? / Explain why that released?

    Q2) Please describe the various situations in which the bit flip occurs on the current platform?

    Q3) If you set a ECC limitations, in most of the developed product bit flip occurs.

      Platform writing programs to NAND FLASH, because is to first use, bit flip by ECC limitations is confused is normal or abnormal.

      And, when the ECC limitations is released, bit flip will recover all. Please to advise on the situation and precautions that can not be corrected by the bit flip.

    Q4) By improving the H/W Is there any way that can inhibit the bit flip occurs?

    Q5) Is Bit-flip problem is relevant according to the Flash download method? (Rom writer equipment or TI development tool)


  • 0
    TI__Guru**** 393215 points

    Moving this to the AM387X forum.

  • 0
    TI__Guru**** 170625 points

    Hi Carl,

     

    Carl Ko said:
    EZSDK 5_05_01_04 for DM814x

    This comes with not up-to-date linux kernel. The newest linux kernel is at:


    Please review all the NAND related patches that are not in your code base.

    Regards,
    Pavel

  • 0 in reply to Pavel Botev
    TI__Guru**** 170625 points
    ECC for u-boot is BCH8, while for linux kernel it also support (with the latest NAND patches) BCH16.
  • 0 in reply to Biser Gatchev-XID
    Intellectual 340 points

    Hi.

    Thanks for your answer.

    I content to be required is, describes the SDK and Nand flash Pactch that was used to development.

    The current state of progress is solved using the patch below the bit flip problem.

    “Patch => mtd:nand:omap2: cleaning of omap_correct_data for BCH8 ECC scheme

    What we need is a patch and if you use only sdk that have been following the official opening
    And describes the difference between when you add application.

    SDK => EZSDK 5_05_01_04 for DM814x

    Differences between sdk and patch are as follows

    <SDK.>

    -- if (!(chip->ops.len & 0x7ff)) {

    --                        stat = chip->ecc.correct(mtd, p, &ecc_code[i],

    --                                        &ecc_calc[i]);

    --

    --                        if (stat < 0)

    --                                mtd->ecc_stats.failed++;

    --                        else

    --                                mtd->ecc_stats.corrected += stat;

    --                }

     

    <patch>                                

    ++                stat = chip->ecc.correct(mtd, p, &ecc_code[i], &ecc_calc[i]);

    ++

    ++                if (stat < 0)

    ++                        mtd->ecc_stats.failed++;

    ++               else

    ++                        mtd->ecc_stats.corrected += stat;

    ++

    That is, an explanation as to why haneungeot need to delete the if (!(chip->ops.len & 0x7ff)).

    Data that customer requests is tricky.
    And you want to be a description of the troubleshooting.
    You would like to know that there is any difference from the standpoint of the developer.

  • 0 in reply to Biser Gatchev-XID
    Intellectual 340 points
    Hi.


    Thanks for your answer.


    I content to be required is, describes the SDK and Nand flash Pactch that was used to development.

    The current state of progress is solved using the patch below the bit flip problem.

    “Patch => mtd:nand:omap2: cleaning of omap_correct_data for BCH8 ECC scheme


    What we need is a patch and if you use only sdk that have been following the official opening
    And describes the difference between when you add application.


    SDK => EZSDK 5_05_01_04 for DM814x

    Differences between sdk and patch are as follows




    <SDK.>

    -- if (!(chip->ops.len & 0x7ff)) {

    -- stat = chip->ecc.correct(mtd, p, &ecc_code[i],

    -- &ecc_calc[i]);

    --

    -- if (stat < 0)

    -- mtd->ecc_stats.failed++;

    -- else

    -- mtd->ecc_stats.corrected += stat;

    -- }



    <patch>

    ++ stat = chip->ecc.correct(mtd, p, &ecc_code[i], &ecc_calc[i]);

    ++

    ++ if (stat < 0)

    ++ mtd->ecc_stats.failed++;

    ++ else

    ++ mtd->ecc_stats.corrected += stat;

    ++




    That is, an explanation as to why haneungeot need to delete the if (!(chip->ops.len & 0x7ff)).




    Data that customer requests is tricky.
    And you want to be a description of the troubleshooting.
    You would like to know that there is any difference from the standpoint of the developer.
  • 0 in reply to Pavel Botev
    Intellectual 340 points
    Hi.


    Thanks for your answer.


    I content to be required is, describes the SDK and Nand flash Pactch that was used to development.

    The current state of progress is solved using the patch below the bit flip problem.

    “Patch => mtd:nand:omap2: cleaning of omap_correct_data for BCH8 ECC scheme


    What we need is a patch and if you use only sdk that have been following the official opening
    And describes the difference between when you add application.


    SDK => EZSDK 5_05_01_04 for DM814x

    Differences between sdk and patch are as follows




    <SDK.>

    -- if (!(chip->ops.len & 0x7ff)) {

    -- stat = chip->ecc.correct(mtd, p, &ecc_code[i],

    -- &ecc_calc[i]);

    --

    -- if (stat < 0)

    -- mtd->ecc_stats.failed++;

    -- else

    -- mtd->ecc_stats.corrected += stat;

    -- }



    <patch>

    ++ stat = chip->ecc.correct(mtd, p, &ecc_code[i], &ecc_calc[i]);

    ++

    ++ if (stat < 0)

    ++ mtd->ecc_stats.failed++;

    ++ else

    ++ mtd->ecc_stats.corrected += stat;

    ++




    That is, an explanation as to why haneungeot need to delete the if (!(chip->ops.len & 0x7ff)).




    Data that customer requests is tricky.
    And you want to be a description of the troubleshooting.
    You would like to know that there is any difference from the standpoint of the developer.