When does CS timing matter, and what bugs come from getting it wrong?

CS timing matters because many SPI slaves treat the CS edges as transaction framing, not just enable. A device typically expects CS to go low before the first SCLK edge and stay low for the entire transaction, then go high after the last bit, and it may latch or commit the received command on the rising CS edge, or reset its internal byte counter when CS deasserts. Get it wrong and you see subtle bugs: deasserting CS mid-transaction can abort or corrupt a multi-byte command; some devices need CS toggled (high between) per byte while others require it held low across a whole multi-byte burst, so using the wrong style mis-frames the data; and if CS glitches or is shared incorrectly, the device may interpret noise as a transaction. Because of this, firmware usually drives CS as a plain GPIO under software control (rather than the SPI peripheral's hardware-NSS) so it can guarantee exact assert/deassert points around the byte sequence per the datasheet. The debugging approach when reads look right "sometimes" is to scope CS against SCLK and verify it brackets the intended transaction with correct setup/hold relative to the clock.