shuchitak
commented
2 years ago 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
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 https://github.com/xmos/fwk_rtos/issues/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.