Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


After vPortSuppressTicksAndSleep exits SysTick_Handler must be called once to sleep again

Posted by hmf55 on November 23, 2015

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.

After vPortSuppressTicksAndSleep exits SysTick_Handler must be called once to sleep again

Posted by rtel on 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 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.

After vPortSuppressTicksAndSleep exits SysTick_Handler must be called once to sleep again

Posted by hmf55 on 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:

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

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.


[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]

Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

Version 10.1.0 of the FreeRTOS kernel is available for immediate download. MIT licensed.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


FreeRTOS and other embedded software careers at AWS.

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers


STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner