SD Card Info

[@rt]

Hi Guys,
When I was using Microchip’s MDDFS library in a project implementing an SD card,
I filled in a few gaps such as retrieving the name of the partition, and card capacity, etc. that was never written into the library.

I’ve since become interested in the SD card’s CID register, which is never accessed by MDDFS library at all,
probably because the info contained it it is not vital to the card’s operation in the way the CSD register is.
In a nutshell. it’s easy to simply duplicate the CSD request routine, and change that to issue CMD10 instead of CMD9.

Something I’ve found interesting is that some cards send no 0xFE token before their reply, and some cards that do send the 0xFE token, also send an 0xFF byte before the token.
So an issue arises where the correct reply has to be aligned to calculate the reply checksum.

So there can be no hard rule to simply wait for 0xFE before reading in the reply (because it may never arrive, or may be part of the actual reply data).
I wonder if anyone has a better way to deal with all replies than my current solution, which is to calculate the checksum from each of a few start offsets, until it’s correct.
Cheers.

[@rt]

Hmm... typing it out, it just occurred to me that a particular card might need a delay between the request, and it’s reply.
Clocking it with SPI just might result in 0xFF (or set bits) before the card has really started sending it’s reply.

[thm_w]

Are you referring to initialization or a normal response timing?
Its possible they are violating spec and need a delay or aren't waiting long enough for a valid response, it helps to have a logic analyzer to check.

The host shall supply power to the card so that the voltage is reached to Vdd_min within 250ms and start to supply at least 74 SD clocks to the SD card with keeping CMD line to high. In case of SPI
mode, CS shall be held to high during 74 clock cycles.

http://users.ece.utexas.edu/~valvano/EE345M/SD_Physical_Layer_Spec.pdf (simple spec)
https://web.archive.org/web/20131115122620/http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Components/General/SDSpec.pdf (full)

[@rt]

Hi,
The initialisation is working. It would only mess up some particular information if the CID register values weren’t parsed properly.
Basically if you send CMD10 to the card, the reply would normally be:

Code: [Select]

0xFE, CID REGISTER CONTENTS, CS.
For some cards it could just be:

Code: [Select]

CID REGISTER CONTENTS, CS.
I have not seen the above, but have seen code that deals with that possibility,
and also mentioned int he source comments.

For Samsung cards in particular (personally tested by me), I get:

Code: [Select]

0xFF, 0xFE, CID REGISTER CONTENTS, CS.

There are plenty of easy ways to deal with it, but it makes me wonder how such cards were introduced,
and existing software that requested the CID register dealt with it.
It makes me consider that I’m doing something wrong, but also suspicious that it’s only a particular brand card.