On a NOR flash, especially one that also contains my boot code and application, I usually avoid the overhead of a formal file system. Instead, I save each “interesting” object starting at the border of the erase block and start with a header structure that, with minimal content, has the size of the object and the checksum. Adding a name or resource identifier to the header is a natural extension.
The bootloader searches for a valid application by checking the checksum before using the block. Similarly, other resources may be validated before use.
It also simplifies the use of the firmware update utility to verify an object before erasing and program it in FLASH.
A pool of small resources can be best handled by wrapping it in a flashing container. If the runtime resources support it, I will be tempted to use ZIP to transfer files, wrapping the ZIP archive image in the size and checksum header and keeping it at the border of the erase block. If you cannot afford the decompression time, you can still use ZIP with uncompressed files or use a simpler format like tar.
Naturally, the situation is very different for a NAND flash. There I highly recommend choosing a created (commercial or open) file system designed for NAND flash quirks.
RBerteig
source share