What happens if two SPI slaves are selected simultaneously, and how do you prevent it?

If two CS lines are asserted at the same time, both slaves enable their MISO output drivers and drive the shared MISO line simultaneously. If one drives high while the other drives low, a short-circuit current flows through both output stages. This corrupts the data the master reads, and in the worst case, the sustained contention current can damage the output transistors of one or both slave devices.

Prevention is straightforward in firmware: always de-assert the current slave's CS before asserting the next slave's CS. In safety-critical systems, add a small delay between de-assertion and re-assertion to account for CS propagation delay through any buffers or level shifters.

A subtler problem occurs with hardware-managed CS on some MCUs. If the SPI peripheral is configured to manage CS automatically, switching the CS GPIO to a different slave while a transaction is in progress can briefly assert both. The safe approach is to complete the current transaction, wait for the SPI busy flag to clear, de-assert CS in software, then configure the new slave's CS pin. Another defensive technique is to use external logic (a decoder or mux) so that only one CS can be active at a time by design, regardless of firmware bugs.