[SOLVED] SD card SPI conflict

Hi guys and gals,

I have a teensy 3 on hand here interfaced on a board with a SPI bus that has a MCP3911 AFE and a SDHC card. The whole system runs at 3.3V so there are no level translators in use. Power is provided by a stable MCP1702 power supply instead of relying on the voltage regulator inside the teensy chip (disabled). Anyhow, the system is working just fine with just the MCP3911 on the SPI bus. Speaking of which, the bus is running at 8MHz and in Mode0, with MSBFirst.

Both CS lines feature pull-up resistors and behave as one would expect. However, insert a SDHC card and the SPI bus comes to a grinding halt. The Saleae Logic 8 reports a mismatch and the screen indicates no SCK action.The bus doesn't show any MISO action either, just MOSI and CS. My electrical connections should be good since I have used this same card and holder successfully in previous designs and my computer can read and write fine to it. So, I have a couple of questions that I hope folk can answer here.

For one, would a series terminator on the SCK line potentially cause this problem? I'm using a 100 Ohm resistor because the distance from the SCK line (24 mil wide) is much greater than for the other pins on the SPI bus (which do not feature a similar 0805-based resistor).

Is there anything different when it comes to SD cards like maximum SPI bus speeds that one should stay under (it's operating at 8MHz presently). Is SPI0 the proper mode?

Should I consider putting these devices on separate SPI buses (not just use CS-pins) by bitbanging the ADC output?

100? sounds low to me.

I'm not sure, but when I tried to access a SD card and another SPI device I had more luck with bit-banged SPI for the other one (the slower one).

I made up a small bit-banged SPI library if that helps:

Hi Nick,

Thank you so much for your reply. I chose 100 Ohms for the series terminator based on the characteristic impedance that a 2.5" long 24mil-wide trace produces. All the other SPI lines were so short that they were going to be OK either way (i.e. less than 2"). Paul S. also recommended a 100 Ohm resistor for the CLK signal the Teensy 3 is producing for the MCP3911 to reduce potential for EMI issues.

Are conflicts between SD cards and other devices on an SPI bus so common that the cards need to be segregated? In the current incarnation, the idea was to log relevant data once a second to the SD card. The SPI bus is running at 8MHz (the maximum, allowed, it appears). The teensy may or may not be able to bit-bang at up to 12MHz because of the clock-divs that the teensy offers (the maximum frequency that a PWM pin can produce is 12MHz, as best as I can tell).

I am really reluctant to learn / implement how to bit bang, but there doesn't appear to be an alternative. I wonder why the SD card is answering / interfering when its CS-pin is held high by the MCU and features a (belts and suspenders) pull-up (10K) as well.

I don't know for sure, maybe an SD card issue?

You don't have to learn bit-banged SPI, I gave a link to a library already written.

If you are taking readings and writing them to disk, surely speed isn't of the absolute essence? The bit-banged SPI is slower, but writing to disk is slow too.

Hi Nick,

Thank you again for the link - you are correct, your library takes care of just about everything!

I'm at the point where I am going to declare that the Sandisk 2GB MicroSDHC and the MCP3911 simply cannot play nice, no matter how much I do to make them happier. Let me explain what I did to test the conditions, what conclusions I came to. I hope I'm wrong! [EDIT: I was wrong, see below]

So, to test the Teensy 3 by itself, I replicated the Teensy MicroSD shield using a sparkfun part I had. The breakout from Sparkfun does not feature the pullup resistor that Paul put on his breakout (3.3V to MISO) so I added one on the breadboard. Running the SDInfo example yielded a happy card, lots of information - this from the same SD card on the other board being terribly unhappy.

On the other board, I added the missing MISO pullup and another 10uF capacitance for VCC-GND, etc. all to no avail. I am going to double-check my previously-checked pinouts one more time. But if that passes, my next "test" will be to isolate the SD card carrier on the SPI bus (cut the traces continuing on to the MCP3911) and see if that does the trick. If the SD card works fine without the MCP3911 being on the hardware SPI bus, then my inclination will be to use your library for the MCP3911 while leaving the hardware SPI to the SD card.

Seem reasonable? Thank you again!

Sounds good. The other thing you could try would be to build in a delay after asserting SS, maybe it takes a moment for the inactive one to set the MISO line high-impedance, but in any case what you describe sounds like it should work.

How details can come back to bite one in the rear end...

So, tracing the wires going into the SD card holder (and mind you, I chose the Hirose unit because it features exposed pads vs. the many models out there that hide their pads under the metal wrapper) I noted a anomaly. Wires were not where I expected them to be. Long story short, the library part I created for the Hirose had a switched pair of pads (correctly labeled but incorrect location) that lead to 3.3V being swapped with MISO. Yeah, there is a lot of egg on my face. Previous issues with other boards that I was never able to resolve probably came from this very simple little problem.

Anyhow, the MCP3911 team deserves a lot of credit for the analog front end it produced. It is a great chip and anyone contemplating energy measurements with an Arduino ought to consider using it. You get 24 bits of no missing codes, 16 ENOB if you turn on decimation to 2048s/s and so on. I ran a quick test of a tiny transformer output vs. the incoming voltage varying via a variac and the response was not only linear, it matched with a an R^2 of 0.999989 to a linear plot fit. That's pretty good. I have yet to test a current transformer but I doubt the results will be much different.

Anyhow, thank you Nick for your help!

Many SD card holders shorts CS to ground when a card is inserted.

Many SD card holders shorts CS to ground when a card is inserted.

CS as in chip select? They should not - there is a separate Card Detect switch for that (SD anyway, I don't think microSD sockets have that feature). Chip Select should only be under the Master SPI device's control.