nRF51822 SPI limitations (send/recv from timer)

[Gabriel C.]

Hello Everyone,

I am trying to use a display (through SPI) in a custom board with nRF51822 and SoftDevice S120. All works great as long as I call the SPI methods from main, and I am able to set up the screen properly and write everything I want in it.

The problem comes whenever I try to send/receive data through SPI outside main. Either I try to call it from a timer handler or an event handler, it only send 2 bytes max. through SPI.

To configure or write the screen I need to send a large amount of bytes, so when I am limited to 2 bytes from outside main I am not able to make it work. (Checked with Saleae Logic Analyzer)

Is there any kind of limitation of SPI I missed? Is it working only from main?

I already tried to send byte by byte with timing in between, send the full byte array at once, initialize the SPI in the timer, etc... but there is no way I can make it work.

Any advice or solution would be much appreciated.

Thanks in advance,

Gabriel.

[Krzysztof Chruscinski]

Hi,

are you using SPI driver from SDK (if yes then from which version?).

In general there is no such limitation, only that if you are using SoftDevice from time to time you might get bigger gaps between bytes in the transfer because SPI interrupt has bigger latency (if SoftDevice processes the stack).

If you have SoftDevice you must ensure that calls to SoftDevice does not happen from application high interrupt level because you will get deadlock (SVC call to SoftDevice on lower priority). SPI driver from SDK is calling softdevice API so it might be the case that your context has too high priority.

[muhkuhns]

I worked around this by just setting a flag when the timer expires and putting my actual code (+unset flag of course) inside an if(flag)-statement inside the main-loop.

This works fine for me. The cpu can also go to sleep. It checks in the main-loop if the flag is set, if not it goes to sleep. When the timer expires and the flag was set in the timer event handler the flag in the main-loop is checked again and executed and the cpu goes back to sleep again.