SPI communication

Question

I am using TI's DSP 28335 to read data sensors using I2C, and SPI to send this data further to the FPGA. The device is set to use SPI in the slave mode with 8-bit data words, and I use interrupts.

I have read SPI wiki page, and various other documents (including TI's reference page for SPI), but I haven't understood the SPI communication.

So, the questions are :

1. Is the slave device receiving all the time while the SS (slave select) is low?
2. does the TX FIFO buffer always needs to be non-empty when SS is low? I have noticed that when TX FIFO buffer gets empty, some garbage is sent^*.
3. If the answer to 2. is yes, how to prevent it? Is setting MOSI to high impedance enough (by setting the TALK flag to 0)?

---

^{* Under garbage, I mean whatever is in LSB. Since I set data word size to be 8 bit, I expected the DSP to send only 8-bit data words from the SPIDAT register.}

Answer 1

Yes, the slave will keep shifting one data bit in and out on each clock pulse as long as SS is low. When SS goes high the data which is in the shift register at that time will be latched.

A FIFO never needs to be full. It will accept a new byte of data the SPI master shifts in as long as it isn't full. As long as there's data in the FIFO you will read. When the FIFO is empty a read from it should return all zeros.

I would suggest you try to use the SPI in non-FIFO mode. FIFO mode is disabled by setting the SPIFFEN bit to 0 in the SPIFFTX register.

edit re your comment
There is no standard for what should happen if the master clocks new data in when there's none available; SPI doesn't occupy itself with you data content, it's basically just a shift register. The most sensible thing to do is sending zeros, but you could also be sending the last data from the FIFO again. Your protocol should avoid this kind of situation. Does the master really expect to read data, or is it only sending, ignoring data coming in? If it expects data, why isn't it there?

About the 8-bit format section 1.4.2 on page 17 says:

• Data must be left-justified when written to SPIDAT and SPITXBUF.
• Data read back from SPIRXBUF is right-justified.
• SPIRXBUF contains the most recently received character, right-justified, plus any bits that remain from previous transmission(s) that have been shifted to the left.

This indicates that the full 16-bit shift registers are used, but that only 8 clock pulses are generated.

Answer 2

Every time the master clocks a word's worth of data (normal word length is 8 bits, but some masters are programmable), a word of data will be sent and a word of data will be received. If the slave is "ready" for the data interchange, great. If not, the master will still send a word and receive a word; what will happen as a result depends upon the design of the slave.

A typical hardware slave device will be designed so that even when the device itself is "busy", its SPI hardware will either always be ready to exchange data, or else always be ready to have the master request status by feeding it a falling edge on /CS and clocking in some status-request command. If the device is busy, the hardware might not be able to do anything beyond sending an "I'm busy" response, but if the device sends a response that says "I'm not busy", it's guaranteed to be ready to exchange some amount of data without further delay (the exact amount of data will depend on the device, and possibly upon its reported status). For example, an SPI memory chip might be designed so that once it reports that it is not busy, it will always be ready to send or receive a page worth of data.

Note that many microcontrollers' SPI slave implementations fall way short in this regard. SPI has a very rigid association of incoming and outgoing data bytes; some controllers require that the CPU read each incoming byte and determine the response between the last clock of one byte and the first clock of the next, and send out unspecified data if the CPU fails to react in time. Some others are better in various ways, but many effectively require that the master either guess at when the slave is going to be ready for each byte, or else use another wire for that purpose. Even implementations which use another wire can be problematic, since if the handshake wire reports "ready", the master sends a byte, and the wire continues to report "ready", it may be unclear whether the slave is still ready, or whether the slave isn't ready but hasn't gotten around to setting its wire to indicate "unready". UARTs often include hardware flow control logic that will stop asserting a "ready" line as soon as they're unready, even without CPU intervention, but I've never seen an SPI slave that did so.