I thought I would be all clever and throw in a hardware SPI master into the latest CPLD VHDL code. Prior to this, I bit-banged the SPI via a set of I/O bits in a CPLD register. The bit-banging was fine, but I wanted to unburden the CPU from all of this twiddling as well as increase the transfer rate with the SD card. So, I cast about on the intarwebs and found a very lightweight SPI master implemen ted in VHDL. Remember, this is a CPLD, not an FPGA, so lightweight is really important. I removed all the register-controlled I/O bits and integrated the SPI master.  Simulated fine. Worked fine on the PCB, even. What it doesn't do, however, is its intended function -- talk to the SD card!

I can't init the SD card.  I think I know why. I wanted the SPI clock rate to be fast - faster than I could bit-bang - so it ended up being 3 Mbps (a function of the 24 MHz system oscillator). Big deal, right? SD cards work with clock rates into the 10's of MHz, so what's the problem? It all gets back to how the SD card is being used. The SD card SPI mode is a legacy mode, not the native mode, and so a special initialization dance needs to be done on the SD card I/O to get it to switch modes. Briefly, clock in  at least 74 pulses with the CS line negated. That's not a typical SPI transfer, but that's just the point: this is a special action. What I overlooked, it seems, is that another requirement of the init dance is that the clock rate is between 100 and 400 kbps. Oops. My SPI port is twerking at 3Mbps while the SD card is looking for a 400kbps slow-dance partner.

So, I'll either throw in a bit to dump the SPI clock rate down by a factor of 8, or else I'll add some provision to manually toggle the CLK line to the SD card. I think the former is the most prudent path, and I hope that I've got enough macrocells left in the CPLD to squeeze this in. I'll write later as to whether or not this fixes the issue.