This reminds me of an unfortunate bug I was debugging the other day that had the same solution but a different problem on different hardware. Here's the setup:

This reminds me of an unfortunate bug I was debugging the other day that had the same solution but a different problem on different hardware. Here's the setup: I have a weird SPI device that has two different CS lines: one for accessing the control registers, and one for accessing the data buffer. Because of this, I have to handle CS manually and can't just let the SPI peripheral handle it. Fair enough, not a big deal. So I pull CS low, stick some data into the output register, and wait for TX_BUSY to go to 0 (i.e. done transmitting). Unfortunately, TX_BUSY goes low after the rising edge of the last bit, but before the falling edge of the clock back to idle. Despite the device saying that it's active on the rising edge of the clock, it totally disregards input data if CS goes back to idle before the last falling edge of the clock. Solved by adding some nop cycles. Easy to count how many are necessary because the peripheral and CPU are deterministic as described in the article, but damn what a debugging nightmare.