# Best practice for implemeting bare metal or lightweight OS flash file system?

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.

• Some brands have a mild set of examples or even some canonical routines. Most don't. Other than that, you just told me to not give the answer that's invariably the answer, so I won't. – Asmyldof Apr 12 '16 at 8:16
• Windows CE uses the FAT filesystem for embedded Flash - with its own Flash abstraction layer. I'm surprised that there isn't a standard codebase for doing this. Maybe the key algorithms are patented? – pjc50 Apr 12 '16 at 8:35
• make sure the hardware is not already doing wear leveling for you, might make it worse if you are trying to wear level something that is already wear leveling. – old_timer Apr 12 '16 at 13:14
• linux things are generally open source, you can "simply" port it to bare metal and not have to completely write your own. – old_timer Apr 12 '16 at 13:14
• if there are truly no open source solutions, there may be a reason...maybe it just isnt required... – old_timer Apr 12 '16 at 13:15

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.

• This is a route I have taken in the past. Unfortunately I also have had the SD card compatibility nightmare. Truthfully what I am doing needs an extra few hundred KiB, not GB, and has the space for an SO-8, but not really for a card slot. Thanks for your answer! For some people this is certainly the right one. – Daniel Apr 12 '16 at 13:37

You can use RL-FlashFS ,but as you know this is not a free option and have you to using MDK-KEIL as your IDE,maybe this is possible with FAT-FStoo.

Here is one option I found during the search: a lightweight filesystem for SPI flash storage: SPIFFS

It doesn't have bad block management support, but it seems pretty complete otherwise as far as a really simple way to read and write files!

• SPIFFS seems to be a good (if not the only) solution suitable for an embedded target. I couldn't find any other openly licenced library that does not use a lot of resources – sensslen Aug 11 '16 at 14:51
• @Daniel Were you able to get SPIFFS work with S25FL0? I have it working for AT45DB but its a $2 flash and S25FL0 is <$1. – clmno Jan 10 '18 at 11:11

I never used it in my projects, but please have a look at fat FS lib.

• I have-- it would require a flash translation layer (ftl) to work correctly – Daniel Apr 12 '16 at 18:21