SD and MMC cards support SPI (serial peripheral Interface). Since most microcontrollers have a dedicated SPI module, hardware development is negligible. The card requires a filtered power supply of 3.3V.
The easiest way to connect an SD card to an embedded system is to use a commercial SD/MMC card socket. The connector has surface mount type contacts that can be soldered using a fine soldering iron. A quicker alternative is to use a micro SD card and solder a connector to the contacts of a micro SD adapter. It should be remembered that there is a mechanical write-protect (WP) switch on SD cards – this switch has absolutely no connection with the internal workings of the card. It is the responsibility of the host to check the state of the WP switch using some mechanical arrangement before writing any data to the card. Most commercially available card sockets have mechanical systems to detect the position of the WP switch and also to detect the presence of the card.
SD/MMC cards require a supply voltage of 2.7 to 3.6V at 200mA (max). This can be derived from a linear regulator such as the LM317. However, many devices such as LCD panels, motor controllers and RS-232 devices require 5V levels for proper operation, which requires that the controller be powered by a 5V supply. Since the card is not 5V tolerant, some level translation is essential. The quickest way is to use a resistive potential divider on the MOSI SCK and /CS lines. The circuit used for testing is identical to the one given here. The MISO line from the card can be wired directly to the controller, but care should be taken to ensure that the controller does not drive the MISO pin at any time.
Since the AVR microcontroller is usually programmed via the SPI interface some clarification is in order. During programming, the programmer holds the reset pin of the microcontroller low. This puts all I/O pins in the hi-Z state, which causes the card to get deselected (\CS not pulled low) and the card ignores all SPI activity. This was observed with all three micro-SD cards used during testing, but has not been verified for MMC cards. Series resistances on the ISP (In System Programming) lines are a good practice.
All SD cards support data rates of 25 Mbit/s (20 Mbit/s for MMC). These translate into SPI clock speeds of 25 MHz and 20MHz. (Exception: During the initialisation procedure, MMC cards only support clock speeds of up to 400 kHz) Since the ATmega16 is used at a maximum clock frequency of 16MHz, the SPI clock can be used at a maximum of 8 MHz, in double speed mode (SPI2X=1; see datasheet). Without an external clock source, the maximum SPI data rate is 4 MHz (Internal 8 MHz RC Oscillator as clock source).
The SPI module is used entirely in the single master mode (the ATmega16 is always the master). The SPI master has complete control of all SPI data transactions since it controls the SPI clock line. Essentially, for each SPI transaction, the master and slave EXCHANGE exactly one byte (Read SPI basics before proceeding further if this statement is not completely clear). Thus, if the controller is expecting N bytes from the slave, the master must send N (‘dummy’) bytes to the slave and watch the bytes received in return. For the SD card, the dummy byte is always 0xFF.
The SD/MMC cards support two communication modes – SD/MMC modes, and SPI mode. Only SPI mode is discussed here. The SD/MMC card behaves like an SPI slave device. All communication consists of commands sent by the host to the card and the corresponding responses sent back by the card. The number of bytes in each ‘packet’ is always deterministic.
The host issues commands to the card for various functions. Each command, without exception, is 6 bytes long. After the card receives and processes the command, it sends back a response. The number of bytes in the response is uniquely related to the command. The first byte of the command is called the command index. This tells the card ‘what to do’. The following 4 bytes of the command are a 32 bit argument. The most significant byte of the argument is sent first. For commands that do not have an argument this field is padded with a dummy value. The last byte is a CRC (checksum [*]), used for error detection. The card responds to each command with a predefined response. Responses are of types R1, R1b, R2, and R3.
R1 is exactly 8 bits long. Each of the 8 bits is indicative of a particular status. The R1b is exactly like the R1 response, and is followed by a busy bit (0 when busy and 1 when not); which indicates that the card is busy executing the last command. The R2 response is a set of two bytes sent in response to the SEND_STATUS command, and contains 16 status bits. The first eight of these are identical to the R1 response. The card generates a 5-byte long R3 type in response to a read OCR command. The first byte contains the same information as the R1 response. The remaining 4 bytes are the 32-bit Operating Conditions Register (OCR).
During read or write commands, there is an additional data payload to be transferred. This data is always preceded by a data token (single byte, value 0xFE). The data payload can have N bytes where 1≤N ≥MAX_BLOCK_LENGTH Data tokens are used in the transfer of data during read or write commands. All data bytes are transmitted MSB first. Data payloads can have lengths ranging from 4 bytes to (N+3) bytes. (Where N is the number of bytes per data block) The first byte is always a start byte (0xFE for single block read/write), followed by the N data bytes and a 16 bit CRC. The SD/MMC specifications define the typical and absolute maximum processing times for commands. However for simplicity, a single timeout is used for all card communication, with no significant performance penalty.
Here is the complete circuit diagram of the SD/MMC card interface as used for this project.