Timeslot API timeslot IRQs are received 75 us late

[Bertram]

I am using the timeslot API, and I have noticed that if I read Timer0 as the first thing in my timeslot, it will be at 75 us. This delay is very consistent, so my timing between timeslots are accurate, but I find it strange that I dont get to execute code in my timeslot until timer0 is already at 75 us.

As I understand the documentation, timer0 keeps track of how long it was since my timeslot started (and thus how much time I have left before it ends). I have not found any reference to a delay from the time slot starts and to I get to execute code, so 75us (around 5000 clock cycles) seems excessive.

I am requesting time slots with the HF clock ready and high priority. The delay does not seem to be affected by if I am having active BLE connections, scanning or neither.

Is it expected behaviour to find the timer0 at around 75 us when you get to execute code in the timeslot? Or am i doing something wrong or havent configured things right?

Setup:

BOARD: nRF52840-DK devkit (NRF52840)

softdevice S140 version 6.1

SDK 15.2

[Sigurd]

Hi,

I was not able to reproduce this. Are you reading back the timer0 cc0 value when you get the NRF_RADIO_CALLBACK_SIGNAL_TYPE_START ?

static volatile uint32_t cc_start_value;

nrf_radio_signal_callback_return_param_t * radio_callback(uint8_t signal_type)
{
    switch(signal_type)
    {
        case NRF_RADIO_CALLBACK_SIGNAL_TYPE_START:

            NRF_TIMER0->TASKS_CAPTURE[0];
            cc_start_value = NRF_TIMER0->CC[0];
            NRF_LOG_INFO("NRF_RADIO_CALLBACK_SIGNAL_TYPE_START: TIMER0_CC0: %d",cc_start_value);

[Bertram]

Hi Sigurd

Yes, what you describe is exactly what I am doing.

Which value are you reading when you read timer0 cc0 on NRF_RADIO_CALLBACK_SIGNAL_TYPE_START ?

what is the expected value?

If 75 us is much higher than expected, I can create an example that reproduces the issue and runs on NRF52840-DK. I just did not want to spend the time stripping away non relevant code etc. and creating a nice lean example to demonstrate the issue,  if the 75 us was to be expected.

[Bertram]

I have now created an example that demonstrates the issue.

I actually see the "timeslot delay" vary quite a bit, from minimum 61 us to maximum 91 us, but its always there.

The example debug prints (100 times a second) the timer 0 value on time slot start. The code does not exit the time slot, but waits in the time slot with while loops (while transmitting some dummy data on the radio), until it ends the time slot.

See attached .zip :

nrf_ticket.zip

[Sigurd]

Hi,

From the release notes for s140_nrf52_6.1.1, the following bug-fix is mentioned:

Fixed an issue where NRF_TIMER0 may not be reset at the start of a radio timeslot (DRGN-10650).

Please use s140_nrf52_6.1.1_softdevice.hex instead, and see if that fixes the issue.

[Bertram]

Hi

I tried with the 6.1.1 softdevice, and now I read a value between 14-15 us. So this is a big improvement, much lower delay and much more stable.

Do you have an expected value for the timer when the time slot begins? Is the 14-15 us to be expected?

[Sigurd]

Bertram said:

So this is a big improvement, much lower delay and much more stable.

 Great!

Bertram said:

Do you have an expected value for the timer when the time slot begins? Is the 14-15 us to be expected?

 Yes, this seems to be expected. I'm measuring the same value here.