RE: Timeslot api - timeslots triggered prematurely

eyalasko — Tue, 26 Feb 2019 23:22:26 GMT

To whom it may help -

It happened to be a flaw in my code.

I called an RTOS api, xQueueSendFromISR(), from within the callback.

The callback runs in the highest priority (smallest number - 0) which is higher than configMAX_SYSCALL_INTERRUPT_PRIORITY (=2) as described here

RE: Timeslot api - timeslots triggered prematurely

Susheel Nuguru — Mon, 25 Feb 2019 11:29:26 GMT

Hi eyalasko,

[quote user=""][/quote]

Now, I occasionally observe that the next timeslot, that is supposed to get triggered every 29000us (or longer in 100us steps) actually fires prematurely.

This is often accompanied by a hard-fault (not necessarily immediately)

We have not seen such a behavior with timeslots before. Are you sure that the clock source LFCLK is selected correctly with the right accuracy? If there are differences in the underlying clock accuracies and to which you which configured the softdevice, this could happen as the softdevice measured expected jitter varies to the actual actual clock. This can be fixed by telling the softdevice the right accuracy of the lfclk being used when you enable the softdevice.

[quote user=""]If initial timeslot was granted using high priority, do all other timeslots should be requested with high priory as well?[/quote]

No, that should not be needed. You can take each timeslot request on the individual basis.

[quote user=""]Is it possible that after the callback returned NRF_RADIO_SIGNAL_CALLBACK_ACTION_END, another single timeslot shall be triggered (as also observed)[/quote]

That should not happen if you have only opened one session. There seems to be something wrong in the request of the timeslot. Are you sure that your app is not trying to request another timeslot while there is one already in the queue?