PIC32 SD card and SPI

[kyrk.5]

Hi,

I struggle with an SD cards since some days long. Actually some kind of problem pops always up when I have to do some work with an SD card. Seems like every SD Card is just like a little bit different.

In the current situation I use PIC32-PINGUINO-OTG and an MP3 shield with a VS1053 chip. The shield is also having an SD card connector. Some months ago I used this setup and it was working fine. Actually now I am wondering how this was even be possible.... But that SD card is long gone, since then, I bought a new one. With this one my old project did not want to work. Until now I tried not to fully and deeply understand the inside of the SD-SPI protocol. But with the problems now, I was forced to dig deeper and deeper in the protocol. So here is my question and problem:

Is it possible to share the SPI between an SD Card and an other SPI device? As per my understand of the SPI it should be generally possible as long as each chip gets its own Chip Select. But now comes the SPI protocol and tells (http://www.dejazzer.com/ee379/lecture_notes/lec12_sd_card.pdf):
"To communicate with the SD card, your program has to place the SD card into the SPI mode. To do this, set the MOSI and CS lines to logic value 1 and toggle SD CLK for at least 74 cycles. After the 74 cycles (or more) have occurred, your program should set the CS line to 0 and send the command CMD0:
01 000000 00000000 00000000 00000000 00000000 1001010 1"
OK, but this means that an other SPI device might reset the SD card. Or if the SD card was not implemented very carefully, it might react to even clock and CS high? So how is it possible to have even more then one SD card on a SPI bus? Or a SD card and any kind of other chip?

Every design on the internet is suggesting that the SPI can be shared. Even Olimex design, since the UEXT is using the same SPI (at least on some of the PIC32 boards) as the SD-Card. And the MP3 shield also shares the SPI between the VS1053 and SD card. But I think it is not possible this way. The SD Card should have some kind of circuit that can disconnect it from the SPI bus, for this an extra line is needed since it must be possible to drive CLK and MOSI when CS is high.
Other solution would be to use different SPI bus for the on PCB SD Card and the UEXT and the Shield connection.

An SD Card can be controlled over the 4bit interface. Sadly on the PIC32-PINGUINO-OTG only the SPI pins are connected. I think it would be a good idea to connect also the other PINs too, to enable 4 bit interfacing. Once I tried a bit bang 4 bit interface, sadly it was only 10% faster then an SPI. Considering that the Microchip SD Card driver is more or less synchronous it does not give any performance penalty. But maybe an SQI could boost the performance, not sure.

[Lurch]

You might want to look at this: https://www.bigmessowires.com/2016/01/30/sd-card-spi-initialization/

[kyrk.5]

Hi,

thank you for the link. It confirmed me about the problem, that some of the SDcards need a little bit special attention

There is a suggested workaround like initialize the SDcard first then everyting else. However, SDcard might be hot attached, then it is quite hard to implement this workaroud. Also in my case the SDcard got initialized well and file reading is started, then after some read operation a different SPI device is beeing communicated which affect the SDcard bad. In this case the suggested workaround is already effective but is not helping

The safest design would be to either make sure the SPI bus can be separated for the SDcard or the SDcard should get its own SPI bus. Sharing it with UEXT or Shield would lead to sometimes working sometimes not working SDcards.

[Lurch]

Not much you can change on the Pinguino. A tri-state buffer switched by the /CS would have helped, since it essentially disconnects the bus from the sdcard when not selected.
You might also want to check which spi mode is being used. Some cards works well with mode 1, but most external devices use mode 0. Or try to add a tri-state buffer chip to the spi lines on your external board.

[kyrk.5]

A tri-state buffer on the /CS is not a good idea. Since at reset there is a command where CS must be high. So the tri-state must be controlled with a separate line.

I am unsure about if SD Cards really needs different modes. As per my understanding they need different modes during init and normal run. And the microchip driver already had this switching implemented.

I have noticed that the board PIC32-HMZ144 is already using different SPI busses for UEXT and SD Card