FreeRTOS changes for better RTOS timer accuracy

[Susheel Nuguru]

Hi,

I have made some changes with how we update tick timer inside FreeRTOS and the results are promising . The improvement is

1. RTOS tick will auto correct if masked for more than one tick. BLE activity will not affect the RTOS tick accuracy. No ticks will be lost.
2. better RTOS timers resolution (max deviation noticed with BLE traffic is 2%).
3. TicklessIDLE wakeup tick correction is simplified using RTC overflow feature
4. More stable BLE connections due to increased efficiency of RTOS timers.

I have tested this for few hours but I need you guys to give feedback on how this improves your setup.

[WestCoastDaz]

Hi Aryan,

No unfortunately I didn't I was intregrating SDK 12.2 into our system yesterday and I had a multiple include issue that sucked up my day:(

Also, I was waiting on the further response on the Sourceforge post you made. I reviewed the thread and I am satisfied with the answer.

[ahedin25]

Susheel,

Please provide more explanation for this snippet (SDK 13.0.0):

    /* It is important that we clear pending here so that our corrections are latest and in sync with tick_interrupt handler */
    NVIC_ClearPendingIRQ(portNRF_RTC_IRQn);

Is this because the tick interrupt which is disabled, the event cleared, and then enabled in the sleep function will have always pended an interrupt (with a default tick of 1 ms and and an expected idle time of at least 2 ms)? I don't remember the interrupt firing immediately after vPortSuppressTicksAndSleep was exited, but it could be how I was testing it.

In what situation does this code in xPortSysTickHandler (line ~100) occur? And what is the reason for it?

#if configUSE_TICKLESS_IDLE == 1
    nrf_rtc_event_clear(portNRF_RTC_REG, NRF_RTC_EVENT_COMPARE_0);
#endif

Please provide some explanation as to why you switched from incrementing the tick once using the sleep function (vTaskAdjustTick) vs. repeatedly calling xTaskIncrementTick.

Thank you,

[Susheel Nuguru]

Hi ahedin25, Yes, that was the reason i saw interrupts being pended after wakeup from tickless idle sleep and were causing wrong increments of RTOS ticks. Also the latest RTC counter value is sniffed just before this line, so we do not need to count an already pended interrupt because we sniffed the value directly from the RTC counter. The advantage of sniffing the value from RTC counter is the autocorrection capabilities now the tick interrupt has when it is masked for more than a tick period. That is the reason I added the overflow feature of RTC so that we can sniff RTC counter without any side affects.

Please provide some explanation as to why you switched from incrementing the tick once using the sleep function (vTaskAdjustTick) vs. repeatedly calling xTaskIncrementTick.

Because of the softdevice ability to mask the FreeRTOS tick interrupt to many tick periods, i have noticed that FreeRTOS behaved differently when it is in critical section (disabled freertos interrupts) as it pended the actual increment to be done later after the RTOS came out of critical section. The result of this was that when RTOS came out of critical section, it had to increment the tick multiple times which was quite processor hungry (took more than 1 ms sometimes). Which directly lead to lost ticks. It was clearly not the efficient way to increment the tick multiple times because of how the critical sections for tick update methods are designed. Have you followed the discussion in FreeRTOS thread given in the answer. You can also find it here

This change should work fine with or without BLE softdevice, and as far as i see , there are no consequences of this as tick interrupt is running at lowest priority so we do not have to worry about the RTOS asserts as all other contexts are done processing when we are here .

[ahedin25]

So is the current implementation in SDK 13.0.0 not what it should be?

[Susheel Nuguru]

Can you please explain what you mean by that? The current implementation is how it should be