SPI Slave dropping bits

[shuchitak]

System information
Using RPI3 as the SPI master configured with the SPI clock running at 390.625kHz.

Describe the current behavior
If I send back to back SPI xfers from the host, I see bits being dropped on the MISO output from the device. I haven't checked whether they're being dropped in the MOSI as well. I have ruled out that this is not happening as a result of the application overwriting the tx_buf, by preloading the tx_buf with non data and making sure that the application just drops the received xfer data and doesn't modify tx_buf. For eg. I've initialised my tx_buf with all bytes set to 0x5 but what I see on MISO is the bytes set to 0x82 which looks like a 1 bit shift in the output.

I've tried to narrow down what might be causing this and it looks like the latency in rtos_spi_slave_isr() execution is the reason. If I set ctx->waiting_for_isr = 0; before calling rtos_osal_queue_send() to add the xfer item to the xfer_done_queue, I don't see bits being dropped on MISO, atleast in the one test I have. Maybe, when we do implement changes to the driver to fix #64, we could change it so it's able to set ctx->waiting_for_isr = 0 to unblock the HIL thread before writing to the xfer_done_queue.

Describe the expected behavior

Standalone code to reproduce the issue
If possible, provide a reproducible test case that is the bare minimum necessary to generate
the problem.

Other info or logs
Include any logs or source code that would be helpful to diagnose the problem. If including tracebacks, please include the full traceback. Large logs and files should be attached.

[shuchitak]

I ran my test with all 4 SPI modes to check if modes with cpha = 1 shows fewer drops than modes with cpha = 0 as suggested by @xmos-jmccarthy. I don't see any improvement in performance as such with modes having cpha = 1.

I did notice something strange though. SPI_MODE_3 performs significantly worse than the other 3 SPI modes. I do 200 writes in quick succession in my test. While SPI mode 0, 1, 2 show on an average about 15-20 instances where MISO is corrupted, SPI_MODE_3 has about 60-70 out of 200 transfers with wrong MISO. Another very strange thing was, while all the other modes stopped showing any MISO errors when I put a wait between 2 consecutive commands, SPI_MODE_3, on adding a wait, started showing MISO wrong for all 200 transfers! So SPI_MODE_3 seems especially broken.

[xmos-jmccarthy]

I am working on some changes that should make the RTOS driver usage of spi_slave more consistent, and remove these issues.
The dropped bits you are seeing are most likely caused by timing errors due to the length of the application callbacks. My changes should make the RTOS driver usage of the driver consistent, but still high, as this is a consequence of SPI slave in software.

Until these changes are merged I recommend following the same guidelines as in lib_spi, concerning the CS to first SCLK and intertransaction time gaps:
https://www.xmos.ai/download/private/lib_spi-%5Buserguide%5D(3.0.2rc1).pdf
Section 1.4

[xmos-jmccarthy]

Closed by xmos/xcore_iot#537