Return to Robotics Tutorials

SPI slave data corruption

This is Part 3 of a series describing how to use a Remote Control (RC) transmitter to drive a robot using an Arduino / ATtiny SPI slave. If you haven't already read it, please see Part 1 & Part 2 for the background material.

Table of Contents

SPI read transactions

Successful SPI Read Transaction at 62kHz

SPI Data corruption

SPI Data corruption due to Interrupts

Read transactions (slave responding to master) are more challenging than writes because the slave needs to analyze the first byte in order to respond in time for the start of the second byte. In fact, the SPI slave may only have enough information to determine how to respond by the end of the last bit from the first byte (clocked in by SCLK). Generally, the SPI master will expect that the SPI slave will start sending the first bit of the read data by the very next SCLK cycle. As a result, one of the most difficult timing windows for the slave is the setup time in advance of the second byte.

Unfortunately, some SPI masters only provide a single SCLK cycle between the byte transfers! If we depend on interrupts to notify us when we have completed the reception of byte 1 and set up the SPI Data Register (SPDR) for the start of byte 2, then the interrupt response latency (the time it takes for our ISR to start) becomes critical.

Corrupted SPI Read Transaction at 62kHz

As mentioned earlier, there are some scenarios that can cause our SPI Data Transfer Complete ISR to become delayed in starting -- these will eat in to our critical timing window. If we take too long, then the 2nd byte will start to be shifted out from the slave before we have configured what the outgoing byte should be! Since we haven't written to it in time, the SPI slave will simply shift out whatever was left in the data shift register (typically the value of byte 1 from the master).


Reader's Comments:

Please leave your comments or suggestions below!


Leave a comment or suggestion for this page:

(Never Shown - Optional)