File System
The
SmartMesh network stack
includes a file system that allows your application to persist its data in internal flash. The exposed API allows your application to create, delete, read and write files. Functions in the API also allow your application to obtain information about the file system's content and free space. The file system is flat, i.e. there are no directories. The application shares the file system with theSmartMesh network stack
which uses it to store persistent settings and temporary files created during an Over-The-Air-Programming (OTAP) operation.Features
The built-in file system incorporates the following features:
- Wear-Leveling: flash sectors needed for internal storage are chosen uniformly to increase longevity of the embedded flash.
- Fault-Tolerance: support for shadowed files guarantees that each individual write operation either completes, or does not occur at all, even in the face of power loss.
Note:
The
SmartMesh library
's file system offers your application a "user-friendly" abstraction for accessing the underlying flash memory. Your data is organized into files, which have names, and which you can hence look for. Similarly, shadowed files (see below) give you the peace of mind that your data will not be corrupt, even if your device loses power during a write operation.
Unlike the traditional file systems on a PC, the embedded flash file system has the following important properties:
- Erasing and writing to flash costs a lot of energy
- Erasing and writing to flash takes a lot of time
- The underlying flash memory can only be written a (large but) finite amount of times
- Compared to your PC's hard-drive, the amount of space in the
SmartMesh library
's file system is small
SmartMesh library
's file system.- Regularly storing data samples or packet contents into the file system
- Using the available space in the file system as extended RAM that is updated often
- Storing persistent configuration
- Storing calibration information
- Storing failure logs
File Naming
The file system is flat and does not support directories. For that reason, each file needs to have a unique name, with a maximum of 12 characters. All file names must start with an single digit numeric identifier. Identifiers 0 and 1 are reserved for use by the stack, and the application should only access/create files starting with number 2. While non-printing characters are allowed after the starting character, we suggest using printable ASCII characters if filenames are to be human readable.
Examples:
File Name | Description |
---|---|
1mote.cfg | Valid. 1 indicates that the file belongs to the SmartMesh network stack . |
2app.log | Valid. 2 indicates that the file belongs to your application. |
foo.bar | Invalid. Does not follow the naming convention. |
File Types
An application that creates files has an option to specify whether the files should be shadowed or raw, depending on the requirements and access patterns.
Shadowed Files
A write to a shadowed file is fault-tolerant. If an error occurs during the write operation, or power is lost, the file will remain in the unchanged state - as it was prior to the faulted write operation. To support such behavior, the file system creates a copy of each modified sector (a shadow) on every write. The old sector becomes unused only after the write completes successfully. While this operation provides a very convenient abstraction, the energy cost associated with each write may be significant. In the worst case, the underlying operation requires rewrite and/or erase of multiple sectors.
Raw Files
Compared with shadowed files, raw files are not fault-tolerant. If a write fails or power is lost, the file may contain partial or otherwise corrupt data. The file system translates each write API call into a direct flash write. While the performance and energy cost of writes to raw file is smaller, the application must observe the following restrictions:
- Each word (4 bytes) in the file may be written at most once
- A write offset must be on a word (4 bytes) boundary
Raw files may be a good match for use cases such as logging of infrequent events, where data is only appended and never modified.
Temporary Files
Files marked as temporary will be automatically deleted from the file system upon mote start-up, and at the beginning of Over-The-Air-Programming (OTAP) session.
If an OTAP transfer starts while a temporary file is in use, the application may get an access error as the file will be deleted. If this is a valid use case, your application should either be prepared to process such errors, or you should implement a command to suspend file system activity for the duration of OTAP operation.
Space Usage
File size | File type | Number of sectors |
---|---|---|
<=2028 | shadowed | 1 |
>2028 | shadowed | 1+ceiling(file size/2044) |
any | raw | 1+ceiling(file size/2044) |
Other notable limitations of the file system are:
- Maximum number of files that can be stored in the file system is 32
- Maximum file length supported is 261632 bytes
- The file system requires 2 unused sectors for its operation
In general, your application should reserve 8 files and at least 10KB for use by the
SmartMesh network stack
network stack. The rest can be used by your application and OTAP files.
The Over-The-Air-Programming (OTAP) procedure uses the file system to store the new binary image as it is being received.
If you plan on using OTAP, you need to make sure that there is enough free space in the file system to hold a full binary image.
We therefore recommend to:
- keep the size of the full binary image below 200kB
- keep 160kB of free space in the filesystem
- declare non-critical files to be temporary when possible, these files will be deleted when OTAP starts to make more space
This is especially important when you are planning to reduce the size of the file system partition and/or creating files in the file system.
Refer to the
SmartMesh On-Chip API html documentation
in the /doc
directory of the for documentation about this feature.