The CMX-FFS Failsafe file system is designed for NOR and NAND flash applications which require the degree of reliability needed to survive power failures, resets and other conditions which typically cause file system corruption.

File API

The file API is a standard interface. All the interface routines are fully re-entrant. There is an optional “secure” file API which enforces user access to the file system.

The API provides all standard features for file manipulation such as fopen, fwrite etc. As well as routines for directory manipulation such as mkdir, chdir.

Intermediate File System

This is the control room of the file system. Although the source code is supplied, its detailed operation is not normally the concern of developers using the system. This section does all types of maintenance such as FATs, CRC’s, Bad blocks etc.

Driver Layer

Specific drivers control access between the Intermediate File System and the Physical media. These are kept as simple as possible and generally only need to have minor modifications made to constants to reflect particular flash array configurations and flash chip types.

Key Features

CMX-FFS FailSafe

The CMX Flash File System is completely protected against unexpected reset (power failure) and also has several other features to ensure the integrity of your data.

In its primary mode of operation the system maintains two FATs (File Allocation Tables). The diagram shows the principle by which the system is updated without any risk of data loss. A new file has to be completely accepted in the new FAT before the old FAT and file will be destroyed .In the event of an unexpected reset, the system is able to recover the last completely stored file, possibly the old version if storage of the new file was not complete.

Wear-leveling

Wear-leveling is a very important feature in many flash systems (NAND and NOR) and is necessary to ensure the greatest possible life expectancy for the flash chips. The system provides block management algorithms which ensure that the least used blocks are always used.

Bad Block Management

Bad block management is an essential feature of Flash arrays (particularly NAND flash). On initialization, the software automatically checks for bad blocks and pages them out of the system. Subsequently any additional bad blocks detected (NOR or NAND) are automatically paged out. In this situation data may be lost. NOTE: Developers should carefully check their storage requirements against the type of flash they are planning to use.

CRC32

All files and also the FATs are protected by a CRC32. Corrupted files will be detected upon opening and the error will be signaled to the user and any bad blocks will be marked as such.

ECC

Optional support is provided for ECC in NAND flash chips where the necessary hardware support is available. The ECC implementation ensures that single damaged bits in bad blocks are automatically corrected. A fast algorithm has been implemented for the fastest possible calculation.

CMX-FFS User API

The system provides two file APIs for the developer to choose from. The standard API provides the functions listed and the access routines are exactly the same as in a standard file API (fs_read() is equivalent to fread()). Both the Standard API and the Secure API are fully documented in the User’s Implementation Guide.

CMX-FFS Driver Layer

NAND and NOR Driver Layer

Because Flash types vary and their hardware configurations also vary, it is not practical to pre-code all possibilities. Thus, for any particular system a minimal amount of porting work must be done.

The first definition that must be set is the MAX_VOLUMES which must be set to the maximum number of volumes in the system. Typically for a system with some NOR flash for code and configuration storage and NAND Flash for data storage this would be set to 2.

The next step in porting is then to specify the variables in each volume based on its physical capacity. There are nine of these variables for each volume whose values may be derived directly from the Flash chip specification and the hardware configuration.

The last step is to check the routines listed below so that the control codes used for accessing the particular device are correct. These routines are short and simple.

The details of what needs modifying are contained in the porting section of the User’s Implementation Guide. The process of modifying the device driver should take only a few hours- most of which will be for the developer to familiarize themselves with the Flash array specification and match it to the driver.

Boot Sector

If a boot sector is required in a NOR flash or some blocks need to be reserved for some purpose outside of the FSS this is easily done by setting the BlockStart variable in the appropriate Volume descriptor structure to point to beyond the reserved area.

CMX-FSS Development System

Source Code

The source code is independent of any particular operating system, though the integration for use with CMX RTOSes and TCP/IP Stacks is provided. Integration is simple for all systems we know of. The system must provide a semaphore mechanism if reentrancy is required otherwise this can be left as a NULL function.

The ‘C’ source code has been cleanly compiled on many compilers, is ANSI C compliant and is also syntax checked to the highest level possible. The system has been verified on several types of NOR and NAND flash in a variety of hardware configurations.

Demonstration/System Test Program

The development system comes with a test program which simulates most system functions on a PC. The program simulates in PC RAM and Hard disk NAND, NOR and RAM drives enabling the user to check and verify the system. The user can use this for a tool to check wear-leveling performance, ECC functionality, corrupt files, bad blocks etc.

There is a complete graphical representation of the current FAT, showing block usage (deleted, unused, used etc.) Both a physical and logical display is provided.