SD card and Winhex

Go To Last Post
25 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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 ?

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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 #.

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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ª

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

indianajones11 wrote:
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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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
http://www.yampp.com
The quick black AVR jumped over the lazy PIC.
What boots up, must come down.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

/Jesper
http://www.yampp.com
The quick black AVR jumped over the lazy PIC.
What boots up, must come down.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
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. Examples (quote):

"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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

/Jesper
http://www.yampp.com
The quick black AVR jumped over the lazy PIC.
What boots up, must come down.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Newer SD cards have sector sizes of 1024 or 2048 bytes.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jesper wrote:
Umm, those ALWAYS values are not really fixed, and certainly not part of the SD card spec.

peret wrote:

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.

jesper wrote:

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.


I can see your line of thinking, jesper, but it sure seems as those >>are<< part of the spec unless someone is lying to us interested observers.

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

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It seems that some cards do not accept 512 bytes read/writes as this Freak experiences.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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? ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
It seems that some cards do not accept 512 bytes read/writes as this Freak experiences.

It sounds like Hazmat over there has neglected to use the SD card command to set the write block length. It's part of the open/setup process to write this to 512 for FAT file systems. I shall drop him a note. Remember, with SD cards you're not talking directly to the Flash memory, but to a processor in between that hides the actual storage management from you.

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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:

Quote:
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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

1) Since my P.T. shows the part. is INACTIVE, how come my m644 read_sector code works

You misunderstand what "active"/"inactive" means. It's simply a flag to the BIOS (on an Intel PC) as to whether the x86 code in the boot sector should be loaded into memory and executed. It's nothing to do with whether the partition is readable or not. (it always is)
Quote:

2)and do i need to activate an SD card part. If so, how ( FDISK does nothing )?

So "no". True FDISK can switch the active flag on a partition (you usually set it on the partition that contains the copy of MS-DOS, Windows or Linux) but it would be unwise to mess with it in case you blitz the rest of the MBR at the same time.
Quote:

3) Does the "simplified physical spec. " apply to SDHC

Not sure what you mean but SDHC should be useable with AVRs but they have a more complex init sequence. If you use FatFs you will see this in:

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();

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.