FAT File System fails to write without error

Running FreeRTOS+FAT on SiLabs Giant Gecko. Prototype application code working, but we are in a bugfix/enhancement phase. So Our code includes a system logging process which basically writes a CSV file for debug. On my device, this has suddenly stopped working. However, it fails without returning an error.

I’ve stepped through the code watching:
it opens the file (creating it), writes the entry to the file, and closes the file.
But when I check the file system the file was not even created.
This may be an old issue. We are currently using V10.0.0 as far as I can determine.

I managed a workaround (deleted and rebuilt the entire filesystem), but would welcome any information about this or similar problems in the FAT library. And yes, part of the reason for posting this is my task to investigate upgrading FreeRTOS+FAT.

Thanks.
Ed

Can you do a cache flush and check if the issue goes away.

Really the only supported way to flush the cache is to close the file.

I haven’t run across a problem like that in years of using FreeRTOS+FAT. You could take a look at the SD card on a desktop with something like “chkdsk” or “fsck” to see if the file system metadata is corrupted. FAT itself is inherently vulnerable to metadata corruption in the event of sudden interruption such as power loss or removal of the card from the socket. In practice, what I usually see in cases where a file has been opened and written to but not closed is a zero-length file.

In one of my projects I get a warning interrupt about 500 ms before power goes down. It has three SD cards and I’m still working on making sure I can get all files closed and cards unmounted in that time.

1 Like

In the end, I had to erase the file system and recreate it.

One interesting observation was a directory that had three “.” subdirectories. The directory size was printed as an int (%ld format) and it showed as -1.
Seems to me the FAT library should be able to detect an error like that.

I may have to add some checks of my own.
Ed

Thank you for sharing your solution!

1 Like