We’ve been using FreeRTOS+FAT fairly successfully for a while, but I’ve just added some new features to our system and during testing we have been getting assert fails in FreeRTOS+FAT.
Simplified description of our system:
We are using a Microchip SAMV71 processor with 384kB of RAM, and we have implemented FreeRTOS+FAT on a connected 8GByte SD card with 16kByte of buffer space.
Our current code is based on code downloaded from the FreeRTOS+FAT github: commit bbf2c67, 19-May-21.
The current test setup I’m running has 3 relevant threads:
Two “command handler” threads that read from different command files. Command files are small text files (a few kBytes); each thread reads a command from a file with open/seek/read/close.
The commands generate events which are queued and recorded in the system log by the logging thread. Each event is written with the system log file with open/seek/write/close. The system log file is several MBytes.
So to summarise, there are 3 threads accessing the file system. 2 threads read only, and only one thread writes, all accessing different files.
In my current test I’m running the system more heavily loaded that it would be in nominal operations, and reading about 20 commands per second in total. The commands are test commands and don’t do much apart from generating events for the system log.
When I leave the system running it is OK for a while but sooner or later always fails at one of the configASSERTs in FreeRTOS+FAT:
Most frequently the configASSERT in FF_UnlockFAT (ff_locking.c, line 297) fails, during ff_fopen, ff_fseek or ff_fclose calls.
Less frequently the configASSERT in FF_Assert_Lock (ff_locking.c, line 247) fails, during ff_fseek calls.
As far as I am aware we are using FreeRTOS+FAT in a nominal mode of operation, just loading it rather more than we have in the past. Although we’ve been using FreeRTOS+FAT with reasonable success for a while, other parts of our system access the file system in similar ways and I’m now concerned that we may have just got lucky in avoiding these asserts in the past. I’d be grateful for any tips on resolving/avoiding these sort of issues. In particular, is this sort of issue likely to be affected by the size of buffer we have allocated? (the 16kByte figure we used was a bit arbitrary, as I don’t know how it’s used by the library).