Technology moves fast, only 18 months ago, the 1GB SD card was very easy and affordable to purchase. Today, they’re like hen’s teeth, where the 2GB SD card has taken over this position in the market, of course a doubling of which “Mr Moore” would be happy with.
Thus, It’s only natural to project that, in 12 – 18 months time, the 2GB SD card will be difficult to source, leaving the consumer only able to purchase the 4Gb SD Card and above with any ease.
This is all good for the consumer of course, as they are getting more bang for their buck. But, for the designer it raises it’s own set of unique technical hurdles to cross.
As technology moves on, as do the specifications which devices operate under. Moving from a 1GB legacy SD card to either a more modern 1GB Card (If you can source one!) or a larger device, requires that firmware support a different SD Card Specification be written.
In this first blog, I will deal with the differences in Initialisation of SD cards under the different Specification revisions.
The v1.01 SD Card specification was written in 2001, the v1.1 spec was introduced in 2006, with the v2 spec was introduced later that year. Following the introduction of the SDHC and SDXC formats in 2010 came v3 of the specification.
With these changes, come semantic differences in the operation of the devices.
SD Spec V1 Initialisation:
Below is the initialisation flowchart for SD Cards conforming to V1 of the SD Card Specification; (Click to enlarge)
It can be seen that, from an Idle State the Host sends the CMD0 Command – “Go Idle” while holding the Chip Select pin Low. This command resets all connected SD cards to their Idle state, effectively it is a Reset command. Holding the CS pin Low forces the card into SPI mode, which is how this design is operated.
As a point of note, almost all commands sent to the SD card will be responded to with the R1 response. This response contains a set of bytes which indicate the devices status; Busy, Idle, Error, Card Locked, CRC error and a host of other status Bits.
Following CMD0, the SD card will be in it’s Idle state, from here the host may read the Operating conditions Register, or OCR, using CMD58. The SD card responds to this command with the contents of the OCR, allowing the host to ascertain such parameters as the cards operating voltage range etc. This allows the host to reject incompatible cards from the outset.
The next command can be either CMD1 or ACMD41, in my original design, for simplicity’s sake, CMD1 was chosen here.
CMD1 – “Send Op Cond”, puts the SD card into it’s Initialisation State. The SD card will respond with the standard R1 response, which contains the devices' status. The host must wait for the device to signal that it is Idle, that is the R1 response is 0x00.
At this point the device is ready to use normally.
SD Spec V2 Initialisation:
We now move onto v2 of the SD Specification, and the initialisation has changed to the following; (Click to enlarge)
We can now see that the Initialisation sequence has become somewhat more involved.
With the introduction of the V2 SD Card Specification, the Host now needs to determine which specification the connected device conforms to. This is accomplished with the addition of the CMD8 Command – “Send Interface Condition”. The host must include this along with this command a parameter which defines the voltage range it allows.
Upon reception of this command, the device will send the R7 response. This response contains the devices accepted operating voltage range.
The host at this point waits for the the R7 response, meaning the device is both V2 Spec compliant and also can operate at the given voltage range. If either fail, it can then peruse alternative options for communicating with the device, or rejecting the device completely.
If the R7 response is correctly received, then the Host must now determine whether the device is a standard format SD card or the newer and larger SDHC format.
As the devices have grown, in order to maintain backward compatibility, it has become necessary for the host system to determine which “size” of device is connected.
This process is accomplished by the host, via the use of the “Send Op Cond” (ACMD41) command. By supplying the High Capacity Support (HCS) bit, the Host can inform the connected SD card as to whether the host itself can support the High Capacity Card format.
As a note, the ACMD41 command is actually a combination of two separate commands, the “Application Command” (CMD55), and the “Send Op Cond Command” (ACMD41). CMD55 instructs the SD card that the next command is an Application Specific command, thus ACMD41 must be proceeded with CMD55.
In order initialise v2 onwards compliant devices, the above process is carried out. To simplify matters, the process can be used for v2 compliant, standard SD cards as well as SDHC, where the CCS bit in the response to ACMD41 is used to determine which type of card is connected.
Further, the specification requires that the sequence CMD55 + ACMD41 must be repeated for at least 1 second at power up in order to initialise the SD card correctly.
I must note however, that I have found by trial and error that, in order to properly initialise the SD Card and determine it’s Card Capacity, it is necessary to add a CMD55 – “Read OCR” command to the ACMD41 sequence. I’m not sure at this time why this is, but once I’ll know I shall update this blog to reflect my new knowledge!
Once this process is complete the SD Card is then ready for use.
SD Spec V3 Initialisation:
The v3 SD Specification shows the following for the Initialisation Sequence; (Click to enlarge)
I have included the above sequence for completeness however, it is almost the same as the V2 Initialisation sequence. It is however clear to see the progression of complexity, along with the increase in technical specs of the devices has had an impact upon how these devices are initialised.
In my next blog I will be dealing with the differences in Data Access mode commands, and it’s effects upon the host firmware.
No comments:
Post a Comment