Handling SPI Bus Contention and Errors

In this lesson, you will learn how to identify and recover from communication failures in SPI networks caused by electrical glitches or conflicting master-slave states.

Understanding SPI Vulnerabilities

Unlike UART, which is point-to-point, SPI often operates in environments with multiple devices sharing the same MISO, MOSI, and SCK lines. Because SPI is a synchronous protocol, it is highly sensitive to the timing of the SS (Slave Select) signal.

The Problem: Bus Contention and Glitches

Bus contention occurs when two devices attempt to drive the MISO line simultaneously. This typically happens if two SS lines are asserted at once, or if a master resets while a slave is still actively shifting data out. Additionally, noise on the SCK line can cause "clock glitches," where the master and slave disagree on how many bits have been transferred, leading to a "bit-shift" error where subsequent data is offset or corrupted.

Detecting and Resolving Failures

To handle these issues, we look for two specific signs:

1. Illegal State Transitions: If you receive unexpected data patterns (e.g., all 0xFF or 0x00 in a system expecting specific headers), your slave might be out of sync.
2. Timeout Errors: Since SPI is master-driven, the master should implement a watchdog timer. If the bus stays busy or the transfer takes longer than the expected bit-duration, the master must abort.

To recover, you should implement a "Bus Reset" routine:

void spi_recover_bus() {
    // 1. De-assert all Slave Select lines to force slaves to idle
    set_ss_high(); 
    
    // 2. Clear buffers to remove stale bits
    clear_spi_rx_buffer();
    
    // 3. Briefly pulse the clock line if the slave is stuck
    // (This helps clear out a stuck bit-counter in the slave)
    for(int i = 0; i < 8; i++) {
        toggle_sck();
    }
}

By manually driving the SS pins high and clearing the internal shift registers, you reset the state machines of your peripherals to a known state. Always verify your data integrity after such a reset by requesting a "Who-Am-I" or status register byte before resuming high-speed communication.

Key Takeaway: SPI contention and bit-drift are best resolved by forcing all slave devices into an idle state via the Slave Select line and clearing shift registers before re-initiating communication.