FreeRTOS timers may fire earlier than expected when configUSE_TICKLESS_IDLE == 1

[KarRej]

Hi all,
I am using nrf52 with Softdevice 113 v7.0.1 and SDKv16 and FreeRTOS v10.0.1 and I am experiencing some issues with FreeRTOS timers expiring earlier than expected when configUSE_TICKLESS_IDLE == 1.

The problems started occurring when I applied fix in vTaskStepTick() proposed in the FreeRTOS forum: https://forums.freertos.org/t/assert-in-tasks-c-2611-on-xtickcount-wrap-around/9984
There were two solutions proposed, one in the Nordic port and the seconds in generic FreeRTOS code, but both of them cause the same problem.

I also created the corresponding post in the FreeRTOS forum: forums.freertos.org/.../13416

So is there any solution that fixes the original problem with assert on xTickCount wrap around that will not cause timers to expire too early?

[Susheel Nuguru]

Hi,

Sorry for the late reply, I was travelling and did not get a chance. It is interesting problem you have and I have seen the fix proposed and I like the idea but i think the fix needs a minor modification.

Current Code:

            if (diff > 0)
            {
                vTaskStepTick(diff);
            }

freertos forum Proposed Code:

            if (diff > 0)
            {
                vTaskStepTick(diff - 1);
                NVIC_SetPendingIRQ(portNRF_RTC_IRQn);
            }


New proposed code
            if (diff > 0)
            {
                BaseType_t switch_req = pdFALSE;

                vTaskStepTick(diff - 1);
                switch_req |= xTaskIncrementTick();

                /* Increment the RTOS tick as usual which checks if there is a need for rescheduling */
                if ( switch_req != pdFALSE )
                {
                    /* A context switch is required.  Context switching is performed in
                    the PendSV interrupt.  Pend the PendSV interrupt. */
                    SCB->ICSR = SCB_ICSR_PENDSVSET_Msk;
                    __SEV();
                }
            }

[Susheel Nuguru]

basically, the idea is good but pending an RTC for correction leaves more grey spots than the problem it solves.