Use of ECC in NAND memories for STM32F429

[David Garcia]

Hello,

I am trying to use the ECC computation block for a NAND memory in STM32F429. The page size of my memory is 2048 bytes + 64 spare bytes.

The ST32F429 Reference Manual says "The ECC algorithm implemented in the FMC can perform 1-bit error correction and 2-bit error detection per 256, 512, 1 024, 2 048, 4 096 or 8 192 byte read or written from/to the NAND Flash memory". But I have some questions about this:

• The register FMC_ECCR2/3 has 32 bits. Are only 32 bits required for a 2048 byte page? Or is it necessary to calculate the ECC in parts?
• How can I correct an error bit?
• Is there an example of using ECC in NAND memories with page sizes greater than 512 bytes using HAL? And without using HAL?

I'm pretty lost on this topic and I don't know where I can look.

Best regards

[Tesla DeLorean]

In the past ST has had NAND libraries, you'd need to speak to your local sales rep or FAE.

As​ I recall this was designed for older NAND devices that couldn't auto generate syndrome bytes, in either case you'd push your data through the interface and then push the ECC syndrome bytes. NAND devices aren't byte addressable, the memory interface is like a FIFO.

Most people are using eMMC devices today due to the common footprint and longer term availability.​

[David Garcia]

Thanks for the reply.

But, the 32-bit syndrome generated is enough to detect 2 errors on a 2048-byte page?

[Tesla DeLorean]

That's not how this works. The ECC syndrome data is significantly larger, in the order of 64-bytes or more, depending on the device, SLC/MLC, etc.

The data is also interleaved into rows, and something equivalent to a CRC (or fire-code) is run across the rows.

The data is feed into the unit a word or byte at a time as it traverses the FMC, as I recall, and it accumulates the syndrome data across all the data as you push it across the interface, once the whole sector has been sent you switch into another mode and push the 64-bytes, or whatever, of data that ECC unit generates.

On the read back, similarly the data is pulled from the interface, and then you pull the computed/xor'd syndrome bytes via the peripheral, and determine where they fail, upon failure you run your STM32 side SW to determine the number and location of the errors, and then fix the RAM copy of the data you just pulled.

Newer NAND devices (thinking 2008) had more complicated and longer ECC polynomials to address the failure modes of the devices, and these could auto-compute the syndrome bytes as you wrote the data portion of the sector, and write them automatically into the extension area at the end. This would save you from doing a SW computation on the host, or programming the method/polynomials into the HW ECC generator/checker.

I'm pretty sure the "correction" phase always has to be coded in software as the HW unit doesn't have that level of complexity, and can't random access the memory buffer you copied the data into.