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.

Using OMAP L138 EMIF 4-bit ECC.

I am using a Micron NAND flash device MT29F8G08ABABA which requires 4-bit ECC.

I am running VxWorks 6.8 on this device and the NAND flash device will be sitting on CS4 on the EMIF bus. To interact with this device I will be using DataLight's NAND flash drivers that will need some tweaking to both support this device and to support the OMAP L138. For the most part integration has gone well except when it comes to the 4-bit ECC portion.

The DataLight drivers look like they store the spare data (along with some tag data) at the *END* of every page. The problem that I see is this.

The 4-bit ECC instructions in the OMAP L138 technical reference document details 4-bit ECC on a read as follows

Set 4BITECC_START in NANDFCR to 1.

Read 512 bytes from NAND Flash.

Clear 4BITECC_START by reading any NAND Flash 4-bit ECC register (NAND4BITECC;4:1])

Read parity value stored in NAND flash .

Write parity data into NAND4BITECCLOAD.

..... etc..

The problem is that since the parity data is stored at the end of every page (not at the end of every 512 byte segment), I won't be able to write anything to the NAND4BITECCLOAD register until at the very end of the page read.

My question is this. Is it possible to simply set 4BITECC_START, read 512 bytes out of NAND, read and store off into a local buffer (e.g recentEcc) the 10 bytes of parity data stored in NAND4BITECC and continue reading the rest of my 4096byte page.

After I am completely done with the read i will then be able to read 80 more bytes of data from the spare region which will contain the parity data that was stored during a write.

After I have done this could I then write the recently computed ECC (stored in recentECC earlier in the read operation) into the NAND4BITECC[4:1] registers and then write the parity values read from the spare area of NAND into the NAND4BITECCLOAD register and proceed with calculating the syndrome, reading my error count, error address offset and my error value and then correcting corrupted data in my page buffer?

In summary:

Does the EMIF peripheral also calculate the 4-bit ECC parity values upon a read?

If so can I store off that parity data while I read my entire page out and then use that parity data in combination with the parity data found in the spare region to perform syndrome and error correction operations AFTER the read is done and finished with?

Thanks

-Jason Ling

  • Jason Ling said:

    My question is this. Is it possible to simply set 4BITECC_START, read 512 bytes out of NAND, read and store off into a local buffer (e.g recentEcc) the 10 bytes of parity data stored in NAND4BITECC and continue reading the rest of my 4096byte page.

    After I am completely done with the read i will then be able to read 80 more bytes of data from the spare region which will contain the parity data that was stored during a write.

    Yes, this is possible. And in fact the best way to use spare area for ECC and bad block markers alone.

    Jason Ling said:

    After I have done this could I then write the recently computed ECC (stored in recentECC earlier in the read operation) into the NAND4BITECC[4:1] registers and then write the parity values read from the spare area of NAND into the NAND4BITECCLOAD register and proceed with calculating the syndrome, reading my error count, error address offset and my error value and then correcting corrupted data in my page buffer?

    I'm not really sure about this. But I think it should be possible, otherwise there is no use of having NAND4BITECC registers Read/Write. 

    If this doesn't work, you've to implement a software routine to compare and correction of data using the ECC bytes.

  • Hi Jason,

    Yes, the EMIF can calculate 4-bit ECC parity values upon a read.

    Do you want to compare the ECC parity of first 518 bytes read with the stored parity of a page of data? The syndrome will most probably show a non-zero value (indicating an error) as these are for different data sizes. Unless, you plan to also store parity for the first 518 bytes written at the end of the page during writes and this is what you are reading back. But in this case, you will only be able to correct the first 518 bytes of data read.

    Regards,

    Sunil Kamath