Electronic – Best practice for implementing bare metal or lightweight OS flash file system

flashstm32

I am looking at flash devices that are available for rewriteable data storage, and it's clear that they need either some sort of translation layer for an overlying file system (such as FAT) or a specific type of filesystem designed for them (such as JFFS2).

Examples:

This seems like such a common thing, but I'm not seeing a lot of resources (specifically on the stm32 platform) for dealing with the flash issues of write-only by page, wear leveling, and bad block monitoring.

It seems like a system like JFFS2 would take care of a lot of that, but it doesn't really seem to be used much outside the Linux ecosystem. What are some of the more common ways to deal with this in a leaner OS environment?

One highly-desirable feature is fault tolerance. For example, if the power is removed during certain operations, FAT can be corrupted. A good solution should be journaled or something similar.

(Note: "Write your own" is a highly obvious and undesirable answer)

Best Answer

Although you reference a 1 MB SPI Serial Flash chip, I think it is much more common to see file systems implemented on removable SD cards. That has two advantages: much larger storage (GB instead of MB), and you can remove the SD cards and read/write them on a PC.

An additional advantage is that the name-brand SD card makers like Kingston and SanDisk provide wear-leveling as part of the SD card architecture (but don't count on that from less expensive SD card makers).

Microchip (and I am sure other vendors) has a library you can use to implement either a FAT16 or FAT32 filesystem on an SD card. It is described in this application note AN1045, "Implementing File I/O Functions Using Microchip’s Memory Disk Drive File System Library". Obviously this will be targetd for PIC microcontrollers.

The low-level read/write SD card sector routines in this library could probably be modified to work with a SPI serial flash, but you would need to do your own wear-leveling and bad sector marking which would add a lot of complexity.