Actually, most of the info/code you may find on SD initialization is either dated or innacurate, since it predates SDHC & SDXC by years. The procedure is more complicated nowadays, as it forces you to deal with old hardware in a backwards-compatible way.
Firstly, as mentioned by others, select a low initial clock rate (generally in the 100 kHz - 400 kHz range; use 400 kHz if possible); you'll be able to switch to higher clock later on, if the device allows for it. While new cards can safely withstand MHz-ish clocking, older will complain (i.e. not communicate or return garbage).
Next thing is that you shouldn't use
CMD1 to initialize SD/SDHC/SDXC cards unless your card doesn't recognize
ACMD41; as said in the SD Card specification:
In any of the cases CMD1 is not recommended because it may be difficult for the host to distinguish between MultiMediaCard and SD Memory Card.
Some controllers (newer and higher capacity cards mostly) will simply stay in IDLE if you issue
CMD1 to them.
You should first issue
CMD8 0x1AA after the reset (
CMD0), and then try to use
CMD55 + ACMD41. If and only if that fails, use
tl;dr to initialize the card in SPI mode you should:
0x01) - note that in case of
0xFF or garbled response you should simply repeat this step; see below for more info.
0x01, followed by echo of arg, in this case
0x000001AA) - while it may seem that this command is optional, it's completely mandatory for newer cards. While
0x1AA is a common arg value here, you may actually pass other values as well; see "Table 7-5: Card Operation for CMD8 in SPI Mode", p. 108 in spec for details.
0x0, CRC: any,
0x65 actually (response:
CMD55 being the prefix to every
ACMD; if the response is
0x05, you've got an old card - repeat
CMD1 with arg
0xF9] instead of
ACMD41 , arg:
0x40000000, CRC: any,
0x77 actually (note that this argument assumes the card is a HCS one, which is usually the case; use
0x0 arg [CRC
0xE5] for older cards). If response is
0x0, you're OK; if it's
0x01, goto 3a; if it's
0x05, see note on it above (in 3a.); if it's neither, something's wrong with it (also see below).
Most cards require steps 3a/3b (or
CMD1 for old cards) to be repeated, usually at least once, even if you wait some time between them; i.e. the actual sequence is
CMD1) - to be sure, try the
CMD1 if you got
0x05 from them) \$n\$ times (select \$n\$ within your reason; it's actually quite common to have to wait a couple hundred ms if the device is just after the power on, so aim for that), with small delays between the tries if you wish, and assume fail if response
0 doesn't appear (i.e. if the device stays in IDLE mode for some reason). Also, receiving
CMD0 is common if a device was in some "strange" state previously (e.g. hung up, got S̲S̲ deasserted [high], had over-/undervoltage on some pins etc.) - just give it some time, rinse and repeat \$n\$ times. A garbled response to
CMD0 is quite OK sometimes - if you sent it a couple of times and the response is still neither
0x01, try to go forward with
CMD8. If it works - you're good to go; if it doesn't - it's probably broken.
Note that responses that have the MSB set but ain't
0xFF usually suggest that your SPI got a shift in clocking (as a result of e.g. Vcc drop, which happens routinely when you're doing SD hotplugs). To fix it, you can try to completely reset the device (power on/off, deassert/assert S̲S̲ etc.); it usually works.
Also, the spec says
After the last SD Memory Card bus transaction, the host is required, to provide 8 (eight) clock cycles for the card to complete the operation before shutting down the clock.
It could work without it, but since 8 cycles = 1 SPI output byte, it won't hurt much and it's just good to have it.
Note that you should assert S̲S̲ (aka CS) low at least before and after each
CMD - it's completely mandatory in case of
CMD0 (the device won't turn on without it) and, in reality, required for all other
CMDs if you have a standards-compliant SD card. Connecting the card's S̲S̲ to GND permanently may seem to be a good idea if the card is the only SPI client your host will ever connect to, as it would save you both the uC output pin & the need to manage it by code at all, and because the card should assume it's selected all of the time. In reality, some cards (if not most of them) actually expect a high-to-low slope to turn on instead of simply detecting low, and thus get angry if you don't toggle the S̲S̲ bit at all, and then either lag clocks or spit garbage; some (usually newer) cards should work, some (older) may not, YMMV (yet again). Still, for any more robust SPI configuration (>1 slave device) remember to assert the pin low before any actual transaction with the given SD card.
Besides, while the spec says that only
CMD8 should have CRC in SPI mode, some SD cards (like Transcend ones) seem to require proper CRC for
ACMD41 - if you want to be on the safe side, simply use a precalculated value for them.
Also, while SPI doesn't require pullups/downs by itself, throwing a 47k pullup on MISO may be a good idea; some devices leave their DO pin high-Z under specific circumstances (not initialized e.g.), and floating pins can always be a source of strange problems. If your uC has 3.3 Vcc, you may use internal pullups; if it's 5V, don't do that unless your MISO line has a proper 5->3.3V logic translation already.
How To Use MMC/SDC
Part 1 Simplified
Simplified Specification - most importantly sections 6.4.1 Power up and 7.2.1 Mode Selection and Initialization with Figure 7-1: SD Memory Card State Diagram (SPI mode)