This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

FreeRTOS changes for better RTOS timer accuracy

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.

Parents
  • 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,

    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,

Reply
  • 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,

Children
No Data
Related