SD card SPI fun, week ending June 22, 2014

DISK DRIVE EMULATION

I had to dig into research on the SD card use of SPI protocol because my first shots at accessing the card directly without use of an SPI library did not go well. As stated in earlier blog posts, when the library is used, my attempts to communicate with other SPI slaves, especially my fpga, suffered various impacts that appeared to stem from the library leaving the SPI hardware of the Arduino in an odd state but could also be interference by the SD card shield itself.

I discovered quite a few things about SD cards that reinforce my original desire to have independent SPI links for this unit, although that was frustrated by lack of any Arduino card that carries the essential clock line for the three other USART units out to a pin that I could access. Without the clock signal, SPI won't work well, so the USART, a facility that is a combination of serial port and SPI, in fact can only be a serial port (UART) on these boards.

SD cards must be 'woken up' by a string of clock cycles while the inbound (MOSI) and selection signal (SS) are held high. Since SS is high when the slave is NOT being selected, this violates the intent of the SPI protocol for shared slaves since a slave should ignore the signal lines unless its SS line is taken low. It takes 74 or more clock cycles to wake up the chip, putting it in its native, non-SPI mode. I don't yet know how long a period causes it to 'go to sleep' where it needs the initialization again, hopefully that doesn't happen once it is initialized in SPI mode.

Another oddity is that the SD card does not release the outbound (MISO) signal when SS is returned to high, violating the SPI specification. It takes another eight clock cycles before the card releases MISO to its high impedance state. This definitely hoses up any other slave, legitimately selected, that tries to send its data on the shared MISO line.

Finally, I don't know what state the MISO line takes when the SD card is in its native, non-SPI mode. Since any string of 74 or more '1's on MOSI will do this when another slave is active and SD has its select high, I can imagine this could be another source of problems.

I will continue a bit with my direct, non-library access to the SD card, where I might be able to control some of these anomalous effects, but if the card resets based on the data pattern from other slaves on the chip, I need to isolate the SD card from the MOSI line until it is actually being accessed. This would require a second selection signal, a kind of meta-SS, that switches MOSI and SCLK so the card won't see these until I turn on the meta-selection signal. It means additional hardware and some signal rerouting for my growing sandwich of Arduino and shields.

I think that the first USART, used for serial communications over the USB link and for flash programming of the Arduino, can be used as an SPI link. It would be very inconvenient as I use the serial link for the operator interface as well as for debugging purposes, but if the USART clock is accessible for that mechanism, it would at least allow me to isolate the SD card from the rest of the slave devices, using the SPI library for the card and the other link for well behaved slaves. I might need to use another USART for a direct serial connection in pseudo RS232 mode (TTL logic levels but RS232 protocols).

It will be easier to block the SCLK signal from the SD card unless some meta-SS is on for the SD card. I have spare enable gates on a 74HC125 on one of the shields. I began to modify the shield for the controls and to alter the Arduino code to enable/disable the clock passthrough buffer.

In addition, I recoded the relevant part of the SD card handling routines to conform to the way that the SD card actually works and to use of the new meta-select signal. I also worked on the code so that it handles fpga and ram slave devices per the SPI spec.

DIGITAL GAME MUSEUM WORK

I did some repair work on the four metal floor controllers for the Dance Dance Revolution game, as most have one or more positions that don't work reliably. This will be the core of the DGM exhibition at an upcoming Japanese culture fair. I began to check the condition and failure causes so that I can get these working well.

No comments:

Post a Comment