NAND ECC Generation for DaVinci Family of Devices

NAND ECC Overview

Data in NAND devices, like other storage media, can suffer errors during reads and writes. Error correction codes allow the errors to be overcome, at the cost of storing some extra data is stored in the NAND device. The External Memory Interface (EMIF) in the supported device list

Devices Supported

The EMIF of the following TI DaVinci devices support ECC at the level specified. Devices that support 4-bit ECC also support 1-bit ECC. However, the ROM boot loaders of these devices (in the case that they support NAND boot) use the highest supported ECC level for boot purposes. The higher order ECC is required for MLC NAND devices, but in all cases the NAND data sheet should be consulted regarding required ECC levels. While the below categorizations seek to provide guidance with regards to a given device's ECC support, the device datasheet and silicon errata should also be consulted for confirmation of specific support.

4-bit Reed Solomon ECC

• DM335/DM355
• DM36x
• OMAP-L1x/C674x

The 4-bit ECC can correct up to four byte errors in a 512-byte read operation. This means that more than four bit errors can be corrected, as long as all of the bit errors are confined to four or fewer distinct bytes.

1-bit Hamming ECC

• DM643x
• DM357
• DM644x
• DM646x

The 1-bit ECC can correct a single bit error and detect up to two errors in a 512-byte read operation.

GenECC Applications

The genECC application is a tool for creating the required ECC data for NAND pages offline on a PC, without having to use the EMIF hardware of the chip. This tool is being distributed for some devices with the Boot and Flash utilities found here. All source is included in these packages for those who wish to examine the algorithms.

The applications are written in C# and compiled with the Microsoft .Net csc.exe compiler. They can be run under Linux using the open source Mono framework. Running the command from the command prompt with no options will generate a help screen.

The command takes as an input a binary file, which it parses into 512 byte chunks for ECC parity generation. The program creates an binary output file containing the data that would be generated and seen in the ECC registers of the device during actual write operations. The program has a verbose option, which can be activated using the "-v" command-line option. This will provide a human readable text output of the ECC register data, in addition to the standard binary file output. The binary output file name will the input file name, without extension, followed by "_eccdata.bin". The "-o" command line option can be used to override the output file name to be whatever you like.

For 1-bit ECC, there is a single register that holds the Hamming parity information. Therefore the output file would contain one 32-bit value for each 512 bytes of input data. For example, a 2Kbyte input file would generate an output file of length 16 bytes, since the 2KByte input file consists of four 512-byte chunks. Note that only 24 bits of that one ECC register actually contains ECC information. How those bits of information should be stored in the spare bytes of the NAND device, such that the ROM boot loader can correctly interpret them during read back at boot time, may be device dependent. Please consult with the device's datasheet and system guides for details.

For 4-bit ECC, there are four registers that hold the Reed Solomon parity information. Therefore the output file would contain four 32-bit values for each 512 bytes of input data. For example, a 2Kbyte input file would generate an output file of length 64 bytes, since the 2KByte input file consists of four 512-byte chunks. Note that in the case of the Reed Solomon ECC, each register actually contains only 20 bits of ECC parity information, for a total of 80 bits. How those bits of information should be stored in the spare bytes of the NAND device, such that the ROM boot loader can correctly interpret them during read back at boot time, may be device dependent. Please consult with the device's datasheet and system guides for details.

If the input file is not an exact multiple of 512 bytes, the program will pad the last chunk with bytes of 0xFF such that its size reaches 512 bytes. If some other padding is required, it must be added to the input file before giving it to the genECC application.

 

Sample Output for 1-bit genecc program for DM644x

$ ./genecc_DM644x.exe -v dummy.bin-----------------------------------------------------   TI EMIF2.x Hamming ECC Parity Generator for DM644x   (C) 2009, Texas Instruments, Inc.   Ver. 1.00-----------------------------------------------------NAND operation #1        NANDFxECC = 0x0A5005AFNAND operation #2        NANDFxECC = 0x0A5B05A4NAND operation #3        NANDFxECC = 0x01760E89NAND operation #4        NANDFxECC = 0x077E077E

Sample Output for 4-bit genecc program for DM35x

$ ./genecc_DM35x.exe -v dummy.bin-----------------------------------------------------   TI EMIF2.5 ECC Parity Generator for DM35x   (C) 2009, Texas Instruments, Inc.   Ver. 1.01-----------------------------------------------------NAND operation #1        NAND4BITECC1 = 022702EC        NAND4BITECC2 = 03DF034E        NAND4BITECC3 = 01F502AD        NAND4BITECC4 = 003601B8NAND operation #2        NAND4BITECC1 = 02BB00FC        NAND4BITECC2 = 006C0194        NAND4BITECC3 = 03B60049        NAND4BITECC4 = 00FD01CENAND operation #3        NAND4BITECC1 = 00380209        NAND4BITECC2 = 01290315        NAND4BITECC3 = 0018016F        NAND4BITECC4 = 03780157NAND operation #4        NAND4BITECC1 = 00FA03EB        NAND4BITECC2 = 0021022A        NAND4BITECC3 = 01C50267        NAND4BITECC4 = 03010397

For technical support please post your questions at http://e2e.ti.com. Please post only comments about the article NAND ECC Generation for DaVinci Family of Devices here.

Retrieved from "http://processors.wiki.ti.com/index.php/NAND_ECC_Generation_for_DaVinci_Family_of_Devices"

Categories: Flash | Boot | EMIF | DM335 | DM355 | DM36x

Leave a Comment

Comments

"The 4-bit ECC can correct up to four byte errors in a 512-byte read operation. This means that more than four bit errors can be corrected, as long as all of the bit errors are confined to four or less distinct bytes."

How can 4 or less bit errors be spread out over _more_ than 4 bytes? Why can't we just say 4 bit errors and leave it at that. If there is a distinction here it is lost on me. -- Bill

• It's up to four BYTE errors - you can have more than 4 bit errors so long as they're contained within max 4 bytes. Jon Povey 02:31, 3 May 2010 (UTC)