the problem is, that the system is awake at least for the duration of one system tick – depends on the configTICKRATEHZ. 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. Question: 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.

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 configEXPECTEDIDLETIMEBEFORESLEEP 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.

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: configEXPECTEDIDLETIMEBEFORESLEEP is set to 10 clocks configUSETICKLESSIDLE 1 (off course thats the matter) configTICKRATEHZ 1000 -> leads to 1 ms awake time [every second]) if 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 to:

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

then the system is awake for only ~ 0.15 millis compared to ~ 1.15 millies otherwise. Or in the case configTICKRATEHZ 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. Regards.