In a project based on Softdevice S132 7.0.1 employing the Softdevice timeslot API, I noticed that the nrf_radio_signal_callback_t function passed into sd_radio_session_open() sometimes seems to be invoked with a 10us delay compared to other occasions. I'm not sure whether this pertains to all signals handled by the callback; so far I looked at NRF_RADIO_CALLBACK_SIGNAL_TYPE_RADIO.
The following diagram shows the timing as recorded with debug pins The "RADIO_ACTIVE" signal is two PPI channels linking the NRF_RADIO->EVENTS_READY event with a GPIOTE task and the NRF_RADIO->EVENTS_DISABLED event with another GPIOTE task on the same pin. The "SIGNAL_HANDLER" signal is a software-toggled pin at the beginning of the signal handler. This is the slower timing.
With "faster timing" the same event looks like this:
As you can see, it takes 14.612us between NRF_RADIO->EVENTS_DISABLED being asserted and the signal handler being called if no debugger is connected, while it only takes 3.56us if none is connected.
I had a hunch that it might be somewhat related to the issue NUS connection problems with TimeSync example ported to SDK16.0.0 so I tried to configure the timeslot with NRF_RADIO_HFCLK_CFG_NO_GUARANTEE, but this does not seem to have any impact.
Initially, I thought it is related to the debugger being connected or not, but currently I'm not sure. I have not run into any issues with the debugger connected, but without debugger connected the scenario with 10us delay seems to occur from time to time.
How can I ensure that the delay is always smaller?
EDIT: I invested some more time in investigating this issue and realised that it is not related to timeslot use. Measuring the same timings with a project, that does not have the softdevice enabled, but uses the radio directly; I noticed that sometimes there is a factor 10 delay between the peripheral event and the IRQ handler being called. I'm testing on a nRF52832 (on the PCA10040 / nRF52 DK)
EDIT 2: Further investigation showed that the faster timing is obsorvable significantly more often than the slower timing if a debugger is connected. The slower timing is observable significantly more often if no debugger is connected. It seems like whether the radio is receiving or transmitting does not have an impact on the outcome.