MMC fat16 status report

Gene Smith gds at chartertn.net
Thu Jan 15 17:11:54 UTC 2009


When doing cp in the shell on a single file I am still not getting good 
results but am beginning to see what it does and it is consistent. 
Possibly someone with a SD, MMC or other linear flash device can try 
this and see if they see the same thing.

I start with a newly formatted card, fat16 using gparted, and copy in 
one very short text file, freddy.txt. Looking at the sdd1 partition with 
dd it looks fine: the fat tables are as expected and the root directory 
contains just the file freddy.txt. The file freddy.txt resides in 
cluster 3. Cluster 2, the actual first cluster, is still available but 
not yet used (don't know why) so the fat table(s) looks like this initially:

0000200: f8ff ffff 0000 ffff 0000 0000 0000 0000  ................
0000210: 0000 0000 0000 0000 0000 0000 0000 0000  ................
:
001ec00: f8ff ffff 0000 ffff 0000 0000 0000 0000  ................
001ec10: 0000 0000 0000 0000 0000 0000 0000 0000  ................
:

Note: the first two cluster (marked by 1st and 2nd word, f8ff,ffff) 
don't really exist from what I understand so the 1st cluster is index 2 
and for me is at 0x41600. The 0000 indicates it is free.

Root directory entry looks like this:
003d600: 4166 0072 0065 0064 0064 000f 0055 7900  Af.r.e.d.d...Uy.
003d610: 2e00 7400 7800 7400 0000 0000 ffff ffff  ..t.x.t.........
003d620: 4652 4544 4459 2020 5458 5420 0000 9100  FREDDY  TXT ....
003d630: 2e3a 2d3a 0000 6eb5 263a 0300 1300 0000  .:-:..n.&:......
:

And the cluster 3 (the freddy.txt contents) looks like this:
0042600: 0000 006b 696e 670d 0a09 6b69 6e67 0d0a  ...king...king..
0042610: 0909 6b69 6e67 200d 0a00 0000 0000 0000  ..king .........

Then I unmount the card from linux and move it to my rtems board. After 
starting rtems I run the shell and create the mount point and mount the 
card:
mkdir /m
mount -t msdos /dev/sd-card-a1 /m
cd /m

ls shows Af and freddy.txt as expected.

Then I cp freddy.txt albert.txt
and cat albert.txt and see the contents correctly (same as freddy). 
After unmount'ing the card and moving it back to linux I then look again 
with dd. The first fat table looks ok. Albert.txt is added at the 
available first cluster 2 fat position:

0000200: f8ff ffff ffff ffff 0000 0000 0000 0000  ................
0000210: 0000 0000 0000 0000 0000 0000 0000 0000  ................

But then the next 3 sectors are erroneously written in the fat table 
area and contain the second redundant fat table, the directory entry and 
the file contents:

0000400: f8ff ffff ffff ffff 0000 0000 0000 0000  ................
0000410: 0000 0000 0000 0000 0000 0000 0000 0000  ................
:
0000600: 4166 0072 0065 0064 0064 000f 0055 7900  Af.r.e.d.d...Uy.
0000610: 2e00 7400 7800 7400 0000 0000 ffff ffff  ..t.x.t.........
0000620: 4652 4544 4459 2020 5458 5420 0000 9100  FREDDY  TXT ....
0000630: 2e3a 2d3a 0000 6eb5 263a 0300 1300 0000  .:-:..n.&:......
0000640: 414c 4245 5254 2020 5458 5420 0000 0000  ALBERT  TXT ....
0000650: 0000 0000 0000 2110 2d06 0200 1300 0000  ......!.-.......
:
0000800: 6b69 6e67 0a09 6b69 6e67 0a09 096b 696e  king..king...kin
0000810: 6720 0a00 0000 2110 2900 0200 0000 0000  g ....!.).......

But the correct root directory entry is written where it should be and 
contains the new albert.txt pointing to cluster 2:
003d600: 4166 0072 0065 0064 0064 000f 0055 7900  Af.r.e.d.d...Uy.
003d610: 2e00 7400 7800 7400 0000 0000 ffff ffff  ..t.x.t.........
003d620: 4652 4544 4459 2020 5458 5420 0000 9100  FREDDY  TXT ....
003d630: 2e3a 2d3a 0000 6eb5 263a 0300 1300 0000  .:-:..n.&:......
003d640: 414c 4245 5254 2020 5458 5420 0000 0000  ALBERT  TXT ....
003d650: 0000 0000 0000 2110 2606 0200 1300 0000  ......!.&.......

The file contents of the original file freddy.txt are still present in 
cluster 3 but the copied contents of albert.txt (should be the same as 
freddy) are not written to cluster 2. The data for albert.txt is 
(incorrectly) in the fat table at 0x800 !! When file albert.txt is 
dumped with xxd in linux, it contents is the uninitialized data at 
cluster 2:
0041600: 2e20 2020 2020 2020 2020 2010 0000 0000  .          .....
0041610: 0000 0000 0000 2110 2900 0200 0000 0000  ......!.).......

Reading of flash seems to work correctly. Also, all the data is written 
to flash but in the wrong place except for the fisrt fat table contents 
at 0x200 and the new root directory file, albert.txt, at 0x3d600.

One other thing I have observed is that if I copy freddy.txt to 
albert.txt in rtems shell and *don't* cat albert.txt and just unmount, I 
see the same result as above except that albert.txt is not added to the 
root directory files at 0x3d600. So the albert.txt appears not to be 
present on linux (or on rtems after a restart) unless it is cat'd at 
least once in rtems (unmount or blksync does not seem to "sync" the file 
completely, but cat does).

Possibly my MMC driver code has a problem but it reads OK and all data 
is written and some actually at the right place (1st fat, root dir). I 
have tried to step through some of the dosfs code but have been unable 
really tell what is going on with it.

-gene










More information about the users mailing list