Windows 8.1 Effect on FAT12

Windows 8.1 Effect on FAT12

Postby Tight Yorky » Fri Jun 20, 2014 9:58 am

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?
Last edited by ric on Fri Jun 20, 2014 11:38 am, edited 1 time in total.
Reason: added quote tags
Tight Yorky
 
Posts: 22
Joined: Thu Jun 19, 2014 10:32 pm
PIC experience: Professional 2-5 years with MCHP products

Re: Windows 8.1 Effect on FAT12

Postby Tight Yorky » Fri Jun 20, 2014 10:00 am

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
Tight Yorky
 
Posts: 22
Joined: Thu Jun 19, 2014 10:32 pm
PIC experience: Professional 2-5 years with MCHP products

Re: Windows 8.1 Effect on FAT12

Postby Tight Yorky » Fri Jun 20, 2014 10:01 am

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.
Tight Yorky
 
Posts: 22
Joined: Thu Jun 19, 2014 10:32 pm
PIC experience: Professional 2-5 years with MCHP products

Re: Windows 8.1 Effect on FAT12

Postby Tight Yorky » Fri Jun 20, 2014 10:04 am

Hi,

pcbbc you are correct about the allocation, any cluster can be valid, and may be due to the history of transactions on the disk.

But just to expand on my previous post, that may not be obvious to a reader that has not seen the internal MSD code by MChip. There is no format command in the application, the FAT12 'disk' format is effectively coded in the 'C' file as constant byte arrays. So if the application is adapted for your own use, it is necessary to re-evaluate (all) the relevant sector entries to ensure the format is valid for an operating system to read. If you add or remove a pre-loaded file for example, the root dir, both FAT entries, the data cluster(sectors) have to be altered in the byte arrays.


hoosier, I find it easier to work with FAT12 by remaining in bytes rather than constructing words. Writing the bytes backwards helps interpret the FAT12 clusters (see the attached jpg which is a screen capture of an excel sheet).

You can be prevent Windows formatting your disk by preventing write access to LBA 0 and 1 (MBR/VBR) and returning an invalid command through the SCSI command reply.

Hope this assists.

T Yorky.
(I have posted here as MChip forum would not accept my post after over an hour of trying!)
Attachments
Post002_FAT.jpg
Post002_FAT.jpg (99.2 KiB) Viewed 5748 times
Tight Yorky
 
Posts: 22
Joined: Thu Jun 19, 2014 10:32 pm
PIC experience: Professional 2-5 years with MCHP products

Re: Windows 8.1 Effect on FAT12

Postby bmernax30 » Tue Nov 24, 2015 10:34 pm

Hey guys,
I feel like I'm running into a similar problem as in this post. I ended up stumbling upon this searching for an answer. My original post in the microsoft forums is in the link here.

http://answers.microsoft.com/en-us/wind ... 928ef6ffb7

The jist of the problem seems to be Windows 8.1 and its ineffectiveness at handling a Fat12 system. In my problem I'm creating a 64KB USB mass storage from a Nuc123 series microcontroller. The code works fine on Windows 7, but in Windows 8.1 and 10 there's a 1Kb space that is detected as used and it won't allow a 64KB bin file to go in there. What's weird is the problem resolves itself after I put the computer to sleep and wake it back up. The 1Kb used space disappears.

Can anyone help give me some more information on Windows 8.1 and its issues with FAT12?

I've looked into the code and I think the program revolves around reading the format data block and Windows trying to fix a problem in that which screws everything up.
bmernax30
 
Posts: 1
Joined: Tue Nov 24, 2015 10:27 pm


Return to USB

Who is online

Users browsing this forum: No registered users and 2 guests

cron