Timeslot API timeslot IRQs are received 75 us late

RE: Timeslot API timeslot IRQs are received 75 us late

Sigurd — Wed, 05 Feb 2020 16:00:01 GMT

[quote user="Bertram"]So this is a big improvement, much lower delay and much more stable.[/quote]

Great!

[quote user="Bertram"]Do you have an expected value for the timer when the time slot begins? Is the 14-15 us to be expected?[/quote]

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

RE: Timeslot API timeslot IRQs are received 75 us late

Bertram — Tue, 04 Feb 2020 13:05:15 GMT

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?

RE: Timeslot API timeslot IRQs are received 75 us late

Sigurd — Tue, 04 Feb 2020 12:42:55 GMT

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.

RE: Timeslot API timeslot IRQs are received 75 us late

Bertram — Mon, 03 Feb 2020 15:20:28 GMT

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 :

devzone.nordicsemi.com/.../nrf_5F00_ticket.zip

RE: Timeslot API timeslot IRQs are received 75 us late

Bertram — Mon, 03 Feb 2020 08:00:27 GMT

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.

RE: Timeslot API timeslot IRQs are received 75 us late

Sigurd — Mon, 03 Feb 2020 07:47:51 GMT

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);

RE: Timeslot API timeslot IRQs are received 75 us late

Bertram — Fri, 31 Jan 2020 10:12:43 GMT

I choose not to include code example etc. to reproduce the issue as I am just wondering if the observed time slot delay is to be expected behaviour or if I am doing something wrong.

If it is not expected behaviour, I can always spend the time to create nice reproduce examples etc. if relevant.