I have an SPI peripheral that has an odd protocol and in trying to sort out why it was acting up I finally caught a logic trace showing about a 13us break in the SPI data I was sending. Normally this wouldn’t be an issue but this peripheral has a clock that times out with a max period of 7200ns (7.2us).
As far I can tell I can’t rely on the soft device not breaking in an inserting these long gaps in my SPI transfer, if Im wrong about this or if there is some documentation on exactly what the max length of these soft device interrupts could be please let me know or point me to the docs.
Now onto the possible hack that could save me. It seems my peripheral only has an issue if the break in the data comes when the data line is high, which means the next bit coming across MOSI is a one. However if the interrupt from the soft device occurs when MOSI is low and the next byte is a zero then I don’t have an issue. Coincidentally the data being sent is in two byte pairs where the first byte is always zero and the second byte is 0-255, so if the interrupt is before the first byte of the pair I am okay, but if it is before the second byte then I have a problem. I can see from my logic trace that the first two bytes are sent together because of the SPI double buffering but after that the bytes are sent as singles. I am making the assumption that the soft device can’t break in during that first two byte transfer so my thinking is if I can get all my data to transfer in these two byte pairs then any soft device interrupt will prepend a zero byte and I won’t get bad data.
So the question is, can someone point me to a good example of how to get all my data to send in pairs by keeping the double buffer primed? Am I going to have to do individual spi transfers of two bytes only, stepping through my data buffer or is there a way to force the built in SPI control to grab two bytes for each interrupt instead of one?
