FreeRTOS changes for better RTOS timer accuracy

RE: FreeRTOS changes for better RTOS timer accuracy

ahedin25 — Wed, 29 Mar 2017 15:16:42 GMT

Should the SDK 13 solution call xTaskGetTickCountFromISR? So that it reads properly. Implemenation is the same.

RE: FreeRTOS changes for better RTOS timer accuracy

ahedin25 — Fri, 24 Mar 2017 14:57:25 GMT

The patch in this thread:

if(diff > 1)
{
    /* This could happen if this interupt was masked for more than one RTOS tick period */
    vTaskStepTick(diff - 1);
}


 if ( xTaskIncrementTick() != pdFALSE )
 {
     SCB->ICSR = SCB_ICSR_PENDSVSET_Msk;
     __SEV();
 }

RE: FreeRTOS changes for better RTOS timer accuracy

ahedin25 — Fri, 24 Mar 2017 14:56:41 GMT

SDK 13.0.0

if (configUSE_DISABLE_TICK_AUTO_CORRECTION_DEBUG == 0)
{
    /* check FreeRTOSConfig.h file for more details on configUSE_DISABLE_TICK_AUTO_CORRECTION_DEBUG */
    TickType_t diff;
    diff = ((m_tick_overflow_count << portNRF_RTC_BITWIDTH) + systick_counter) - xTaskGetTickCount();

    while((diff--) > 0)
    {
        switch_req |= xTaskIncrementTick();
    }
}
else
{
    switch_req = xTaskIncrementTick();
}

/* Increment the RTOS tick as usual which checks if there is a need for rescheduling */
if ( switch_req != pdFALSE )
{ 
   	 ...
}

RE: FreeRTOS changes for better RTOS timer accuracy

ahedin25 — Fri, 24 Mar 2017 14:56:29 GMT

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?

RE: FreeRTOS changes for better RTOS timer accuracy

Susheel Nuguru — Thu, 23 Mar 2017 21:50:01 GMT

Thanks Darren, yes these changes are included in sdk13.0.0 version. No need for these patch in this release anymore.

RE: FreeRTOS changes for better RTOS timer accuracy

WestCoastDaz — Thu, 23 Mar 2017 21:25:24 GMT

Aryan,

I think what ahedin25 is asking is have these changes been incorporated into SDK 13 or do we have to update port_cmsis_systick.c and task.c in SDK 13?

Cheers, Darren

RE: FreeRTOS changes for better RTOS timer accuracy

Susheel Nuguru — Thu, 23 Mar 2017 21:11:10 GMT

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

RE: FreeRTOS changes for better RTOS timer accuracy

ahedin25 — Thu, 23 Mar 2017 21:01:43 GMT

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

RE: FreeRTOS changes for better RTOS timer accuracy

Susheel Nuguru — Thu, 23 Mar 2017 20:51:42 GMT

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 .

RE: FreeRTOS changes for better RTOS timer accuracy

ahedin25 — Thu, 23 Mar 2017 19:44:12 GMT

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,

RE: FreeRTOS changes for better RTOS timer accuracy

WestCoastDaz — Thu, 08 Dec 2016 23:36:21 GMT

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.

RE: FreeRTOS changes for better RTOS timer accuracy

Susheel Nuguru — Thu, 08 Dec 2016 20:30:47 GMT

Hi Darren, did you get time to test this?

RE: FreeRTOS changes for better RTOS timer accuracy

cp52 — Wed, 07 Dec 2016 08:30:10 GMT

Is the patch for the nordic SDK 12. or 12.2 or does it not matter?

Sorry. I cant read I see that the answer is below.

RE: FreeRTOS changes for better RTOS timer accuracy

Susheel Nuguru — Wed, 07 Dec 2016 06:19:49 GMT

Hi Darren,

I attached a patch for it. I think it is unfair to make vTaskStepTick available only for tickless mode. I have created a post in FreeRTOS forum to convey this.
Sourceforge post

Anyways, since we have source code, I have removed this restriction for now by removing the compile flag. This must be agreeable given the nature of our BLE stack.

RE: FreeRTOS changes for better RTOS timer accuracy

WestCoastDaz — Wed, 07 Dec 2016 04:26:28 GMT

Aryan,

I tried to compile this new file but I can't link vTaskStepTick when not using TicklessIDLE. From your initial post it seems like this should work for either Tick mode and Tickless mode.

Thanks, Darren

RE: FreeRTOS changes for better RTOS timer accuracy

Susheel Nuguru — Tue, 06 Dec 2016 22:53:55 GMT

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