FreeRTOS timers may fire earlier than expected when configUSE_TICKLESS_IDLE == 1

[KarRej]

Hi all,
I am using nrf52 with Softdevice 113 v7.0.1 and SDKv16 and FreeRTOS v10.0.1 and I am experiencing some issues with FreeRTOS timers expiring earlier than expected when configUSE_TICKLESS_IDLE == 1.

The problems started occurring when I applied fix in vTaskStepTick() proposed in the FreeRTOS forum: https://forums.freertos.org/t/assert-in-tasks-c-2611-on-xtickcount-wrap-around/9984
There were two solutions proposed, one in the Nordic port and the seconds in generic FreeRTOS code, but both of them cause the same problem.

I also created the corresponding post in the FreeRTOS forum: forums.freertos.org/.../13416

So is there any solution that fixes the original problem with assert on xTickCount wrap around that will not cause timers to expire too early?

[KarRej]

Susheel Nuguru said:

xExpectedIdleTime in vPortSuppressTicksAndSleep is somehow handled wrongly, since we disable the RTC interrupts for the time based on this value, it might be possible that the device is sleeping more than it should even if the timers are supposed to be expired earlier.

and

Susheel Nuguru said:

The wakeup from the sleep in 

vPortSuppressTicksAndSleep is taking aweful lot of time. This seems less likely but still possible. Not sure what we could optimize if this is what it is happening.

as far as I understand it, both should cause the timer to expire later than expected. 
And for me, it is not such a big problem. 
I am more concerned about the timer expiring earlier than expected. 
But anyway, I will redo the tests with configUSE_TICKLESS_IDLE_SIMPLE_DEBUG = 0 and let you know about the results

[KarRej]

I just checked this fix combined with configUSE_TICKLESS_IDLE_SIMPLE_DEBUG = 0 and the results are the same: min = 18.5ms, max = 21.5ms

[Susheel Nuguru]

I will have to reproduce this. I will make a small project to test the accuracy of the timers and come back to you today

[Susheel Nuguru]

Hi, I have tried to reproduce the 17.5ms min and 22.5 ms max variation of toggles at my desk and I was not successful in that. Which makes me think that there could be probably something more in your application that might be masking the kernel for longer times during some operations. One thing that i can think of such long operations can be flash erase operations. Are you using FDS library actively in your application? if so that can explain some shadowing while using using sd_app_evt_wait. 

Do you see the same results when you use below version of the sleep instead of sd_app_evt_wait?

                do{
                    __WFE();
                } while (0 == (NVIC->ISPR[0] | NVIC->ISPR[1]));

[KarRej]

I used the code you suggested instead of 

uint32_t err_code = sd_app_evt_wait();
//                NRF_STATUS_CHECK(err_code);

but it didn't helped. 
I still observe the timings from range <18.5ms;21.5ms>