[Solved] SPI slave data loss with Raspberry Pi at 100k baud

[stevestrong]

For the Roger's core you can find here some projects: https://github.com/rogerclarkmelbourne/ ... -535488793
And here for ST official core: https://learnbuildshare.wordpress.com/a ... -as-slave/

[fd_]

I finally found the problem, and as I was suspecting, it indeed was a stupid mistake from my part:

In the kernel modules, I was registering the interrupt for the rising edge, although it should have been the falling edge:

Code: Select all

request_threaded_irq(request_pin_irq, send_spi_message, NULL, IRQF_TRIGGER_RISING, "request", spi_dev);

The STM32 triggers the interrupt like this:

Code: Select all

digitalWrite(REQUEST_PIN, HIGH);
delay(1);
digitalWrite(REQUEST_PIN, LOW);

So, while the Raspberry Pi already started sending out data over SPI, the STM32 still had to wait 1ms, set the request pin low and start listening on the SPI.

Eventually, I decided to try sending longer strings, and that's when I noticed that the end of every message was received, and the amount of missing data at the start was influenced by the SPI baud rate (higher rate -> more data missing). I still don't know why I was seeing the 'H' at the start of the 'Hello!' message (I was receiving 'H!' for every 'Hello!' sent), but obviously, I don't intend on investigating this further. Now that I register the interrupt on the Pi on the falling edge, I seem to have reliable communication even at 16M baud rate, which I find phenomenal!

Once I had the base SPI communication going, I was able to build a DMA circular-buffered timer-triggered implementation in no time. I'm currently testing it and playing around a little.

I'd like to take this opportunity to thank everyone who was trying to help me in fixing the bug I was seeing, and generally all the great people developing the STM32duino stack and the HAL libraries! This really seems like a great platform to work with!