CMX Systems
RTOS
TCP/IP
cmxFlash File Systems
  •CMX-FFS
  •CMX-FFS-TINY
  •CMX-FFS-FAT
  •CMX-FFS-SAFE-FAT
  •CMX-FFS-THIN
USB
CANOpen
Compilers
Modeler

 

CMX-FFS

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 and 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

•PowerFail Safe •Royalty Free ‘C’ Source
•UserAccess Control •Fully Integrated with CMX RTOSes and TCP/IP stacks
•Wear leveling •Multiple Volumes
•Directories •Mix of media types
•Re-entrant •NOR Flash Devices (optional)
•DataFlash Devices (optional)
•Porting Guide •NAND Flash Devices (optional)
•Standard API •ECC (optional)
•Bad Block Management •6 months Technical Support and Updates

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

General File System Function
f_getversion Get file system version number
f_init Initialize file system
f_staticwear Execute static wear leveling
 
Drive Functions
fs_mountdrive Mount a drive
f_format Format a drive
f_getfreespace Get usage information from a drive
f_getdrive Get current drive number
f_chdrive Change current drive
 
Directory Functions
f_getcwd Get current working directory
f_getdcwd Get a drive’s current working directory
f_mkdir Make a directory
f_chdir Change directory
f_rmdir Remove a directory
 
File Access Functions
f_open Open a file
f_close Close a file
f_flush Flush a file to flash
f_write Write to a file
f_read Read from a file
f_seek Set position in a file
f_tell Get current file position
f_eof Check if at end of file
f_rewind Move to start of file
f_putc Put a character to a file
f_getc Get a character from a file
f_truncate Truncates a File
 
File Control Functions
f_rename Rename a file of directory
f_move Moves a file of directory
f_delete Delete a file or directory
f_filelength Get the current length of a file
f_findfirst Find a file or directory in the specified path
f_findnext Find next file or directory in the specified path
f_settimedate Set the time and date on a file or directory
f_gettimedate Get the time and date from a file or directory
f_setpermission Set the permissions on a file or directory
f_getpermission Get the permissions from a file or directory

A full Unicode API is included.

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.

NAND Flash Driver functions NOR Flash Driver functions
 
NReadFlash() ReadFlash()
NEraseFlash() EraseFlash()
NWriteFlash() WriteFlash()
NVerifyFlash() VerifyFlash()
NgetFlashID() GetFlashID()
NGetInitialBadBlocks()  

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.

All content is subject to change without notice
Copyright material 2014© All Rights Reserved. Site and all contents are the sole property of CMX Systems, Inc.
No part of this site may be copied or used without the express written permission of the owner.
Web Services by Unicorn Web Development, Inc.