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

[ahedin25]

I am sorry, but I am still don't understand the explanation. SDK 13 repeatedly calls increment tick, but your patch only calls step tick once and increment tick once.

When using the patch code in my system, vTaskStepTick would assert. The FreeRTOS discussion indicates that vTaskStepTick can't be used because it might jump over the tick of when a task unblocks. Your explanation indicates that in certain situations the time to increment the tick for all of the lost ticks could take a millisecond.

So, it seems that xTaskIncrementTick must be used to corret the tick and in some cases it will cause another tick to be lost. What happens when another tick occurs when running in the tick interrupt handler?