I have an application where I have a microcontroller (NXP LPC1343) which is connected to an FPGA via 16-bit SPI. There is also an SD card using the same SPI port (MISO/MOSI) but with a different CS/SS pin (both are active low, as per the SPI specification). One of the things I need to do is write data from the FPGA onto a file on the SD Card using FAT32, and this is the job of the microcontroller. The microcontroller is running FatFS, which I have gotten to work reliably by itself.

Because the microcontroller only has a small amount of RAM, only a small amount of data can be buffered at once. Hence, the micro has to read a buffer from the FPGA, change the SPI mode to 8-bit, and then write that data to the FATFS. Recall that in order to configure the SD card for SPI mode, a command must be sent while the SPI bus is running at 400 kHz, and a certain amount of waiting has to happen. Therefore, I would like to have to only perform the initialization once.

However, performing transactions on the FPGA even while holding CS high on the SD card seems to put the SD card into a weird state such that it needs to go through initialization again. This of course is undesirable, since the initialization may take several milliseconds, in order to write just 4 kB or so of data (again limited by the small RAM capability of my micro). As I need to write several megabytes as quickly as possible, this reduces performance from about 500 kB/s to less than 100 kB/s.

I'm aware that SD cards aren't technically fully SPI compliant, but how can this problem be fixed?

  • \$\begingroup\$ It should honour it, as far as I know. Maybe try a different SD card? \$\endgroup\$
    – Marko
    May 8, 2013 at 3:46
  • \$\begingroup\$ This is a great question. Thanks for asking (and answering) it. \$\endgroup\$
    – markrages
    May 8, 2013 at 5:16

1 Answer 1


Okay, I figured it out actually. I should have googled a bit deeper. It turns out that SD cards don't act exactly like SPI devices when sharing a bus according to How to Use MMC/SDC:

In the SPI bus, each slave device is selected with separated CS signals, and plural devices can be attached to an SPI bus. Generic SPI slave device drives/releases its DO signal by CS signal asynchronously to share an SPI bus.

However, MMC/SDC drives/releases DO signal in synchronising to the SCLK. This means there is a possibility of bus conflict with MMC/SDC and any other SPI slaves that attached to an SPI bus. The right image shows the drive/release timing of the MMC/SDC (the DO signal is pulled to 1/2 Vcc to see the bus state). Therefore to make MMC/SDC release DO signal, the master device must send a byte after CS signal is deasserted.

The SD card and FPGA were probably both trying to drive DO and the SD card lost out, so it reset. Sending an extra byte seems to have fixed it.

  • \$\begingroup\$ This allows you to alternate between the FPGA and the card, right? Did you also find that you could interrupt during the data transfer and resume? From what it says on elm-chan, it looks like that's not possible, but I'd be interested to know whether you confirmed or disproved it. \$\endgroup\$
    – krs013
    Jun 16, 2015 at 23:22
  • 1
    \$\begingroup\$ Yes, it does work as expected for alternating between FPGA and SD, but you cannot interrupt the transfer between calls to FatFS. At least I wasn't able to get that working. That means you cannot (for example) respond to an interrupt during a file write and read from a sensor using the shared SPI bus. \$\endgroup\$
    – Zuofu
    Jun 17, 2015 at 16:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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