SX126x/8x SPI communication issue on some platforms

[jgromes]

Some faster platforms seem to have a problem with SPI communication on SX126x and SX128x. One ms delay seems to remedy this, but the root cause is currently unknown.

https://github.com/jgromes/RadioLib/blob/4ad5261a8333eabb7af332fc60df5e007bf22647/src/modules/SX126x/SX126x.cpp#L1658-L1663

[fazerlab]

I had the same problem with SX1278 + STM32 Bluepill, solve it with delay

[jgromes]

That's interesting, since the SPI driver for SX127x is fundamentally different from SX126x/8x. Could you share what exactly you did and post the debug output before the delay was added? It might help me track down this issue, thanks!

[danverstom]

I was having an issue where my receiving module (SX1262 LoRa + Adafruit M0 adalogger) was receiving half the data sent by my transmitter (SX1262 LoRa + Teensy 4.1). This was because the transmitter was sending the next packet before the receiver had the time to start receiving again, and therefore the receiver would only receive every other packet.

Initially I thought it was just due to the Adalogger being slower, but I then found the RADIOLIB_SPI_SLOWDOWN build option. It turns out that this was making the receiving adalogger take 10ms+ to read the data and start the receive process again.

Commenting this out solves the problem and I am not having any issues with SPI communication

Is it necessary to include this build option for all SAMD boards / can a better solution be found?

For my project, what is the best way of disabling this? For now I have commented it out in the RadioLib source but am looking for a more robust solution

Thanks

[jgromes]

@TomD53 well this is a bit of a skeleton in my closet ...

This entire thing started a few years ago due to issues I saw on STM32 with long SPI commands after switching off debug mode. I suspected the absence of the extra delay needed to dispaly the SPI transactions was somehow screwing up the SPI transaction itself. So I just put down a 1 ms delay and forgot about.

Trying again after a few years, the same code doesn't misbehave anymore, long SPI transactions are fine. This is the case for both STM32 and Sparkfun Artemis board. I cannot check Adafruit SAMD, but seeing as there are no issues for you either, I would say this was an unrelated problem that got solved at some point.

I will remove the slowdown macro, and hope it won't come back to haunt me again.

[danverstom]

Thanks for the fast response and the incredible library ♥️