FreeRTOS+FAT Reliability

Libraries
1

Hi Everyone,

I’m looking for info on the reliability and robustness of FreeRTOS+FAT. How power fail-safe is it? What is the likelihood of a corrupt file system?

Thanks.

1 Like
2

I’m looking for info on the reliability and robustness of FreeRTOS+FAT. How power fail-safe is it? What is the likelihood of a corrupt file system?

FreeRTOS+FAT has been used and tested for more than 10 years. During the last years there were only minor changes, nothing serious. You can see the changes of the last 2 years in the Github repo.

Power fail-safe: when you use it in a normal way, with disk caching in RAM, and use the normal sequence of “create/write/close”, it is not power fail-safe. It doesn’t keep any journals of activities that can help when restoring the integrity.

Backup battery:

I once developed an embedded medical application which had a rechargeable battery, which would keep the CPU, the screen, and the SD-card alive for another 30 minutes. After a power failure, the system would get an interrupt, so that it could flush all writes and leave the memory card in an integer state.

Pre-allocated files:

If there is a risk of unexpected power failures, I would reduce the FAT actions to a minimum. When you write logging or samples, I would write them to a file that already exists and has the full length. So the only actions that FreeRTOS+FAT will do is these:

  • ff_fseek( xFile );
  • ff_fwrite( xFile );
  • FF_FlushCache ( pxSDDisk->pxIOManager );

The FAT and the directories will never need an update.
When using this scheme, when a power failure occurs, there will be at most 1 data sector that is half-written. And yes, in another file I would write some meta information, like which file/sector was about to be written.

With this approach, you are using FAT, the memory card can be shared with other hosts, but in fact you treat it as a raw disk.

The good things about FreeRTOS+FAT:

  • It is written in a very clear style with lots of inline comments.
  • The return codes are all well described and they are easy to trace.
  • It has implemented all stdio-like functions, like ff_fopen(), ff_fwrite(), etc
  • The stdio interface also implements an errno which is stored in Thread Local Storage Pointers
  • The library is well integrated integrated with the FreeRTOS kernel using mutexes to protect the drives against multiple access.
  • It supports multiple drives all mounted to the same root “/”, for instance a pseudo directory “/ram” can point to a FAT16 drive in SDRAM.
1 Like
3

I use FreeRTOS+FAT and have found it to be very solid. However, the design of the FAT file system itself does not allow for fully power fail-safe implementations.

I am intrigued by this: GrumpyOldPizza/RFAT and wonder if some of the ideas from that could be incorporated into +FAT.

Is FAT file system compatibility a requirement? If not, another one to look at would be littlefs-project/littlefs. I work on a project that has 3 SD cards: two internal and one externally accessible. The external one needs to write data that can be easily read on a Windows PC (with no other tools). However, there is no such requirement on the internal cards. I’ve been thinking about changing the internal cards from +FAT to littlefs for robustness.

1 Like
4

Thanks for the replies, most helpful. We will probably continue down the FreeRTOS+FAT path for now although some of the other links provided here do look promising.

5

As mentioned in a previous reply, the FAT itself is not power/crash safe at all. I’ve used FreeRTOS+FAT a lot in a project, for logging real-time data (a few 100 kB/hour) and my conclusion is that it works pretty shaky over time (weeks). In our solution power may be cut at any time and occasionally a SW crash may occur which interrupts FAT access at any time. However, I haven’t seen any problems with the FreeRTOS FAT implementation itself.
From time to time we need to repair/reformat the SD card and sometimes the write accesses tend to get veeery long (like 30s instead of 0.5s).
But I think it’s not only the FAT which is to be blamed, but also the SD card itself is not fully power failure safe and it also needs to consolidate/reorganaze its physical NAND flash blocks from time to time.