• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 1092 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.

starterware nand driver creates bad blocks on write

Bruno Scherrer
Intellectual 820 points
Other Parts Discussed in Thread: OMAP-L138

HI,

I've designed a board with a C6748 and a mt29f4g16abadawp nand chip.

The nand flash is wired exactly the same way as on the LcdK schematic.

I've managed to have the nand example working (by the way I had to fix the pinmux configuration as it only initializes the lower 8bits of data).

After that bug fix the first tests I've made seem to be OK (erasing/writing and reading a single block at a fixed address as written in "nanReadWrite.c" code)

but as soon as I've tried writes on other blocks and of different sizes they all end up as bad blocks one after the other.

Right now I have 12 bad blocks: block0 to 8, block9 and blocks 4094 and 4095.

When i've started my tests I had only one bad block: block 0.  (even this one could have been corrupted by my first tests..)

I see 3 possible reasons:

- my code is corrupted (except the fix in the pinmux intitialization I didn't make any "sigificant" change...)

- the parameters do not correspond to my nand chip (although the dev info seem to be ok: Man. id:0x2C, dev. id:0xCC, PageSize:2048Bytes, BlockSize:128K,PagesPerBlock:64 (I'm using a Micron chip).

- The NandBadBlocCheck routine does not handle correctly my chip....

any help would be greatly appreciated!!!

Thanks

Bruno

  • 0
    TI__Guru** 116100 points
    Dear Bruno,
    I think, you don't want to change anything if you are using the same type of NAND chip (16bit data width)

    I would like you to suggest to refer to the following NAND writer CCS project.

    C:\ti\OMAP-L138_FlashAndBootUtils_2.40\OMAP-L138\CCS\NANDWriter

    nandwriter.c
    Just uncomment "#define NANDWIDTH_16" and comment "#define NANDWIDTH_8"
  • 0 in reply to Titusrathinaraj Stalin
    Intellectual 820 points

    Hi Titus,

    Thank's for your reply. I've used the source code as you've suggested in my low level driver and it seems to work ok.

    I have two new questions however:

    - First one is in respect to ECC errors that I catch on page reads that has been previously erased:

    Can you suggest a way to deal with this issue?

    - Is there some BBT source code in the sitara project or elsewhere (davinci...) that I can re-use in standalone?

    Thanks,

    Bruno

  • 0 in reply to Bruno Scherrer
    TI__Mastermind 43955 points
    Hi Bruno,

    Bruno said:
    - First one is in respect to ECC errors that I catch on page reads that has been previously erased:

    Can you suggest a way to deal with this issue?


    Do a NAND erase again and flash any sample binary using the NAND writer.
    By flashing the image, you can make sure that it will do both write, read, compare and verify that the image written is correct with ECC code.

    Or your question is somtheing like correcting the bad block or disabling the ECC??

    ----------------------
  • 0 in reply to Shankari G
    Intellectual 820 points

    Hi Titus,

    Actually I'm using parts of the NANDWriter (the piece of code you suggested) for writing my own flash file system driver for my application.

    The thing is: when I did my first tests the blocks that has been erased (i.e set to 0xff) were always detected as bad blocks on reads (NAND_readPage). Moreover the page was not read entirely so I could'nt even check read data against 0xff. I know that this kind of issue exists with hardware ECC but I do not know enough about it to fix my problem that way.

    Anyway I've found another way to deal with that problem in the meantime:

    I've modified the NAND_readPage routine so it always reads the entire page regardless of any ecc problem that could arise (it actually reads the page by chunks of 512bytes)

    This way I can check the read page against 0xff myself in case of ecc error in order to differentiate real bad blocks from erased ones.

    Seems to work...

  • 0 in reply to Bruno Scherrer
    TI__Mastermind 43955 points
    Hi Bruno,

    Glad to hear that you are able to solve.

    Thanks for the update.

    ---------------------