Forums

Frank,

I think the device should work without any issues. I have checked both the datasheets.

1. 4-bit ecc can be supported in both devices (64 bytes spare area).

2. The reset command (0xFF) is required for the MT29F2G08AADWP also.

3. The manufacturer ID is same for both the devices. 0x2C. Only device ID is different, which shouldn't be a problem.

How did you flash the NAND using external programmer? Is it using the same ECC algorithm that the bootrom needs? Is your programmer able to do a write and read back properly?

Have you tried using the CCS application NANDWriter for flashing the image?

Thanks for the quick response. I had thought that the device should work too.

Regarding the device ID, they both should be 0xDA according to the datasheet, right? I agree that I don't think that this is a problem, though, since 0xDA is in the RBL's supported device table.

For the external programmer, the exact same ECC was used as before. No changes were made, but I can always double check.

I am using the commandline utility sfh_DM35x.exe to program the Flash via the UART. I've tried a couple boards with the new Flash. The sfh_DM35x utility completes successfully for both like normal, but neither board shows the UBL or u-boot messages via the UART when they boot. If the new Flash part is unsoldered and an old Flash part put in its place, everything works perfectly.

The only change is the Flash part. I made no changes to any other part of the programming process or anything else. If I need to change something, then that's my probably my issue, but I don't see anything to change. I'm at a loss as to why the new Flash part doesn't work, but I don't believe that it is due to a flaw in the programming process since I have been rechecking everything with the old Flash part. I've also tried multiple new parts.

Could there be an issue with the DM355 Rev A that's causing the problem? This board uses the old version so we still have to use the legacy ECC layout.

Thanks,
Frank 

Frank,

There is one more thing. Have you checked the internal ECC support in the new NAND? You have to disable the internal ECC while writing and booting. I'm not sure whether internal ECC is enabled by default. 

Another point to note is that ONFI support will not work if internal ECC is enabled. You can check both of these points. 

What I'll suggest is to use the NANDwriter.out CCS tool to flash the binaries. You can get the source code for the same. You can also verify the data by modifying the code to read back and verify the contents. This will give you greater flexibility in debugging.

Renjith,

We finally were able to make sure that internal ECC support was disabled with the external programmer. We're still seeing the same result. The Flash appears to program successfully, but the DM355 still will not boot from it. As far as we can tell, the Flash contents are exactly the same between the new and old Flash parts.

Do you have any other ideas? I'm still worried that this may be a Rev A issue. Could you check on whether something could have been fixed between Rev A and whatever the latest DM355 revision is?

Thanks,
Frank 

I am not sure about the Rev A and newer version difference. It could be possible. 

How did you disable ECC support using external programmer? Is it done by sending SET_FEATURE command? If so, can you check whether this feature is set by default? Then there is a possibility that this is enabled during bootup and which can be cause the failure. Can you try reading back the data of the page-0 and see what are the values in spare area? Can you compare the same with the page-0 of the older NAND?

If you have an oscilloscope or logic analyzer, can you try to see how many pages of data does the BOOT ROM reads? If its reading just one or max 4 pages, we can safely assume that there is some issue with the ECC logic itself.