indianajones11 
I'm viewing a 2 GB SD card via WinHex and when i view it
as a logical drive sector 0 is filled w/ #s ( MBR ?,
right ). Viewed as a physical drive, sector 0 only has
#s in the 1st P.T., all other #s = 0 and the boot record
is at sector 137!!! I'd appreciate help in understanding
this so I can write my uC access code.
The P.T. shows an INACTIVE part. does that mean i have
to partition the card after I've formatted it ?
clawson 
Don't move onto "logical" until you have decoded the physical.
So start with a physical view and take a look at sector 0. There are two possibilities.
1) Either it is an MBR in which case offset 0x1BE is that the start of the partition table. The chances are (unless it has "complex" formatting) there will be just one of the four partition table entries used. One of the joys of WinHex is that it has templates to decode things like MBRs so if you are viewing sector 0 and you click the down arrow just above where the ASCII is displayed there is a "Partition 1" entry and on that "Partition Table (template)". Use this to get a decoded view of the partition table. The chances are "sectors preceding partition 1" is showing 137 in your case
2) a lesser possibility is that the very first sector is not an MBR at all but a boot sector containing a BPB (in case 1 this is what was in sector 137). In this case use "Boot sector (template)" to have the fields easily decoded.
If it's a BPB then offset 0x36 in the sector probably contains the text "FAT ..."
Cliff
PS Why bother re-inventing this wheel. I doubt anyone's going to make as good a job of it as E L Chan in FatFs and it "hides" all this detail. He knows how to differentiate an MBR or BPB and how to navigate from it to the FATs and the root. It all "just happens"
PPS I forgot to say - if you want to "hand decode" this stuff it is totally, completely and 100% accurately described in Microsoft's fatgen103 which you should be able to find as a PDF or DOC ... Google says: http://staff.washington.edu/ditt...
indianajones11 Under phy. viewing, I selected P.T. template using "access", but the template window that comes up has MBR at the top ( 137 is at offset 454 ), but the sector is mostly 0's!! When I access the boot record temp. at 137, IT looks like an MBR, but temp. window calls it only boot record ( and it's sector is filled w/ #s ).
So Clawson , it must be your case 1.
Thank you.
p.s.
I agree w/ you Clawson about NOT reinventing, this is just an educational exercise in writing SOME SD read only code.
pps -- I have that doc., but I'll take ,say Paul S.'s explaination of FAT over it most any day.
thanks anyway
indianajones11 The P.T. has $38 instead of $00 or $08 concerning whether or not partition's active or not. I searched them'net first, but can't find anything about such a #.
clawson Drag the cursor over the entire 512 byte sector you are talking about then on the WinHex edit menu select CopyBlock-EditoDisplay then paste the text here like this:
========================================================================================= Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 33 C0 8E D0 BC 00 7C FB 50 07 50 1F FC BE 1B 7C 3ÀŽÃ¼.|ûP.P.ü¾.| 00000010 BF 1B 06 50 57 B9 E5 01 F3 A4 CB BD BE 07 B1 04 ¿..PW¹å.ó¤Ë½¾.±. 00000020 38 6E 00 7C 09 75 13 83 C5 10 E2 F4 CD 18 8B F5 8n.|.u.Æ’Ã….âôÃ.‹õ 00000030 83 C6 10 49 74 19 38 2C 74 F6 A0 B5 07 B4 07 8B Į.It.8,tö µ.´.‹ 00000040 F0 AC 3C 00 74 FC BB 07 00 B4 0E CD 10 EB F2 88 ð¬<.tü»..´.Ã.ëòˆ 00000050 4E 10 E8 46 00 73 2A FE 46 10 80 7E 04 0B 74 0B N.èF.s*þF.€~..t. 00000060 80 7E 04 0C 74 05 A0 B6 07 75 D2 80 46 02 06 83 €~..t. ¶.uÒ€F..Æ’ 00000070 46 08 06 83 56 0A 00 E8 21 00 73 05 A0 B6 07 EB F..Æ’V..è!.s. ¶.ë 00000080 BC 81 3E FE 7D 55 AA 74 0B 80 7E 10 00 74 C8 A0 ¼.>þ}Uªt.€~..tÈ 00000090 B7 07 EB A9 8B FC 1E 57 8B F5 CB BF 05 00 8A 56 ·.ë©‹ü.W‹õË¿..Å V 000000A0 00 B4 08 CD 13 72 23 8A C1 24 3F 98 8A DE 8A FC .´.Ã.r#Å Ã$?˜ŠÞŠü 000000B0 43 F7 E3 8B D1 86 D6 B1 06 D2 EE 42 F7 E2 39 56 C÷ã‹Ñ†Ö±.ÒîB։9V 000000C0 0A 77 23 72 05 39 46 08 73 1C EB 1A 90 BB 00 7C .w#r.9F.s.ë..».| 000000D0 8B 4E 02 8B 56 00 CD 13 73 51 4F 74 4E 32 E4 8A ‹N.‹V.Ã.sQOtN2äŠ000000E0 56 00 CD 13 EB E4 8A 56 00 60 BB AA 55 B4 41 CD V.Ã.ëäŠV.`ȻU´Aà 000000F0 13 72 36 81 FB 55 AA 75 30 F6 C1 01 74 2B 61 60 .r6.ûUªu0öÃ.t+a` 00000100 6A 00 6A 00 FF 76 0A FF 76 08 6A 00 68 00 7C 6A j.j.ÿv.ÿv.j.h.|j 00000110 01 6A 10 B4 42 8B F4 CD 13 61 61 73 0E 4F 74 0B .j.´B‹ôÃ.aas.Ot. 00000120 32 E4 8A 56 00 CD 13 EB D6 61 F9 C3 49 6E 76 61 2äŠV.Ã.ëÖaùÃInva 00000130 6C 69 64 20 70 61 72 74 69 74 69 6F 6E 20 74 61 lid partition ta 00000140 62 6C 65 00 45 72 72 6F 72 20 6C 6F 61 64 69 6E ble.Error loadin 00000150 67 20 6F 70 65 72 61 74 69 6E 67 20 73 79 73 74 g operating syst 00000160 65 6D 00 4D 69 73 73 69 6E 67 20 6F 70 65 72 61 em.Missing opera 00000170 74 69 6E 67 20 73 79 73 74 65 6D 00 00 00 00 00 ting system..... 00000180 8B F4 8A 56 24 CD 13 61 61 72 0B 40 75 01 42 03 ‹ôŠV$Ã.aar.@u.B. 00000190 5E 0B 49 75 06 F8 C3 41 BB 00 00 60 66 6A 00 EB ^.Iu.øÃA»..`fj.ë 000001A0 B0 42 4F 4F 54 4D 47 52 20 20 20 20 0D 0A 52 65 °BOOTMGR ..Re 000001B0 6D 6F 76 65 20 64 69 73 2F E3 BB 15 72 20 80 01 move dis/ã».r €. 000001C0 01 00 0E FE 3F 0E 3F 00 00 00 C1 D3 03 00 00 00 ...þ?.?...ÃÓ.... 000001D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000001E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000001F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA ..............Uª
This is an MBR (not a boot/BPB) from a 128MB USB stick I currently have attached. This has Win98SE boot code but at 0x1BE is a one entry partition table:
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 000001B0 80 01 €. 000001C0 01 00 0E FE 3F 0E 3F 00 00 00 C1 D3 03 00 ...þ?.?...ÃÓ..
Some key fields in this are the 0x0000003F (sectors before) and 0x0003D3C1 (sectors in partition)
Cliff
PS I added the line of '='s to make this a deliberately over-wide post to maintain layout.
indianajones11 This is W.Hex view access -> Part. 1 -> P.T. ( template ). Template window shows it is MBR. Patriot says they don't follow HD layout w/ their SD cards and MBR mostly 0's is correct. I've tweaked my access code, running on m644, and i get correct responses for Cmd0 and cmd1. I then read in MBR and confirmed it by signature bytes !! Why do i have to multiply the LBA by 512 ??!! Why can't i just load $0000 0089
( to go to 1st part. )for my sector read func.?
thanks in advance, Jerome
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 000000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000016 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000032 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000048 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000064 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000096 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000112 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000128 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000144 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000176 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000192 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000208 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000224 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000256 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000272 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000288 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000304 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000320 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000336 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000352 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000368 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000384 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000400 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000416 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000432 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 ................ 000000448 0C 00 06 38 F8 B8 89 00 00 00 77 9F 3A 00 00 00 ...8ø¸‰...wŸ:... 000000464 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000480 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000496 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA ..............Uª
clawson OK what I read there is:
0x1BE (446): 0x00 - partition is not active
0x1BF : 0x02, 0x0C, 0x00 - CHS start (but unused)
0x1C2 : 0x06 - type
0x1C3 : 0x38, 0xF8, 0xB8 - CHS end
0x1C6 : 0x89, 0x00, 0x00, 0x00 - offset to partition start
0x1CA : 0x77, 0x9F, 0x3A, 0x00 - 3A9F77 sectors in partition
So I'd suggest the boot/BPB is to be found in sector 0x89. Also the partition is 1,920,955.5 K long - so presumably this is a 2GB card?
Cliff
Jepael Why do i have to multiply the LBA by 512 ??!! Why can't i just load $0000 0089
( to go to 1st part. )for my sector read func.?
Because SD cards have no "read sector" command. They are accessed with byte addresses, not with sector addresses. So yes, you have to multiply the LBA by 512 for SD read command. Easy as LBA<<9.
However, IIRC, SDHC cards are accessed with sector addresses.
Master boot record at physical sector 0:
At 0x1BE: (byte) 0x00: partition is not bootable. 0x80 indicates it's bootable.
At 0x1C2: (byte) partition type
At 0x1C6: (dword) sector number of partition boot record, little-endian.
The partition type byte depends on the card size for FAT12 and FAT16 cards - it doesn't tell you which it is. 0x01 if the size is less than 32680 sectors (16.5MB), 0x04 if less than 65536 sectors (33MB), otherwise 0x06. It hasn't been possible to buy a card small enough to be FAT12 for many years, so in practice all cards up to 2GB are 0x06 and FAT16. A FAT32 card will be either 0x0B if the size is less than 16,450,560 sectors (8GB) and 0x0C for larger.
That's all you need from the MBR. The other three partition table entries are always all zero, as SD cards are only allowed to have one partition.
The partition boot record is at the physical sector number given in 0x1C6, which is logical sector 0. Many of its entries are fixed in the SD card spec and can be assumed fixed when I write ALWAYS. FAT16 and FAT32 records are slightly different.
FAT16 partition boot record (all words and dwords are little-endian)
0x00B: (word) sector size, ALWAYS 512 (0x0200)
0x00D: (byte) sectors per cluster, ALWAYS a power of 2: 1, 2, 4, 8, 16, 32, 64 (128 is not allowed)
0x00E: (word) reserved sector count, ALWAYS 1
0x010: (byte) number of FATs, ALWAYS 2
0x011: (word) number of root entries, ALWAYS 512
0x013: (word) number of sectors in partition if this is less than 65535, otherwise 0x0000
0x015: (byte) medium identifier, ALWAYS 0xF8
0x016: (word) number of sectors in each FAT
0x01C: (dword) number of hidden sectors (offset from here to first FAT)
0x020: (dword) total number of sectors if 0x013 is zero
The rest is irrelevant.
FAT32 partition boot record (all words and dwords are little-endian)
The FAT32 partition boot block consists of 3 bytes at logical sectors 0..2, backed up at logical sectors 6..8. The boot record at logical sector 0 is similar to FAT16, but see the FAT32 spec for the other two sectors.
0x00B: (word) sector size, ALWAYS 512 (0x0200)
0x00D: (byte) sectors per cluster, ALWAYS a power of 2: 1, 2, 4, 8, 16, 32, 64 (128 is not allowed)
0x00E: (word) reserved sector count, variable
0x010: (byte) number of FATs, ALWAYS 2
0x011: (word) number of root entries, ALWAYS 0x0000
0x013: (word) ALWAYS 0x0000
0x015: (byte) medium identifier, ALWAYS 0xF8
0x016: (word) ALWAYS 0x0000
0x01C: (dword) number of hidden sectors (offset from here to first FAT)
0x020: (dword) total number of sectors
0x024: (dword) sectors per FAT
0x028: (word) extension flag - controls FAT mirroring. If bit 7 is zero, write both FAT copies.
0x02A: (word) FS version, ALWAYS 0x0000
0x02C: (dword) root dir first CLUSTER number (not sector number) (usually 2)
0x030: (word) FS info sector (LOGICAL sector number) ALWAYS 1
0x032: (word) Backup boot sector (LOGICAL sector number) ALWAYS 6
The rest is irrelevant.
In FAT32 you're supposed to keep the FS info sector up to date with the free sector count, etc. See FAT32 spec. The root directory is not in a fixed area, it's a file with a FAT like any other, though the spec says it should always start at the first free cluster, which is 2.
SD cards over 4GB (SDHC cards) have too many bytes to fit the byte address in a dword. These cards have a different physical layer protocol and use sector addresses instead of byte addresses. Starting them up and verifying the card type is a bit more involved than the smaller cards, so they're best avoided if you're trying to write the protocol yourself and don't have a copy of the full $D card $pec.
jesper 
Umm, those ALWAYS values are not really fixed, and certainly not part of the SD card spec.
They are FILE SYSTEM specific, in this case FAT, but SOME of them could be different from the values you describe. Note COULD BE, they most likely will not be, unless you use special formatting like I do on certain apps (card obviously still work fine in Windows e.t.c.).
The # of reserved sectors and position of the backup boot is also configurable. Use of the FSInfo sector is not required.
jesper Here is, btw, an interesting observation regarding the reserved sectors after the partition sector:
Windows format will NOT touch these sectors, when reformatting the card, neither with quick format nor full format. So you can store data there, that will survive a format - at least on a Windows platform.
Umm, those ALWAYS values are not really fixed, and certainly not part of the SD card spec.
"This field shall specify the size of a sector in bytes. It shall be recorded as the number 512."
"This field shall specify the number of sectors reserved for system use. It shall be recorded as the number 1."
There's nothing to stop you formatting it differently with different values, but then strictly speaking, it's no longer an SD card. Windows complies with the specification.
jesper Well, that would mean you could only format SD cards as FAT, not as EFS3 or whatever the Linux filesystem are called. Or any other filesystem, for that matter.
I know the spec, but again, those values are NOT related to the card, but to the filesystem. Specifying hard coded values for a card build up by unrelated, sequential sectors is ridicoulous.
Newer SD cards have sector sizes of 1024 or 2048 bytes.
theusch 
Umm, those ALWAYS values are not really fixed, and certainly not part of the SD card spec.
Jesper, I am a member of the SD Card Association, I have the full 2009 version 3 spec in front of me, and those ALWAYS values most certainly are part of the SD card spec.
Well, that would mean you could only format SD cards as FAT, not as EFS3 or whatever the Linux filesystem are called. Or any other filesystem, for that matter.I know the spec, but again, those values are NOT related to the card, but to the filesystem. Specifying hard coded values for a card build up by unrelated, sequential sectors is ridicoulous.
Is the "spec" with the 512 hard number now outdated?
I haven't explored all the corners, but the ElmChan TinyFATfs seems to be happy with various MMC and SD cards.
Lee
It seems that some cards do not accept 512 bytes read/writes as this Freak experiences.
Jepael It does not matter what sector size the memory card informs, a FAT filesystem can never have other than 512 bytes per sector.
So if translation between card sectors and FAT sectors is needed, it is done elsewhere.
clawson I understand the ALWAYS fields in the SD(HC) spec and that's almost certainly how all card manufacturers deliver their cards to be conformant but does something like the format command in Windows know these rules? As soon as someone screws the FS structure then use DOS/Windows format.exe to "repair" the damage is the FS then created still conformant? Or may the ALWAYS fields b varied?
While it may save code to assume that those ALWAYS fields are constant I think I'd burn a few more bytes and read/calculate everything just as you would if handling an HDD - what's that phrase about assumption being the mother of all f*** ups? ;-)
It seems that some cards do not accept 512 bytes read/writes as this Freak experiences.
Similarly, you don't connect an SD card directly to a Windows computer - you plug it in to a card reader (even if this is built in to the computer), and this reader has in it a processor that opens and initializes the card and presents it to Windows as an external hard drive using the SCSI command set (another spec to read). It's kind of important that every link in the chain speaks the same language, and that's the reason for following specifications and conforming to standards. If the Linux guys don't understand this... But of course they do, otherwise you couldn't mount an SD card on Ubuntu. There are, incidentally, two parts to the SD spec, the physical spec and the file system spec, so saying such and such is not in the SD spec because it's part of the file system is misinformation.
Personally I think it's ridiculous that the SD card specifications are private and members-only, but that's not my business. At least there are some redacted versions out there from Sandisk and others - that's how I got started - but I wasted a lot of time writing drivers to handle cases (single FAT, etc) that I later found can never happen. My motivation for posting the information above was to clarify this for other people. I'm not saying to assume the data blindly - if it wasn't meant to be checked it wouldn't be there - but that there's no need to write drivers for any other case.
For what it's worth, the 512 byte sector continues to be the standard for the foreseeable future. The spec for the exFAT file system, for cards bigger than 32GB, contains the following wording:
SectorsPerClusterShift
This field shall specify the bytes per sector expressed as log2(N), where N is the number of bytes per sector. For example, for 512 bytes per sector, the value of this field is 9. This field shall be recorded as the number 9.
indianajones11 Yes, Clawson, the SD card is 2 GB ( sorry for the late reply ). Jesper, thanks for the head's up about our beening able to store at reserved sectors and to Japeal for answering about why need to * by 512.
1) Since my P.T. shows the part. is INACTIVE, how come my m644 read_sector code works
2)and do i need to activate an SD card part. If so, how ( FDISK does nothing )?
3) Does the "simplified physical spec. " apply to SDHC
cards ( maybe with a different init. sequence though ? )? I'd love to be able to work w/ a 32 GB card.
clawson
1) Since my P.T. shows the part. is INACTIVE, how come my m644 read_sector code works
2)and do i need to activate an SD card part. If so, how ( FDISK does nothing )?
3) Does the "simplified physical spec. " apply to SDHC
DSTATUS disk_initialize (
BYTE drv /* Physical drive nmuber (0) */
)
{
BYTE n, cmd, ty, ocr[4];
if (drv) return STA_NOINIT; /* Supports only single drive */
if (Stat & STA_NODISK) return Stat; /* No card in the socket */
power_on(); /* Force socket power on */
FCLK_SLOW();
for (n = 10; n; n--) rcvr_spi(); /* 80 dummy clocks */
ty = 0;
if (send_cmd(CMD0, 0) == 1) { /* Enter Idle state */
Timer1 = 100; /* Initialization timeout of 1000 msec */
if (send_cmd(CMD8, 0x1AA) == 1) { /* SDHC */
for (n = 0; n < 4; n++) ocr[n] = rcvr_spi(); /* Get trailing return value of R7 resp */
if (ocr[2] == 0x01 && ocr[3] == 0xAA) { /* The card can work at vdd range of 2.7-3.6V */
while (Timer1 && send_cmd(ACMD41, 1UL << 30)); /* Wait for leaving idle state (ACMD41 with HCS bit) */
if (Timer1 && send_cmd(CMD58, 0) == 0) { /* Check CCS bit in the OCR */
for (n = 0; n < 4; n++) ocr[n] = rcvr_spi();
ty = (ocr[0] & 0x40) ? CT_SD2 | CT_BLOCK : CT_SD2; /* SDv2 */
}
}
} else { /* SDSC or MMC */
if (send_cmd(ACMD41, 0) <= 1) {
ty = CT_SD1; cmd = ACMD41; /* SDv1 */
} else {
ty = CT_MMC; cmd = CMD1; /* MMCv3 */
}
while (Timer1 && send_cmd(cmd, 0)); /* Wait for leaving idle state */
if (!Timer1 || send_cmd(CMD16, 512) != 0) /* Set R/W block length to 512 */
ty = 0;
}
}
CardType = ty;
release_spi();
indianajones11 Thanks again Clawson, lastly( maybe ? ), do I have to do a byte reverse for every 2 MP3 DATA BYTE reads, since the card is little endian?
thanks in advance
Hi,
I am using TFT LCD to display image and I am reading the physical address of SD card's image(.bin) from win-hex tool and it was giving the physical address which also worked fine to display the image, but after some days it started giving me system volume information while reading the image physical address resulting in failure of image display.
I have also formatted the SD card and repeated the process but then also the issue is same.
Please help me out to solve this.
Thanks,
Shivakumar
clawson As soon as you get FAT fragmentation you can no longer rely on adjacent allocation units (aka "Clusters"). So if you want to read FAT use a FAT reading system like FatFs. It knows how to follow the allocation chains however muddled their physical layout might actually be.