PicForum

hoosier_timmer wrote:
We have a USB application with a PIC18F47J53 micro and the code is based on the USB Mass Storage - Internal Device application. We use Excel and some custom visual basic to write a configuration file to the micro. This file contains a time update for the RTCC and some configuration values. The Excel VBA first erases the TXT file on the micro then writes a new file. We had some customers that would erase the TXT file or format the internal drive so some code was added to check several of the file & internal drive memory locations. If these memory locations didn't match or were zeroed, the micro would restore the TXT file back to factory defaults. Up until now everything has worked fine.
Last week we had a customer use our board for the first time with Windows 8.1. After they did, the memory check routine failed. After locating a Win8.1 laptop, I was able re-create the problem. Win7 and Win8.0 do not cause this problem. The version of Excel does not seem to matter either but I wouldn't guarantee that. Reading the memory back from the micro before and after the Excel VBA download, I see 2 bytes that I was checking for an erased file are set to zero. From the Files.c file, there is a section defining the FAT0 locations.
[code]
ROM BYTE FAT0[MEDIA_SECTOR_SIZE] ={ 0xF8,0x0F, // Copy of the media descriptor 0xFF8 0x00, // FAT12 system! 0xFF,0x0F, //};
[code]
After the Excel download using Win8.1, the last 0x0FFF is missing. Here are the uploaded memory locations.
Before: 0FF8 FF00 000F
After: 0FF8 0000 0000
This is actually the same results I get if I erase the TXT file, no matter version of Windows I use. But that makes sense. I've heard Win8.1 is quite a bit different than Win8.0 but I thought that was just the way it looked. I don't see the FF00 000F combination anywhere else in the memory so I don't think it's written to a different location.

Has anyone else seen similar issues with Win8.1? If I ignore those 2 memory locations being zeroed, everything else seems to work ok. Is this just a Win8.1 issue I'll have to live with?

T Yorky wrote:Hi,
The issue you describe with Win8.1 appears correct. A formatted FAT12 device should have cluster number 2 and onwards set to zero (unallocated) unless they have been detected as faulty. Cluster 0 and 1 do not actually exist but the FAT position entries do and are used for other purposes.
Is it possible that you have misinterpreted MChips MSD example?
If I recall correctly, as an example for their internal MSD, they include an example file on the 'disk' which is included in the code that initialises a root directory entry and a sector. Due to this, the first available cluster is allocated to this example file. As it is only a small bit of text in a single sector, only a single cluster is allocated so it is both the first and last cluster! Importantly, being the last cluster the FAT has an end of cluster chain marker (#FFF) stored in the FAT for cluster 2.
It would be very worth while to investigate the FAT specification that Microsoft provides on their website (but it does have some errors!!!).
Hope the above assists.
T Yorky

pcbbc wrote:
And it is only by chance that the file is located in cluster 2. It would be perfectly valid for the file system driver to place a file in any free cluster of the file system, if it so decided.

It is just convention/happenstance that usually most file systems allocate from the first unused cluster upwards - but there is absolutely no guarantee of that.

The correct way to check for a deleted file is to read the root directory (assuming that is where it is located) and look for it by name. Simply assuming its location is constant in the FAT is wrong. Even of you can guarantee the file was originally occupying the first available FAT cluster for storage of the file, it could have just as easily been replaced by a different file (also less than 1 cluster in size) and you'd be none the wiser.