SPIM transfer from RTC handler gets stuck

[NewtoM]

Hi,

I wrote a function setting some GPIO pins, initiating an SPIM transfer (with EasyDMA), then waiting for the SPIM handler to signal end of transfer, and then set some GPIO pins again.

This is working perfectly fine from the main thread. If I try to use it from the context of an RTC handler (RTC2, running at 8 Hz), however, it gets stuck. First I thought it's only the SPIM handler that won't be called, but actually it seems like the SPIM transfer does not even start as long as the program is in the RTC handler context.

Is that known behavior? What is the workaround? I am using SDK11.

Thanks, NewtoM

Update:

• Incorporating SDK v11.0 -> v12.1 changes within nrf_drv_spi.c did not help.
• Disabling EasyDMA did not help, either.
• When disabling the SPI handler function, i.e., using nrf_drv_spi_init(&m_spi0, &SPI_config, NULL);, the code works again as expected (both with and without EasyDMA). But, then my SPI transfer blocks execution, which I don't want.

If I understand well, the latter case (no SPI handler) also means that the SPI driver will generate no interrupt at the end of the transfer. May that be the problem in my original case? I mean, starting code from an interrupt (RTC2) handler, in which another interrupt handler (SPI) tries to run ...

Any ideas?

Thanks!

[Sigurd]

What IC revision is this? It might be this problem.

[NewtoM]

Thanks for the quick reply, Sigurd! My revision is QFAAB0 so that should not be the problem. RTC2 seems to function (toggling an LED from its handler works).

[RK]

"waiting for the SPIM handler to signal end of transfer", do you mean that, are you actually sitting in the code spinning around waiting for a flag to show the end of the transfer?

Because if you are doing that in an interrupt handler, you're not returning from the interrupt handler and most likely the SPI handler is of equal or lesser priority than the RTC one so it never gets to run. And if you're blocking in the RTC handler, that's pretty much the wrong thing to be doing anywa.

[NewtoM]

Hi RK and thanks for the answer. The above was just a simplified description of what happens. Of course I am not really waiting, but at a specific point I was asserting the SPIM transfer having finished. And in the said case it never have.

Apart from this, your answer is correct. It had to do with the IRQ priorities. When increasing the SPI handler's priority, everything works as expected.

Thank you!