Can you spot the difference in the picture below?

The one on the left (without edge cut) uses a T125A, the one on the right (with edge cut) uses an LC125A. World of difference.

Overview: SPI interfaces should have the MOSI, MISO and CLK signals in common. Each device gets it's own CS line. Drive CS low on a particular device and it starts reading the CLK and MOSI lines, and responding on the MISO line when appropriate. When all devices' CS lines are high (disabled), the MISO line should be pulled up with a 10K resistor or some such, but otherwise float. No devices should drive MISO when they are disabled!

Except for SD cards apparently.

Resources: After re-re-reading the Elm-Chan SD card page again (here http://elm-chan.org/docs/mmc/mmc_e.html), I found a little quote I forgot to read: "Therefore to make MMC/SDC release the MISO line, the master device needs to send a byte after the CS signal is deasserted." Hm. And then I went back to George Foot's SD card page again (here https://github.com/gfoot/sdcard6502), and found this quote: "But in many circumstances, the SD card will continue to drive MISO even when CS is high (i.e. deselected). This interferes with other devices that might be sharing that data pin."

Testing: For months now, I've been using the MicroSD card adapter on the left. And had NEVER NOTICED this behavior. Ever. But on my most recent board, I used the MicroSD card adapter on the right, and it was very screwy. It does continue to drive the MISO line even when CS is high, but Elm-Chan is right in that 8 clock pulses and that's no longer the case... mostly. This particular MicroSD card adapter stopped driving the MISO line high, but started to toggle between high and low at near random it seemed. It wasn't floating, it would drive it (at least) low for some time, like a second or so between changes.

Then I would have another SPI device try to drive the MISO line, and I got: A) all $FF's, B) corrupted data, or C) good data. It was nearly random, as long as I pulsed that clock 8 times before it would *try* to work, but would only work sometimes. If I popped the SDcard out of the socket (but kept the adapter on board), it would work again... mostly. I think it would permanently drive the signal low or something, but not hard enough to force other devices off the line. Very strange activity.

Conclusion: Not all MicroSD card adapters are the same! The one of the left, using the T125A, seems to make the SD card act like an actual SPI device, releasing the MISO line when not in use (as *should* be expected). The one on the right, using the LC125A, continues to drive the MISO line as Elm-Chan and George Foot both have also witnessed.

Ponderings: So, was I just lucky in getting a 'better' version at first? Or should an SPI adapter be expected to act like an actual SPI device?

So, the research has been done. Hope that was helpful! Thanks everyone.

Chad

The key is that SD cards do not have an SPI interface. They have an SD card interface, which has an SPI mode. It sounds like a pedantic difference, but it's an important one. They power-up in SD mode and have to be told to switch to SPI mode if that's what you want to use. Until they're in SPI mode, you can't assume they'll behave like SPI devices.

Switching to SPI mode appears to be a matter of sending the command CMD0 while holding the pin that SPI calls /CS low. SPI mode doesn't use CRC, and works with 8 bits at a time, so it looks like holding the data line low and toggling the clock 8 times will do it. I use SD mode so I'm not clear on the details.

Interesting. I tried various commands to make the thing behave better, but I'm finding that the adapter itself is different. I see what you say about SD cards not really being SPI, but I would have *figured* the adapter would have made everything neat and tidy.

Anyways, I found a solution using 2x PN2222A transistors and 1x 3.3K ohm resistor. Attached is a picture. Basically I'm inverting the /CS line, and using the inverted signal to (essentially) tri-state the MISO line. I am having no problems with any other SPI devices that are plugged into the system now. The old adapter works great, the new one works... mostly. It has been sending an error on the first attempt to start every time, so I just told it to 'try twice' and it works fine now. Silly way of doing it, but hey, it works.

Whelp, there is my full analysis. You now have the problem, and the solution. Thanks!

Chad

Yes as you saw, I had the same problem. It occurs even in SPI mode, it's not only when in SD mode.

I also found that activity on the clock line due to other devices was confusing the SD card, even when it was not selected. I think I fixed that using some diodes and a resistor to make the SD module's MOSI line always high when the module is not selected, but ultimately just put it on its own bus with nothing else to share with.

I haven't looked in detail at what the components on the modules do but I guess the IC is a level shifter and perhaps the two modules use different parts with one of them not supporting tristating the bus?

Regarding the startup issue, I suspect the card is just in a dodgy state, possibly again due to it paying attention to the clock even when not selected. As there's no framing in the protocol I'm not sure exactly how it decides where the start of each byte is, possibly it is somehow getting out of sync and retrying is getting it back in sync. I have only seen this sort of thing when I reset the computer during a data transfer, as the card is still trying to complete the transfer and not expecting to receive commands yet.

In SPI mode, the assertion of CS marks a byte boundary. Also, the clock polarity is expected to be the same on assertion and deassertion of CS (a.k.a. 'mode 0' and 'mode 3'). So, in SPI mode at least, after (re)asserting CS, bit 7 is expected, always.