Application File System

Example Path: examples/EFFS/Std/ApplicationFileSystem

Overview

These examples cover storing and serving application files on a single EFFS-STD file system – the module's on-chip flash file system, as opposed to EFFS-FAT (a FAT32 file system for removable SD/MMC cards).

The primary audience is NetBurner platforms that have no system file system – the ColdFire (MOD5441X, NANO54415, SB800EX) and SAME70 (MODM7AE70, SBE70LC) modules. On these platforms the application creates and mounts its own EFFS-STD file system: it reserves a flash region (via COMPCODEFLAGS or a fixed-address reserve), describes the flash geometry, supplies the physical flash driver, and formats the file system on first boot.

The same example also builds for the i.MX RT modules (SOMRT1061, MODRT1171), which do have a system file system. There, the application does not create a file system – it simply stores and serves its files on the existing system file system (drive 0) at the root directory, alongside the device's /sys area. (Formatting is disabled on the RT modules, because that file system also holds the application image.) All system files live under /sys/files/, so application files at the root never collide with them.

Note

If you are on an RT module and want a separate, formattable partition for your files instead of sharing the system file system, see EFFS-STD HTTP MultiPartition (System File System + App Partition).

How the Application Creates the File System (ColdFire / SAME70)

On a platform without a system file system, two build settings give the application a file system to use. Both are already set per platform in the example makefile – this is simply what they do:

• Link the EFFS-STD library. libStdFFile.a provides the fs_* API used to open, read, write, and manage files.
• Reserve flash for the file system so the application image and the file system do not overlap:
  • ColdFire (MOD5441X, NANO54415, SB800EX): a COMPCODEFLAGS range caps the application region, leaving the top of flash for the file system.
  • SAME70 (MODM7AE70, SBE70LC): -cflag C:3 ("locate application at fixed address") disables the background flash-erase that would otherwise reclaim the file-system sectors.

At run time the application calls fs_main() (which calls EffsStart()) to format the reserved region on first boot and mount it. The example's ReadMe lists the suggested file-system size for each platform and where to change it.

Note

None of the above applies to the RT modules. Their EFFS-STD file system is part of the platform and is mounted before UserMain() runs, so there is no library to link, no flash to reserve, and no fs_main() call – the example makefile already excludes the RT modules from these settings.

Examples

EFFS-STD HTTP (Application File System)

HttpAFS** demonstrates a complete file-storage application built on a single EFFS-STD file system:

• A serial menu for read/write tests, a directory listing, space usage, and – where allowed – formatting the file system.
• An HTTP server that serves files from the file system and lets you upload your own index.html to override the page compiled into the firmware, so a web page can be updated without rebuilding the application.
• An FTP server for uploading, downloading, and managing files with a client such as FileZilla.
• NTP time synchronization so file timestamps are correct.

It builds for every supported platform: the ColdFire/SAME70 modules (where it creates its own file system) and the RT modules (where it uses the system file system at its root). It is the recommended starting point for storing and serving files on any NetBurner module.

Related

• Standard File System (EFFS-STD) – the top-level EFFS-STD overview and a guide to choosing an example.
• System File System (RT Platforms) – examples specific to the RT modules' system file system, including how to inspect it and how to add a separate, formattable partition (SOMRT1061).