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.

[Susheel Nuguru]

NOTE. tested on SDK12.x only (might work with other SDKs, but i am not sure)

apply this patch in SDK\external\freertos folder

No_Ticks_lost.patch

Discussion for a clarification for vTaskStepTick is started here
Update: The change in task.c::vTaskStepTick is now confirmed by FreeRTOS team to be safe and required in our case

EDIT: 19th May 2017

DO NOT USE THIS PATCH IN YOUR NEW DESIGNS. better patch available in here

[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 .