7

I have a microSD connected to an Arduino and I can't program it over ISP without removing the SD card. Does anybody know how to prevent the SD card from interfering with the ISP programming?

Details:

This is the microSD breakout: https://www.adafruit.com/products/254

I'm using an ATMEGA328P at 3.3V 8MHz.

I'm not using a bootloader and, for several reasons, I can't use the serial port for programming.

Thanks!

mar1980
  • 71
  • 1

2 Answers2

3

Because the SD card is an SPI device it shares the same pins as the ISP interface. The only way to not have the SD card interfere with the ISP is to not have the SD card connected.

As you have seen, that can be achieved by removing the card.

It can also be achieved by adding a tri-state buffer between the MCU and the card so the MCU only connects the card to the SPI bus when it is ready to use it - under default operation the card is disconnected.

Majenko
  • 105,095
  • 5
  • 79
  • 137
  • Would you then need to disable the tristate buffer before programming the MCU? – mar1980 Mar 03 '16 at 23:07
  • The buffer would, if you wired it right, default to off when the MCU stops actively setting it to on. – Majenko Mar 03 '16 at 23:11
  • This sounds great! Thanks for the tip. (Do you have any recommendations for what buffer I should use?) – mar1980 Mar 03 '16 at 23:44
  • You can also use the buffer as your level shifter as an added bonus. Look in the 74hc series for a quad tristate noninverting buffer. – Majenko Mar 03 '16 at 23:47
  • You should not need to disconnect the card - provided programming is being done at a compatible voltage level, inactivating the card's chip select should be sufficient. SPI devices are, after all, designed to share the SCK, MOSI, and MISO signals, and so should not drive MISO when they are not slave selected. – Chris Stratton Mar 04 '16 at 14:11
  • @ChrisStratton there are two flaws in that argument... 1: most cheap card shields lack a pull up on CS, so while you are programming the CS is floating. 2: SD cards aren't 100% SPI compatible. They have times where the CS is held high while being clocked. They are notorious for not always playing well with other devices on the bus - care has to be taken with them. – Majenko Mar 04 '16 at 14:15
  • The poster isn't using a shield, but a PCB wired to something that appears to not be a complete Arduino, adding a resistor (at the wiring interface if nowhere else) is trivial (though it would be with a shield as well). Many SPI devices can continue operation after the select returns high, that's quite different than their driving MISO when it has never, or at least not recently, been low. What could make things tricky would be if the existing sketch kicks off an SPI operation that then gets interrupted by entering programming mode. But your "the only way" opener seems inaccurate. – Chris Stratton Mar 04 '16 at 14:18
  • 1
    @ChrisStratton Yes, many (most) SPI devices keep running with CS raised. No other SPI devices require the clock to be run with CS raised. This is a fundamental difference between SD cards and true SPI devices that is known to cause problems in the field. And then of course you have the fuzziness of what constitutes the SD card SPI interface, implemented differently by different mfrs with many cheap Chinese mfrs cutting corners, etc. I have seen some SD cards that even never tri-state their MISO pin. As a general rule of thumb I always put SD cards on their own dedicated SPI channel. – Majenko Mar 04 '16 at 14:53
  • 1
    That's useful detail - your answer would be a lot better if its actual body included this explanation of why you recommend handling an SD card uniquely, as opposed to as an ordinary SPI device. – Chris Stratton Mar 04 '16 at 23:19
1

I had the exact same problem, also using Arduino (Atmega 328P). I have an sd card module with a different layout, but also with a level shifter. My circuit is running at 5V (which is appropriate when using a level shifter).

enter image description here

To resolve the issue I just installed a pullup resistor (10k) on my own board to the chip select line of the sd module, which keeps the sd card unselected while programming the MCU. Now it works.

enter image description here

There seems to be no pullup integrated into the module. Hence the CS is low during programming (without the pullup), the sd card thinks it should answer the SPI commands, and so interferes with the communication to the MCU, which is why programming over an ISP fails.

oliver
  • 175
  • 7