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.

REG failure in reading NAND Micron, MT29F1G08ABADAWP-IT:D when connected to AM335x

Other Parts Discussed in Thread: SYSBIOS, AM3352

Hi,

I have been facing a problem in reading NAND Micron, MT29F1G08ABADAWP-IT:D when connected to AM335x for our custom board. presently am using an RTOS. Here the situation looks confusing. 

when am writing and reading the NAND subsequently, i could not find any mismatch in pages content. but when i write it and poweroff the NAND, later when i just read it after power ON. i could find that one of the blocks is filled with FF's which is creating a mismatch for several pages within the block. and its happening randomly for any block throughout the NAND memory whenever i read it from the start.  

Is it because of RTOS? i have stopped involving other tasks, as such the fault block changes(but overall happens with only one block). 

Could anyone please help me out from this situation??

Regards,

M.Shradhanand

  • Hi Shradhanand,

    Sorry for the delayed response.

    We have not come across such a situation with our GP EVM AM335x board which has a onboard NAND flash MT29F2G08AB when testing NAND performance using no-OS code of StarterWare.

    I suggest you try loading the  Nand example of the 2.00.01.01 StarterWare package, and see if you still come across such a problem.

    Regards

    Anant Pai

  • Hi Anant,

         We are experiencing the same situation using Critical Links AM3352 CPU module which contains a Micron 29F2G08ABAEA. Our system uses SYS/BIOS and NAND drivers from the industrial sdk 1.0.0.8 (am335x_sysbios_ind_sdk_1.0.0.8.) The NAND initialization and first read happen before SYS/BIOS is started, so SYS/BIOS does not appear to be the issue.

         If we do a NANDPageRead() first, it will return a NAND_STATUS_READ_ECC_UNCORRECTABLE_ERROR. If we do a NANDPageWrite(), all subsequent NANDPageRead's will return a NAND_STATUS_PASSED. For us it seems that the call of:

                /* Check for ECC errors and correct if any errors */
                retVal = (nandInfo->hNandEccInfo->ECCCheckAndCorrect)(nandInfo, eccData,(unsigned char *)rxData);

         on line #850 in nandlib.c, is where the bad return value is coming from on the read. We are currently trying to figure how the page write is effecting the page read ecc check, so any help would be appreciated.

    Thanks,

         John C.

  • As an update to our situation:

         The problem continues exactly as before. We have examined and compared the PageRead and PageWrite driver code as well as the ELM and GPMC registers settings during good and bad reads and can find no clear answer. In current tests we are reading/writing block 20 pages 0, 2, 4 and 6. If we add a PageWrite to block 20 page 60 before we do any reads, then the ECC checks on the reads will work correctly.

         Because the page reads work after a page write it seems that driver code works and SYS/BIOS is not interfering with register access. We have also not found anything in the NAND device errata sheet that would indicate any issue like the one we are seeing.

         Thanks,

         John C.

  • Hi Anant Pai,

    Actually am not using the starterware. iam using a custom board which is similar to starterware. but the point is that just few pin are changed and the RTOS being used is Quadros.

    Regards,

    M.Shradhanand

  • Further updates:

         It seems this problem has something to do with the ECC values being calculated during the page writes. Before we write our data structures to NAND, we pre-fill the structure with all one's (0xFF) and then copy our real data into it. This is done so that area in the NAND page beyond what we use will stay the value it was when it was cleared (all one's.)

          When the page is being written in the NANDPageWrite() function, the first 512 bytes gets a ECC value, the last three writes (512 bytes) of the page have all zeros in the ECC data. Every page we write after that always has zeros for the ECC data. If we let the NAND page writes go through, here is what we see.

         On the third page written (block 20, page 4) we see our data:

         Then in the spare area that contains the ECC data:

         The first two bytes are the bad block marker area, and the calculated ECC data is zero. This does not seem correct. If the StarterWare NAND drivers work then some how SYS/BIOS is causing problems with the ECC engine in the ARM (AM3352.)

         Any help would be appreciated.

    Thanks,

         John C.

  • Hi John,

    Sorry for the delayed response.
    Thanks for sharing the details. Can you clarify the following points??
    1: Is cache enabled in your system??
    2: Are you using DMA mode of GPMC engine?
    Please not that there is a bug in the nandlibrary when cache is enabled,
    which gives uncorrectable errors. This has been solved for Polling mode in the latest StarterWare
    release 02.00.01.01, for the DMA mode the issue is still under investigation.

    You can change the operational mode to CPU polling to test with Nandlib APIs.

    Can you incorporate these changes in your code? See if it resolves your issue?
    The changes are in the nandlib part of the starterware package.

    You can also try running the starterware Nand example and see if you are
    able to Read/Write from different pages.

    Hope this helps.

    Regards
    Anant Pai

  • Hi Anant,

          Thanks for the reply. No we are not running DMA. What we have found is that uboot has left something behind that was causing the errors. Because we have an FPGA attached we use some of the other GPMC registers. Because of that we commented out GPMC reset code in nand_gpmc.c (GPMCNANDInit() function) to keep from wiping out our FPGA settings. We still ran all the other code for setup, just not the GPMC reset. So when the GPMCNANDInit() function is run a lot of the GPMC register calls and/or bits into the current register contents(left over from uboot.) We are not sure which of the NAND GPMC registers was causing our issue, but if we reset the GPMC prior to setting up our FGPA and the NAND registers, everything with the ECC seems to work fine.

         Once I have a little more time I will find out which of the registers is causing the issue.

    Thanks,

         John C.