3
\$\begingroup\$

I am trying to interface an microSD card to a microcontroller board (FRDM-KE06Z) using FatFS code. I only modified SPI parts for my application. Besides digging into FatFS code also I checked this guide

When I send CMD0 to the card the reply is correct: response to CMD0

But when I send CMD8 to identify the card the response is totally wrong (after 0xFF there should be anything with MSB set to zero): response to CMD8

I have checked:

  1. Different SPI modes 0/1/2/3, clock speeds 75kHz and 150kHz
  2. Two different SD cards (brand new 32GB SanDisk Ultra HC 1 and an old SanDisk 2GB)
  3. I do send dummy clock cycles after power, I also wait a couple of seconds before doing anything with the card
  4. Wiring is short, so signal integrity should not be the problem
  5. The same happens with and without logic analyzer attached
  6. Plugging the card after MCU pins are initialized, waiting a couple of seconds and starting the code
  7. CS timing is very relaxed (couple of miliseconds before data is sent, many miliseconds between CMD0 and CMD8)

What can be the reason my cards are failing to properly respond to CMD8, while responding correctly to CMD0?

\$\endgroup\$
  • \$\begingroup\$ What do you use to view the waveform? It looks really nice! \$\endgroup\$ – krismath May 21 '17 at 18:49
  • 1
    \$\begingroup\$ DSLogic dreamsourcelab.com/dslogic.html \$\endgroup\$ – filo May 21 '17 at 19:33
1
\$\begingroup\$

I was designing FPGA configuration and writing driver for SD-card a year or so ago, and caught very similar set of issues. My solutions to wrong responses / misbehave of SD-card was simple:

  • when you end command, you do not stop clock just after command completion, you keep supplying clock for 8 or 16 spare cycles - with CS being active or inactive. I think I supply 8 when CS is still active, and another 8 after it deactivates;
  • when you start command, you do the same as above - before activating CS you supply 8 spare clocks, after you activate CS you also supply 8 spare clocks and only then start the command, which is then sensed by octet's first bit being 0 (command start bit).

The clock signal is required for card to complete some its internal operations (the most obvious example is recovering from the data/command error). If your design would supply clock without interruptions you would not catch this issue.

Update: looking to your waveforms supplied I think you should have MOSI being high when CS is not activated and when command is not in progress. Look here, you may find it useful (however not sufficient) to design the SD-card interface.

\$\endgroup\$
  • \$\begingroup\$ What the hell? IT WORKED! I send 5 dummy bytes with CS high before sending CMD8 and now I got the correct reply. I think I will do it before or after every command. Is this behavior documented anywhere is the ~250 pages long simplified SD spec? I hoped that if a card has a powerful controller inside at least it will have its own clock to do housekeeping. \$\endgroup\$ – filo May 6 '17 at 16:00
  • \$\begingroup\$ I found several mentions of this in the net, but not as explicit knowledge. When designing the stuff, I used SD spec, used two datasheets for specific cards (one from Samsung and another do not remember), some info from already existing implementations using MCUs, and that one by Elm-Chan. And my reaction was very similar to yours when it started working - "what the hell!" :) \$\endgroup\$ – Anonymous May 6 '17 at 16:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.