After vPortSuppressTicksAndSleep exits SysTick_Handler must be called once to sleep again

hmf55 wrote on Monday, November 23, 2015:

the problem is, that the system is awake at least for the duration of one system tick - depends on the configTICK_RATE_HZ.

So my MCU is waken up every second to look for tasks to do and has to go to sleep (what most of it is) after wards.
I figured out, that this takes at least one System Tick which is not very energy efficient.

I’ve done some tests:
If I put a xTaskIncrementTick() after the vTaskStepTick(ulCompleteTickPeriods ), this aditional tick is marked as pending
and the system goes to sleep - almost immediately after wards as it should do.

Since I didn’t found a solution or explanation about that behaviour, is it OK to do it that way?

Or are there any other threads which I missed?

Thanks and Regards.

rtel wrote on Monday, November 23, 2015:

I would have to do quite a lot of investigation ot know if that would be ok to do or not, and partially the answer would be application specific anyway. For example, if your application is tollarant to time slippage or not (the time maintained by the running application’s tick count getting out of sync with calendar time).

Also, the most energy efficient solution is very much application dependent. There is a constant configEXPECTED_IDLE_TIME_BEFORE_SLEEP which is provided to deliberately delay going back to a low power mode after a period of execution to avoid having to continuously reprogram the clock, enter sleep mode, wake from sleep mode, wait for the clocks to start up again, etc., which itself may (depending on the frequency this happens) consume more power than just staying away.

hmf55 wrote on Monday, November 23, 2015:

Thanks for the fast reply. May be I was something incorrect rsp. incomplete.

The time is already maintained by a seperate RTC and since the MCU is running from the internal RC clock after wakeup, it is no matter to lose any already inaccurate system ticks.

To give some more detailed timings:

configEXPECTED_IDLE_TIME_BEFORE_SLEEP is set to 10 clocks
configUSE_TICKLESS_IDLE 1 (off course thats the matter)
configTICK_RATE_HZ 1000 -> leads to 1 ms awake time [every second])
configTICK_RATE_HZ 250 -> would give 4 ms awake time [every second]

*)[depends on the tasks and timers of course]

but when changeing the last lines of the

vPortSuppressTicksAndSleep function

    if ( ulCompleteTickPeriods > 0 )
        vTaskStepTick( ulCompleteTickPeriods - 1);

then the system is awake for only ~ 0.15 millis compared to ~ 1.15 millies otherwise.
Or in the case configTICK_RATE_HZ is set to 250: ~ 0.15 to ~ 4.15 millies.

So my suggestion/question is:
Why the system has to wait for another system tick if there are no tasks waiting?

If there are no known issues about that, I will go further this way since xTaskIncrementTick also
didn’t complain with an assertion about a forbidden call.