Illustrative target contract: Mode 0, MSB first, one command byte followed by two data bytes while CS stays active. CS rising ends the command. No universal SPI rule supplies those byte counts or the CS policy; they are explicit target requirements.
A controller configuration can get the clock mode right and still fail by pulsing CS between bytes or inserting an unexpected dummy byte. Verify the byte/CS contract before interpreting a correctly sampled but displaced reply.
Convert a device timing contract into a controller transaction — worked trace
Illustrative isolated example; not measured silicon behaviour.
Implementation choice | What the target sees | Decision |
|---|---|---|
One 24-clock transaction under one CS | Command plus two data bytes | Matches the stated contract |
Three 8-clock transactions with CS pulses | Three separate commands | Wrong despite correct CPOL/CPHA |
One extra dummy byte without device support | Byte positions shift | Wrong unless the target contract requires it |
Inspect command, dummy-clock and CS framing. Correct per-bit decoding does not prove the multi-byte transaction contract.
SoC SPI controllers are configurable for mode, speed and chip select. Device description or firmware must match each target's requirements. DMA can reduce CPU service per word, but alignment, granularity and descriptor restrictions are controller-specific.
Verify mode bits in controller config match device datasheet.
CS GPIO vs hardware CS: GPIO adds software latency to CS timing.
SPI flash boot: mode and speed must match ROM bootloader config.