Occasionally the first byte of data from an SD card SPI read is bad

Question

The device I am developing is an SD card storage add-on to a retro computer, SanDisk Ultra II 1.0 GB SD card in an SD card socket (I have no idea if the brand is significant, it just happens to be what I have).

The SD card is the only device on the SPI bus; a level shifter ensures the card is fed signals at 3.3 V; MISO feeds via bus-switch to a 3.3 V FPGA. The FPGA implements a clocked shift register mechanism, which clocks eight times, shifting out output data to MOSI and capturing input data from MISO.

Many devices attached to many computers work fine.

I use SPI mode. I initalise the card, speed it up to 4 MHz, and send the read single block command.

I observe that first data byte returned occasionally has a one-bit corruption. Typically bit 0 is set when shouldn't be, but I have also seen bit 1 set when it shouldn't be. All other bytes are perfectly correct, always.

Multiple devices were tested attaching to multiple host computers. The problem was only seen with one device attaching to one computer. The device or computer works fine with other computers or devices.

I suspected timing errors in my driver code, but I am sure I have done the eight clock cycles (sending 0xFF, reading first data byte) before I read it.

I'm wondering, could this be related to voltage or current levels, which might be subtly different depending on device or computer?

I'm wondering, does an SD card suddenly need to draw extra current, just as it starts to output data?

Answer 1

Analysis with a cheap USB logic analyzer sampling at 16MHz showed that occasionally there appeared to be only 7 clock cycles grouped together. From the hardware VHDL, I know this to be impossible - once a byte transfer is started, it will exchange bits on the following 8 clocks.

I theorized that there was noise on the SCLK signal, causing a clock that was too fast to see by the analyzer, and too fast for the computer to pick up on, but that the SD Card did actually exchange a bit on.

So I added deglitching logic to the source of the SCLK signal, and the problem has gone away.

Side note: The host computer is a retro computer running at 4MHz. a certain amount of noise on the clock probably isn't visible to most of the components in that computer, but to my modern FPGA based add-on (which can easily run designs with fMax > 50MHz) such things suddenly become an issue.

Thanks to those who have responded.