Reading sectors from SD Memory?

Thread Starter

spinnaker

Joined Oct 29, 2009
7,830
I have been struggling trying to read anything to successfully read a sector on an SD memory chip. I have tried my own code that I pieced together with code I found scattered on the internet.

It initializes and appears to read the sectors successfully, I am getting my 0XFE start of data token but when I compare it to what I see in a HexEditor on my PC on the same card the bytes don't jive. For example in sector one on this SD chip all bytes are supposed to be 0xFF but when I looked at it with my code on the PIC, all bytes are 0xFF with the exception that every 8th byte is a 0x04.


Also I seem to need to read 1 extra byte reading one sector to get the next sector to read successfully. The extra byte is in addition to the 2 CRC bytes which I am reading and the 8 clock cycles needed at the end of a read.

Which brings up another question. What type of CRC is this? I think it is supposed to be CRC16 but when I calculate CRC16 for the bytes from my PIC code or what is displayed on the HexEditor, nothing seems to match up.

Can anyone provide any assistance?
 

thatoneguy

Joined Feb 19, 2009
6,359
I've only dealt with the filesystem level so data could be transferred to a PC by moving the card.

What OS are you looking at the hex data with?

If you use linux, and look directly at the device, you may get the same results as your PIC. Windows may be hiding "user doesn't need to see" data.
 

Thread Starter

spinnaker

Joined Oct 29, 2009
7,830
I've only dealt with the filesystem level so data could be transferred to a PC by moving the card.

What OS are you looking at the hex data with?

If you use linux, and look directly at the device, you may get the same results as your PIC. Windows may be hiding "user doesn't need to see" data.

I'm using Windows 7. I doubt if anything is being hidden. If you look at my results there seems to be a pattern in what I am seeing (or not seeing) on the Pic.
 

thatoneguy

Joined Feb 19, 2009
6,359
Try writing the sector with a different value and see what the checksum shows up as on both platforms.

Is the checksum generated by the SD card, or by the PIC/PC?
 

Thread Starter

spinnaker

Joined Oct 29, 2009
7,830
Try writing the sector with a different value and see what the checksum shows up as on both platforms.

Is the checksum generated by the SD card, or by the PIC/PC?
Tried that. I couldn't get it to write either. It took the command OK but never finished the write.

I am hoping half of my issues are connection problems. I have a an SD connector soldered to a perf board. My pullup resistors are on a separate old proto board that has probably been pushed past it's useful life. I think what I will do is to solder the pullups on the perf board and do away with the proto board.
 

thatoneguy

Joined Feb 19, 2009
6,359
Maybe try ordering one of the PIC Sticks, or whatever they are called that have an LCD on one side, and a PIC and SD connector on the other side?

I'll try to find the source for that, I think it was the display/guts for an MP3 player, but on professional boards with mostly surface mount devices.

That would give you a $25 "Known Working" platform to work backwards from.
 

Thread Starter

spinnaker

Joined Oct 29, 2009
7,830
Maybe try ordering one of the PIC Sticks, or whatever they are called that have an LCD on one side, and a PIC and SD connector on the other side?

I'll try to find the source for that, I think it was the display/guts for an MP3 player, but on professional boards with mostly surface mount devices.

That would give you a $25 "Known Working" platform to work backwards from.
Yep that is what I was thinking. Microchip has one but they use their convoluted library. I'd like to have a 3rd party one out their with their own code.

Sparkfun use to have one from a company out of England but looks like they no longer carry it.

http://www.olimex.com/dev/index.html

No LCD. An LCD would be nice.
 
Last edited:

thatoneguy

Joined Feb 19, 2009
6,359
Here's a homemade one with project files.

It's written in basic, and so is the library, their might be a tidbit or two of info in that area as well, I've found undocumented tricks in odder places.

Linky
 

Thread Starter

spinnaker

Joined Oct 29, 2009
7,830
Here's a homemade one with project files.

It's written in basic, and so is the library, their might be a tidbit or two of info in that area as well, I've found undocumented tricks in odder places.

Linky
Thanks. I have seen a few of these around. What I really need is one I can purchase. I might just pop for one of those full fledged development boards assuming they come with working sample code. I will probably be in the same place again should I decide to do graphics. It is a lot easier when you have a know working setup.



Strange this guy has no pullup resistors.


I am back to square one now. I rewired by perf board now I have nothing working. Not sure what I did wrong.

I am going to try and add a pullup to the SDO of the SD but from waht I have seen it is not supposed to be needed.
 

davebee

Joined Oct 22, 2008
540
A quick check you can use when reading sectors from a FAT formatted SD card is to look for the DOS signature $55AA as the last two bytes of sector 0. If they show up in bytes 510 and 511 of the result byte array then you're reading the card.

Another thing you could do is use a PC to reformat the card, then write a small text file that contains some distinctive text patterns. Then use your SD read routine to search for the text in the sectors. The text should appear just past all the FAT directory sectors, which should be within probably just a few hundred sectors of the card.

As far as I know, the data CRC is a standard CCITT CRC16, but I've never actually done any data CRC encoding or decoding. I have done command CRC7 encoding, and found that they use a little trick - after all the CRC encoding is done, they shift the results left by one and set bit 0, so unless you know to do that, you'll never get the algorithm to work.
 

thatoneguy

Joined Feb 19, 2009
6,359
A quick check you can use when reading sectors from a FAT formatted SD card is to look for the DOS signature $55AA as the last two bytes of sector 0. If they show up in bytes 510 and 511 of the result byte array then you're reading the card.

Another thing you could do is use a PC to reformat the card, then write a small text file that contains some distinctive text patterns. Then use your SD read routine to search for the text in the sectors. The text should appear just past all the FAT directory sectors, which should be within probably just a few hundred sectors of the card.

As far as I know, the data CRC is a standard CCITT CRC16, but I've never actually done any data CRC encoding or decoding. I have done command CRC7 encoding, and found that they use a little trick - after all the CRC encoding is done, they shift the results left by one and set bit 0, so unless you know to do that, you'll never get the algorithm to work.
crc8 of the quoted post is E7
 

Thread Starter

spinnaker

Joined Oct 29, 2009
7,830
A quick check you can use when reading sectors from a FAT formatted SD card is to look for the DOS signature $55AA as the last two bytes of sector 0. If they show up in bytes 510 and 511 of the result byte array then you're reading the card.

Another thing you could do is use a PC to reformat the card, then write a small text file that contains some distinctive text patterns. Then use your SD read routine to search for the text in the sectors. The text should appear just past all the FAT directory sectors, which should be within probably just a few hundred sectors of the card.

As far as I know, the data CRC is a standard CCITT CRC16, but I've never actually done any data CRC encoding or decoding. I have done command CRC7 encoding, and found that they use a little trick - after all the CRC encoding is done, they shift the results left by one and set bit 0, so unless you know to do that, you'll never get the algorithm to work.
Thanks

I finally got things up and running again. I am indeed reading $55AA in 510 and 511. But I am still seeing the difference in data when compared to reading it with a hex editor on my PC as opposed to reading it with my Pic code. See Post #1.

For example byte 508 of sector #1 is a $CB in the Hex Editor but when I read it from the Pic it is an $04.


On my hex editor all bytes are $00 in sectors 1 and 2 but on the Pic I am seeing a $0F then a $04 about every 7 and 8th byte

Here are the first 100 bytes or so of sector 1 from the pic

Rich (BB code):
sector_buffer            
               [0]                  0x00
               [1]                  0x00
               [2]                  0x00
               [3]                  0x0F
               [4]                  0x04
               [5]                  0x00
               [6]                  0x00
               [7]                  0x00
               [8]                  0x00
               [9]                  0x00
               [10]                 0x00
               [11]                 0x0F
               [12]                 0x04
               [13]                 0x00
               [14]                 0x00
               [15]                 0x00
               [16]                 0x00
               [17]                 0x00
               [18]                 0x00
               [19]                 0x0F
               [20]                 0x04
               [21]                 0x00
               [22]                 0x00
               [23]                 0x00
               [24]                 0x00
               [25]                 0x00
               [26]                 0x00
               [27]                 0x0F
               [28]                 0x04
               [29]                 0x00
               [30]                 0x00
               [31]                 0x00
               [32]                 0x00
               [33]                 0x00
               [34]                 0x00
               [35]                 0x0F
               [36]                 0x04
               [37]                 0x00
               [38]                 0x00
               [39]                 0x00
               [40]                 0x00
               [41]                 0x00
               [42]                 0x00
               [43]                 0x0F
               [44]                 0x04
               [45]                 0x00
               [46]                 0x00
               [47]                 0x00
               [48]                 0x00
               [49]                 0x00
               [50]                 0x00
               [51]                 0x0F
               [52]                 0x04
               [53]                 0x00
               [54]                 0x00
               [55]                 0x00
               [56]                 0x00
               [57]                 0x00
               [58]                 0x00
               [59]                 0x0F
               [60]                 0x04
               [61]                 0x00
               [62]                 0x00
               [63]                 0x00
               [64]                 0x00
               [65]                 0x00
               [66]                 0x00
               [67]                 0x0F
               [68]                 0x04
               [69]                 0x00
               [70]                 0x00
               [71]                 0x00
               [72]                 0x00
               [73]                 0x00
               [74]                 0x00
               [75]                 0x0F
               [76]                 0x04
               [77]                 0x00
               [78]                 0x00
               [79]                 0x00
               [80]                 0x00
               [81]                 0x00
               [82]                 0x00
               [83]                 0x0F
               [84]                 0x04
               [85]                 0x00
               [86]                 0x00
               [87]                 0x00
               [88]                 0x00
               [89]                 0x00
               [90]                 0x00
               [91]                 0x0F
               [92]                 0x04
               [93]                 0x00
               [94]                 0x00
               [95]                 0x00
               [96]                 0x00
               [97]                 0x00
               [98]                 0x00
               [99]                 0x0F
               [100]                0x04
               [101]                0x00
               [102]                0x00
               [103]                0x00
               [104]                0x00
               [105]                0x00
               [106]                0x00
               [107]                0x0F
               [108]                0x04
               [109]                0x00
               [110]                0x00
               [111]                0x00
               [112]                0x00
               [113]                0x00
               [114]                0x00
               [115]                0x0F
               [116]                0x04
               [117]                0x00
               [118]                0x00
               [119]                0x00
               [120]                0x00
               [121]                0x00
               [122]                0x00
               [123]                0x0F
               [124]                0x04
This is pretty much confirmed by what I am seeing on my logic analyzer so it is the response of the SD chip and not how I am reading the SPI.

Here is an overview of the two "problem" bytes.




Here is a closeup of the $0F byte.






Here is a closeup of the $04 byte




Also I seem to need to read 3 additional bytes after the 512 block and 2 crc bytes to get every other sector to read correctly.
 

Attachments

thatoneguy

Joined Feb 19, 2009
6,359
I'd post your logic analyzer shots of it there, in addition to the fact you are using a direct wired SD card only, and not trying to hack a reader from an MP3 player.

Also, that thread is from 2007, you might get better luck starting a new thread.
 

Thread Starter

spinnaker

Joined Oct 29, 2009
7,830
I finally am reading the SD chip without those crazy $F0 $04 bytes. Turns out it was the SD chip.

But it gets stranger. When I read sector 0, among other text I am seeing Invalid partition table Error loading operating system Missing operating system

in sector 0

But when I use the HexEditor on the PC I dod not see Invalid in sector zero. In fact if the search is working properly, the word Invalid is no where to be found anywhere on the SD chip.
 

Thread Starter

spinnaker

Joined Oct 29, 2009
7,830
Strange 2 different chips now with those strange $0f $04 bytes.

I can't see how I can have the same exact issue with 2 different chips if the fault is in the chips. It must be the code.
 

thatoneguy

Joined Feb 19, 2009
6,359
The "Invalid Sector" would be an OS message, like the card isn't responding correctly.

I'd try another card, $5, I'd also try a different card reader, that's one common thing that hasn't changed either.
 
Top