FAT32 Filesystem Slice Design Card

‎One of these Design cards stopped working, it appeared something went wrong with the filesystem so had a look into it :)

So with the help of http://www.pjrc.com/tech/8051/ide/fat32.html this site I managed to work out what was going on. I thought I would put it here to explain quantitatively how to calculate it with a real example.

This is taken from 'Basic elements' Slice card, the image was dumped as dd if=/dev/sde of=ele.dd . All the hex dumps are for the entire card.

MBR and Partition Table

The MBR and partition table - (although the MBR is all 0's)

The partition table starts at 1BE, the first 16 bytes being the primary partition, ending at 1CD

See this for detailed info http://en.wikipedia.org/wiki/Master_boot_record

• 1C2 = 0B, showing type is FAT32 filesystem

• 1C6 to 1C9 = 61000000 , Starting(absolute first sector) LBA(hex,h), convert to little endian,le = 00000061 = 97 (decimal,d)

This shows where the boot sector is, 97 * 512 (bytes/sec) = 49664 d = C200 h

• 1CA to 1CD = 9FC90300, num sectors in partition, to le = 0003C99F h = 248223 d

Partition table dump from fdisk (of ele.dd image)

Disk ele.dd: 127 MB, 127139840 bytes
8 heads, 32 sectors/track, 970 cylinders, total 248320 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

 Device Boot      Start         End      Blocks   Id  System
ele.dd1              97      248319      124111+   b  W95 FAT32

FYI

You will also notice 97 (start) + 248223 (size) -1 = 248319 (end)

Visualise why in simple example of a partition that is 4 sectors long.

[97] [98] [99] [100]

imagine it starts at sector 97, is 4 long, it will end at 100, not 101 i.e. 97 (start) + 4 (size) - 1 = 100 (end)

Seems obvious, easy to miss out when working things out! (least it is for me)

Boot sector

If you move along to offset C200 you will find the boot sector. (if you scroll down you can see the backup copy a bit further down)

• C20B - C20C = 0002 , to le = 0200 h = 512 d (bytes/sector)
• C20D = 02 = 02h = 2 d (sectors/cluster)
• C20E - C20F = 2400 to le = 0024 h = 36 d (reserved sectors)

FAT begin LBA = start sec + reserved sec = 97 + 36 = 133 (* 512) = 68096 d = 10A00 h

• C210 = 02 = 02 = 2 d (number of FATS ,always 2)
• C218 - C219 = 2000 to le 0020 h = 32 d (sectors/track) [Wrong on original card, have fixed here with values from fdisk, (things like testdisk don't like it being wrong)]
• C21A - C21B = 0800 to le = 0008 h = 8 (heads) [Wrong on original card too]
• C224 - C227 = C2030000 to le = 000003C2 h = 962 (sectors / FAT)

First Cluster Begin LBA = start + reserved + ( number FATS + sectors/FAT ) 
                        = 97+36 + (2 * 962) = 2057 d (* 512) = 1053184 d = 101200 h

• C22C - C22F = 02000000 = 00000002 h = 2 d (root directories first cluster)

FAT table

This is the FAT table, didn't look into this as worked out what problem was without needing to!

First Cluster (technically cluster #2), root directory

This was where the first thing was wrong, this table was screwed for the Utils folder (was visible but went nowhere clicking it), the folder attribute was 30 instead of 10 and the first cluster high/low bytes were all 0000's. (The screenshot below I had already started fiddling with it.)

Here is the First Cluster (root dir /) at 101200h

Lets look at subfolder '11'

Note names are space padded, names are not reversed endianess.

Note I am only looking at short filenames (8+3) in this example too.

• 101280 - 101287 = 3131202020202020 = '11 ' (filename, 2 characters with 6 spaces padded)
• 101288 - 10128A = 202020 = ' ' (file extension, just three spaces)
• 10128B = 10 (10 is attribute bit for folder, 20 is a file)
• 101294 - 101295 = 0000 to le = 0000 ('high byte cluster')
• 10129A - 10129B = 4900 to le = 0049 h = 73 d ('low byte cluster')

Cluster number is therfor 73

Start  cluster of '11' LBA = First cluster begin LBA + (cluster number - 2) * sectors/cluster
                           = 2057 + (73 - 2) * 2 = 2199 d (* 512) = 112588d = 112E00 h

Cluster start for sub-dir '11'

The starting cluster of folder 11 is 112E00h

• 113014 - 113015 = 0000 to le = 0000 ('high byte cluster')
• 11301A - 11301B = D829 to le = 29D8 h = 10712 d ('low byte cluster')

Cluster number is 10712

Start  cluster of '11-15' LBA = First cluster begin LBA + (cluster number - 2) * sectors/cluster
                              = 2057 + (10712 - 2) * 2 = 23477 d (* 512) =  12020224 d = B76A00 h

Cluster start for sub-dir '11-15'

Ok I think you get the idea, this 11-15 folder cluster start is B76A00 h

So what went wrong?

By searching for filenames that should have been there somewhere, I found a cluster containing some of them after at the end of all 11-xx folders.

I could see by the filenames and fact there were no '..' and '.' this wasn't the first cluster of the Utils folder though. Scrolling up to find it, I came to a large patch of 0's, before then hitting the end of the 11-xx bits.

I can therefore only assume something physically has gone wrong with the card and that memory segment on it is damaged, presumably the controller then just fills in the gap with 0's.

Although I am sure I did't, I think the lock on the SD card was moved at one point (as it was physically dead when I go it, before it miraculously sprang to life after sitting in laptop for a few hours) which is what messed the first cluster up (root dir) when it couldn't see the 0'd cluster of the Utils folder.

Incidentally if the image is put on another card and run with Windows chkdisk, it will remove the Utils & 12 folder and create a File Found folder with the visible files from the missing Utils folder in (less the ones that I think were in the 0'd section). Doing the same thing with fsck.vfat gets an 'Logical sector size is zero.' error.

References

http://www.pjrc.com/tech/8051/ide/fat32.html

Discussion

blog comments powered by Disqus