Forums

SD card and FAT32 (dosfs and fat_io)

Started by John Speth August 21, 2014
Hi folks,

I need to utilize a known-to-work FAT16/32 library for reading SD cards. 
  I'm seeing peculiar boot record data that doesn't make any sense to 
me.  I'm hoping somebody here has preceded me in getting SD cards 
readable with FAT FS libraries.

We've used both dosfs and fat_io (both free to use from the web) with 
success on USB flash drives and rotating magnetic drives.  Now the 
simple process of interfacing to SD cards shows problems in the volume 
boot record (VBR) sector address held in the master boot record (MBR). 
Specifically, the VBR start sector is sector 8192 for all three FAT32 SD 
card samples we're using but no valid VBR exists at that sector.  Our 
single FAT16 SD card sample indicates the correct VBR start sector 
(sector 39) because we can read all files and directories on it.

An important data point is that I've been able to find a valid VBR at 
sector 16 for all my FAT32 cards.  Sector 16 just happens to be the 
sector at byte address 8192 (just a coincidence or significant?).  If I 
redirect the VBR read mechanism to sector 16, I get additional API usage 
failures.

Is there some sort of important differences with SD cards that I need to 
take into account for FAT32 file systems?

Thanks = John Speth
In article <lt5usc$rpp$1@speranza.aioe.org>, johnspeth@yahoo.com says...
> Hi folks, > > I need to utilize a known-to-work FAT16/32 library for reading SD cards. > I'm seeing peculiar boot record data that doesn't make any sense to > me. I'm hoping somebody here has preceded me in getting SD cards > readable with FAT FS libraries. > > We've used both dosfs and fat_io (both free to use from the web) with > success on USB flash drives and rotating magnetic drives. Now the > simple process of interfacing to SD cards shows problems in the volume > boot record (VBR) sector address held in the master boot record (MBR). > Specifically, the VBR start sector is sector 8192 for all three FAT32 SD > card samples we're using but no valid VBR exists at that sector. Our > single FAT16 SD card sample indicates the correct VBR start sector > (sector 39) because we can read all files and directories on it. > > An important data point is that I've been able to find a valid VBR at > sector 16 for all my FAT32 cards. Sector 16 just happens to be the > sector at byte address 8192 (just a coincidence or significant?). If I > redirect the VBR read mechanism to sector 16, I get additional API usage > failures. > > Is there some sort of important differences with SD cards that I need to > take into account for FAT32 file systems? > > Thanks = John Speth >
I use the library from, what used to be, embedded-code.com. They've since closed down and made the library free. I had to do a few tweaks for my particular compiler, but it seems to work well. It handles FAT32 and just plain old FAT formatted cards. The only problem I have is some el-cheapo cards don't work with the initialization code. In fact I am investigated that right now, but all name brand cards jam right on. http://www.embedded-code.com/source-code/memory/secure-digital-mmc- memory-cards/secure-digital-mmc-memory-card-fat16-fat32-driver Tiny URL : http://tinyurl.com/po3oyrk
On Thu, 21 Aug 2014 20:03:16 -0400, WangoTango wrote:

> In article <lt5usc$rpp$1@speranza.aioe.org>, johnspeth@yahoo.com says... >> Hi folks, >> >> I need to utilize a known-to-work FAT16/32 library for reading SD >> cards. >> I'm seeing peculiar boot record data that doesn't make any sense to >> me. I'm hoping somebody here has preceded me in getting SD cards >> readable with FAT FS libraries. >> >> We've used both dosfs and fat_io (both free to use from the web) with >> success on USB flash drives and rotating magnetic drives. Now the >> simple process of interfacing to SD cards shows problems in the volume >> boot record (VBR) sector address held in the master boot record (MBR). >> Specifically, the VBR start sector is sector 8192 for all three FAT32 >> SD card samples we're using but no valid VBR exists at that sector. >> Our single FAT16 SD card sample indicates the correct VBR start sector >> (sector 39) because we can read all files and directories on it. >> >> An important data point is that I've been able to find a valid VBR at >> sector 16 for all my FAT32 cards. Sector 16 just happens to be the >> sector at byte address 8192 (just a coincidence or significant?). If I >> redirect the VBR read mechanism to sector 16, I get additional API >> usage failures. >> >> Is there some sort of important differences with SD cards that I need >> to take into account for FAT32 file systems? >> >> Thanks = John Speth >> > I use the library from, what used to be, embedded-code.com. > They've since closed down and made the library free. > I had to do a few tweaks for my particular compiler, but it seems to > work well. It handles FAT32 and just plain old FAT formatted cards. The > only problem I have is some el-cheapo cards don't work with the > initialization code. In fact I am investigated that right now, but all > name brand cards jam right on. > > http://www.embedded-code.com/source-code/memory/secure-digital-mmc- > memory-cards/secure-digital-mmc-memory-card-fat16-fat32-driver > > Tiny URL : http://tinyurl.com/po3oyrk
Woo hoo! I was going to ask what to use, and someone dun dood it already! I just looked through the documentation, and from my brief look I think I'm going to be happy. Note that when they say "click this link", everything is the same color and only "link" is the link. @@ (This is for a semi-customer project. It's sort of a hobby project, but I'm selling it in small quantities. The current board revision has a 2MB serial flash. My launch semi-customer said "so why not a micro-SD card?". "Cuz it don't fit no good!" sez I He made skeptical noises. So in spite of the fact that I had better things to do, I dropped a Micro-SD holder next to the board so that I could send him a print-out of the layout to PROVE that the Micro-SD was too damned big. Then I looked at it, and looked at it again -- and then I spent half a day and shoe-horned it onto my board. Customers can be a pain that way. This is on a board that's 31 x 43 mm, and has plenty of other stuff going on.) -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
In article <8JadnVJg_8HS5rbJnZ2dnUVZ5rSdnZ2d@giganews.com>, 
seemywebsite@myfooter.really says...
> On Thu, 21 Aug 2014 20:03:16 -0400, WangoTango wrote: > > > In article <lt5usc$rpp$1@speranza.aioe.org>, johnspeth@yahoo.com says... > >> Hi folks, > >> > >> I need to utilize a known-to-work FAT16/32 library for reading SD > >> cards. > >> I'm seeing peculiar boot record data that doesn't make any sense to > >> me. I'm hoping somebody here has preceded me in getting SD cards > >> readable with FAT FS libraries. > >> > >> We've used both dosfs and fat_io (both free to use from the web) with > >> success on USB flash drives and rotating magnetic drives. Now the > >> simple process of interfacing to SD cards shows problems in the volume > >> boot record (VBR) sector address held in the master boot record (MBR). > >> Specifically, the VBR start sector is sector 8192 for all three FAT32 > >> SD card samples we're using but no valid VBR exists at that sector. > >> Our single FAT16 SD card sample indicates the correct VBR start sector > >> (sector 39) because we can read all files and directories on it. > >> > >> An important data point is that I've been able to find a valid VBR at > >> sector 16 for all my FAT32 cards. Sector 16 just happens to be the > >> sector at byte address 8192 (just a coincidence or significant?). If I > >> redirect the VBR read mechanism to sector 16, I get additional API > >> usage failures. > >> > >> Is there some sort of important differences with SD cards that I need > >> to take into account for FAT32 file systems? > >> > >> Thanks = John Speth > >> > > I use the library from, what used to be, embedded-code.com. > > They've since closed down and made the library free. > > I had to do a few tweaks for my particular compiler, but it seems to > > work well. It handles FAT32 and just plain old FAT formatted cards. The > > only problem I have is some el-cheapo cards don't work with the > > initialization code. In fact I am investigated that right now, but all > > name brand cards jam right on. > > > > http://www.embedded-code.com/source-code/memory/secure-digital-mmc- > > memory-cards/secure-digital-mmc-memory-card-fat16-fat32-driver > > > > Tiny URL : http://tinyurl.com/po3oyrk > > Woo hoo! I was going to ask what to use, and someone dun dood it > already! I just looked through the documentation, and from my brief look > I think I'm going to be happy. > > Note that when they say "click this link", everything is the same color > and only "link" is the link. @@ > > (This is for a semi-customer project. It's sort of a hobby project, but > I'm selling it in small quantities. The current board revision has a 2MB > serial flash. My launch semi-customer said "so why not a micro-SD card?". > > "Cuz it don't fit no good!" sez I > > He made skeptical noises. So in spite of the fact that I had better > things to do, I dropped a Micro-SD holder next to the board so that I > could send him a print-out of the layout to PROVE that the Micro-SD was > too damned big. Then I looked at it, and looked at it again -- and then I > spent half a day and shoe-horned it onto my board. > > Customers can be a pain that way. > > This is on a board that's 31 x 43 mm, and has plenty of other stuff going > on.) > >
If you have any issues with the code, just drop me a note. The only real issue I have had is that some cards that return result codes for SDHC compliance are not really compliant. Not handling the CMD16 command seems to be pretty common.