SD Card file system coherency issues

[thomastaranowski]

I have an issue with some netburners where the FAT 16 filesystem on the SD card on my MOD5282 becomes corrupted. The problem is that I don't know of a way to check that the file system is valid before trying to read a file, which sometimes causes the software to hang.

I thought of using chkdsk, but the implementation doesn't seem to be there. Does anyone know if there's a straightforward way to include this, or another method of checking the correctness of the file system at startup?

Thanks

[Ridgeglider]

Tom: I have not run into these kind of issues for a while, so I am a bit rusty. Many (but not all) SD cards seems to come preformated as FAT16.

I use the utilities in the file:
C:\nburn\examples\EFFS\EFFS-FTPFileSystemUtils.h Although #defines in the file indicate EFFS support for FAT12, FAT16, and FAT32, the EFFS-ProgrammersGuide says (section 6.1, pg 18) that all examples in the manual are based on FAT32.


When I began using EFFS long filenames, I began having lost files that I eventualled tracked to the format failing. I also found that if I had written files in 8.3 mode to a card, then changed my app to long filename support, then wrote files with long names, then things would fail. Finally, it seems that I also learned there were limits to the number of files in a single directory under FAT16. I don't remebder the number, but I think it may have been as low as 256 files?? The upshot is that I use long file names. I am very careful to format the cards to FAT32 before use. I do this on a PC. Since doing this, I have experienced no more file system lost-file type trouble. After some bad experience I am pretty careful to keep FAT16 off the system, although I do this manually: it is not supported in the code.

I notice EFFS includes the fs_format and f_format calls, and that the aforementioned FileSystemUtils.cpp simplifies their use with a function called FormatExtFlash() which defaults to FAT32. Its return value indicates whether the format was successful, although I suspect it is less thorough than chkdsk. EFFS also has a CheckBadBlock() function. The DisplayEffsSpaceStats() also shows the bad space. Perhaps your code could format a card w/FAT32, check for bad blocks, if OK write a file indicating the type of format? This file would signify that the card is FAT32 and OK to continue. Just an idea, although not chkdsk. Sorry!

[Ridgeglider]

Tom: I posted this message few minurtes ago and it didn't seem to show up... At the risk of having it appear 2X, here it is again. I have not run into these kind of issues for a while, so I am a bit rusty. Many (but not all) SD cards seems to come preformated as FAT16.

I use the utilities in the file:
C:\nburn\examples\EFFS\EFFS-FTPFileSystemUtils.h Although #defines in the file indicate EFFS support for FAT12, FAT16, and FAT32, the EFFS-ProgrammersGuide says (section 6.1, pg 18) that all examples in the manual are based on FAT32.


When I began using EFFS long filenames, I began having lost files that I eventualled tracked to the format failing. I also found that if I had written files in 8.3 mode to a card, then changed my app to long filename support, then wrote files with long names, then things would fail. Finally, it seems that I also learned there were limits to the number of files in a single directory under FAT16. I don't remebder the number, but I think it may have been as low as 256 files?? The upshot is that I use long file names. I am very careful to format the cards to FAT32 before use. I do this on a PC. Since doing this, I have experienced no more file system lost-file type trouble. After some bad experience I am pretty careful to keep FAT16 off the system, although I do this manually: it is not supported in the code.

I notice EFFS includes the fs_format and f_format calls, and that the aforementioned FileSystemUtils.cpp simplifies their use with a function called FormatExtFlash() which defaults to FAT32. Its return value indicates whether the format was successful, although I suspect it is less thorough than chkdsk. EFFS also has a CheckBadBlock() function. The DisplayEffsSpaceStats() also shows the bad space. Perhaps your code could format a card w/FAT32, check for bad blocks, if OK write a file indicating the type of format? This file would signify that the card is FAT32 and OK to continue. Just an idea, although not chkdsk. Sorry!

[lgitlitz]

There should be a new beta release out in a few days that corrects a few issues with long file names being used with the FTP server. The main ftpd.cpp source file required increased buffers to be compliant with the 256 char file name limit. There have also been changes to the example ftp_f.cpp code that make the file system ftp more robust and efficient. The Compact flash driver had an issue with reading or writing past 8GB which has also been corrected. Cards up to 128GB can now be used, this is a size limitation of the CF specification.

For testing drives you can use the f_checkdisk function. This is in the EFFS documentation:
...\nburn\docs\EFFSfat_331.pdf
The header can be found here:
...\nburn\include\effs_fat\chkdsk.h

The newer builds of the NNDK also allow for dynamically enabling CRC checking during SD Card transfers. The variable that controls this is MMC_CRC_Enable. This variable is declared as an extern in mmc_mcf.h. By default it is disabled and set to 0. To enable CRC then just set this variable to 1 before mounting the card. There is at least a 20% decrease in transfer speed when CRC is enabled which is why it is disabled by default.

-Larry

[rnixon]

Why use FAT16 instead of FAT32?