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.

Intermittent Problems After Nand Migration on DM365

Hi

We recently switched nand chip on our product (from 48nm [MT29F2G08AADWP-ET:D] to 34nm [MT29F2G08ABAEAWP-IT]) and we have been seeing some weird issues. There were regular crashes and there were a couple times where the uboot param partition got erase all by itself.

We are using u-boot 2009.03 and linux kernel 2.6.32.17.

 

Below is a table of the differences of the 2 Nand chip from Micron:

Micron TN-29-52: Migrating 1Gb 48nm and 2Gb/4Gb 57nm SLC NAND Flash Memory to 34nm

 

Feature 1Gb 48nm, 2Gb/4Gb 57nm 1Gb, 2Gb, 4Gb 34nm
ECC 1 bit per 528 bytes  4 bits per 528 bytes or on-die ECC
Vendor ID 20h  2Ch
RC/WC 25ns (3V), 45ns (1.8V)   20ns (3V), 25ns (1.8V)
BERS 1Gb: 1500µs (TYP)  2Gb: 2000µs (TYP)  700µs (TYP)
Command set    ONFI and legacy    ONFI
Block0  Valid at shipment  1 bit/528 bytes ECC Valid at shipment, 1 bit/528 bytes ECC up to 1K  PROGRAM/ERASE cycles
RESET at power-on Not required Required

                                           

One thing I am wondering is if we are doing the "RESET at power-on" . So which part of the dm365 is supposed to do that? How do I verify that it is doing it?

 

Any other ideas on how to make sure things are compatible??

 

Thanks!!

Roy

 

 

 

  • Roy,

    Are you still looking for the solution? The reset command can be issues by sending the 0XFF command. But I don't think reset it the exact problem here. The new NAND ha an additional feature "Internal ECC engine". This will calculate the ECC and store it in the spare area by itself. To get the device bootup from NAND properly, you might have to disable this feature, while writing the data. I'm not sure whether its disabled after reset. You can enable or disable this feature by SET_FEATURES command.