NAND Flash support with larger page size and more addressing cycles

[cn2]

Posted on October 08, 2015 at 11:02

I've a new project were I need to use NAND flash connected to STM32F2 or STM32F4. I need to support NAND Flash chips with 8, 16, 32 or 64 Gbits. These chips have page size of 4096 or 8192 bytes, and the required number of Addressing Cycle is usually 5.

The current NAND Flash driver of STM32Cube's FW is only supporting 512 and 2048 bytes for the page size, and the maximum number of Addressing Cycle is 4. When looking at STM32's reference manual: - there is no limitation on the FMSC about the number of Addressing Cycles -> OK - the ECC calculation can be done on 4096 or 8192 bytes -> OK So my first questions are about the S/W support for this chips: - Is it possible to adapt the NAND Flash driver for support of larger NAND Flashes? - Is this code available from ST? When the driver will be working, I would like to use FATFS with FAT32 mode. It seems that FatFs support only block size (at FAT level) of maximum 4K. Does it mean that block size of 8K at NAND level won't be supported? And the last question: on STEVAL-CCM07 board, ST was providing a complete firmware for NAND Flash management, wear leveling, ... Is this code available in Cube ? I can see FatFs, NAND Driver, but not the glue between them ! #nand-flash-driver-fat

[Tesla DeLorean]

Posted on October 09, 2015 at 00:57

I would think the erase block size is what's going to kill you with FAT32. Yes you can make the sectors bigger, and the clusters too, but it's still ill suited to a straight NAND implementation.

When implementing a NAND driver for a file system that would prefer 512 sectors, one of the things that you're going to have to manage is the deblocking, and how, and when, you write and erase stuff. It'll be a lot easier with an SD/MMC, or eMMC, type arrangement where the ugly stuff gets managed by the memory device, rather that you having to commit a lot of RAM you don't have, to a rather complicated management task that also includes bad block reassignment and wear-leveling.