Hello All.
We're looking into beginning development on an ARM7 based platform, and we are thinking about using an attached SD-card for storing environmental log data.
I've noted that "All files opened for writing must be closed before the memory card is removed from the socket. Otherwise, a FAT file system might be corrupted." as per the instructions on Keil's website, but my question is:
If a system has not closed files it is writing to on the SD-card using a FAT file system, and a power loss occurs, will/can the file system also be corrupted in such a case? I'm assuming yes?
any thoughts on this? is it a bad idea in general to use a FAT file system in a system that very well could expect power loss at any time?
Thank you.
Problems with FAT can be reduced by precreating fixed-sized files, and write changes in sequence to two different files.
Not requiring any any changes to the FAT chains, greatly improve their reliability. And using own FS code, you can make sure that there is no need to update the meta information, i.e. leaving the update time information unchanged.
The above makes the FAT file system look like a container for a "raw" file system, while still making a PC able to read out the file data.
Obivously, a power loss during writes may still create havoc inside the SD controller depending on what actions it performs for the wear leveling actions. Especially since the FAT file system have one sector size while the raw flash memory may have a completely different subdivision into eraseable sectors and a raw flash write may destroy the flash sector affecting the contents multiple file system sectors or the mapping between raw sectors and addressable regions.
Unfortunately, it also makes that file system container almost as unusable for the casual PC user as just forgetting about FAT and just using it as a raw device would have.
I.e. you can't store even a simple text file, must less a GIF image or other data file format, in that file-system-in-a-FAT-file thing without needing a special application that can parse the internal file system and find it. A FAT file system isn't much use if all it ever shows you is a single file, as large as the entire medium, but you've got no idea what's actually supposed to be in there without running the dedicated "decode this" interface program.
You misunderstood me. I never talked about hiding any file system within a single file in the FAT file system.
I talked about storing raw binary data (for example measurements) within a preallocated FAT file of fixed size, to make sure that there are no FAT chains that may break in case of a power loss.
Most image formats don't care if the file in the file system is much larger than the actual image data.
But quite a lot of embedded equipment don't need to store images but need instead to store captured measurements. And in many situations it's ok to have binary files on the memory card that requires a special PC program to extract the data. The PC sees files in a FAT file system, so you don't need to worry about any drivers to extract your "measurements1.dat". And if a power loss results in "measurements1.dat" being broken, you can normally save the day by instead retrieving the "measurements2.dat" file instead.
If you did not have a FAT file system, then your PC would think the memory card was broken or unformatted if you put it in the PC. That is way worse than finding one or more files of fixed size and having a Windows program process the memory card contents into other formats.