# configUSE\_TICKLESS\_IDLE mode vs interrupts **URL:** \ **Category:** Kernel\ **Created:** [May 29, 2015, 6:29pm UTC](https://forums.freertos.org/t/configuse-tickless-idle-mode-vs-interrupts/2914 "2015-05-29T18:29:34Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [May 29, 2015, 6:29pm UTC](https://forums.freertos.org/t/configuse-tickless-idle-mode-vs-interrupts/2914/1 "2015-05-29T18:29:34Z")
**[dumont02](https://sourceforge.net/u/dumont02/)** wrote on [Friday, May 29, 2015](https://sourceforge.net/p/freertos/discussion/382005/thread/81ad22a0/#90bf): We are looking for reducing power consumption in our PIC24F freeRTos application. For reducing power consumption, we are currently looking for using the configUSE\_TICKLESS\_IDLE freeRtos option. Since the current pic24f port does not support it yet, I was looking at adding the required portSUPPRESS\_TICKS\_AND\_SLEEP() macro myself based on instructions provided on the freeRtos Low Power website ([Tickless Low power features in FreeRTOS](http://www.freertos.org/low-power-tickless-rtos.html)). There something I must be missing though. On that website, it says: > To avoid race conditions the RTOS scheduler is suspended before portSUPPRESS\_TICKS\_AND\_SLEEP() is called, and resumed when portSUPPRESS\_TICKS\_AND\_SLEEP() completes. This ensures application tasks cannot execute between the microcontroller exiting its low power state and portSUPPRESS\_TICKS\_AND\_SLEEP() completing its execution. It also says in the example implementation of portSUPPRESS\_TICKS\_AND\_SLEEP(): > /\* Determine how long the microcontroller was actually in a low power > state for, which will be less than xExpectedIdleTime if the > microcontroller was brought out of low power mode by an interrupt > other than that configured by the vSetWakeTimeInterrupt() call. > Note that the scheduler is suspended before > portSUPPRESS\_TICKS\_AND\_SLEEP() is called, and resumed when > portSUPPRESS\_TICKS\_AND\_SLEEP() returns. Therefore no other tasks will > execute until this function completes. \*/ > ulLowPowerTimeAfterSleep = ulGetExternalTime(); Finally, from the vTaskSuspendAll() description: > API functions that have the potential to cause a context switch (for example, vTaskDelayUntil(), xQueueSend(), etc.) must not be called while the scheduler is suspended. Based on these previous citations, I can’t understand how it can work when an other interrupt wakes up the cpu. Let’s say I have a uart RX interrupt waking up the CPU, which calls taskYIELD() as recommended by freeRtos guidelines about ISR. Then it would perform a task context change going against the vTaskSuspendAll() documentation, right? Am I missing something or we really cannot use portSUPPRESS\_TICKS\_AND\_SLEEP() when we have interrupts using freeRtos services that may provoke a task context? Thanks for your help ---
**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\ **Post date:** [May 29, 2015, 8:15pm UTC](https://forums.freertos.org/t/configuse-tickless-idle-mode-vs-interrupts/2914/2 "2015-05-29T20:15:12Z")
**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Friday, May 29, 2015](https://sourceforge.net/p/freertos/discussion/382005/thread/81ad22a0/#90bf/0d28): When the scheduler is suspended interrupts remain enabled. When the interrupt comes in the interrupt service routine executes and calls for a re-schedule to switch to another task. The re-schedule code then executes, but seeing the scheduler is suspended it does not actually perform the context switch, but instead holds it pending. The ISR then exits back to the task code. The task, which was in the supporess-ticks-and-sleep function, exits the function, at which point the scheduler is unsuspended. Inside the function that unsuspends the scheduler it is recognised that a context switch is pending, and the context switch is performed immediately that the scheduler is no longer suspended. Does that answer your question? Regards. ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [May 30, 2015, 11:34am UTC](https://forums.freertos.org/t/configuse-tickless-idle-mode-vs-interrupts/2914/3 "2015-05-30T11:34:49Z")
**[dumont02](https://sourceforge.net/u/dumont02/)** wrote on [Saturday, May 30, 2015](https://sourceforge.net/p/freertos/discussion/382005/thread/81ad22a0/#6a14): Ok, makes sense! So if my understanding is correct, the statement in the vTaskSuspendAll() api doc > API functions that have the potential to cause a context switch (for example, vTaskDelayUntil(), xQueueSend(), etc.) must not be called while the scheduler is suspended is inaccurate since task context switch will simply pend until scheduler is resumed? ---
**Author:** ![richard-damon](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/richard-damon/32/38_2.png) [@richard-damon](https://forums.freertos.org/u/richard-damon)\ **Post date:** [May 30, 2015, 1:59pm UTC](https://forums.freertos.org/t/configuse-tickless-idle-mode-vs-interrupts/2914/4 "2015-05-30T13:59:54Z")
**[richard\_damon](https://sourceforge.net/u/richard_damon/)** wrote on [Saturday, May 30, 2015](https://sourceforge.net/p/freertos/discussion/382005/thread/81ad22a0/#da72): I think the limitation is that the task that calls vTaskSuspendAll() shouldn’t call something that will cause a context switch, but FreeRTOS handles the cases where the request occurs inside an ISR. One way to think of it is it is contradictory to both request no scheduling and at the same time do an operation that needs to schedule another task to perform. ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [May 30, 2015, 4:42pm UTC](https://forums.freertos.org/t/configuse-tickless-idle-mode-vs-interrupts/2914/5 "2015-05-30T16:42:04Z")
**[dumont02](https://sourceforge.net/u/dumont02/)** wrote on [Saturday, May 30, 2015](https://sourceforge.net/p/freertos/discussion/382005/thread/81ad22a0/#233c): Ok I understand. Many thanks for your clarifications! ---
**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\ **Post date:** [June 1, 2015, 5:14pm UTC](https://forums.freertos.org/t/configuse-tickless-idle-mode-vs-interrupts/2914/6 "2015-06-01T17:14:47Z")
**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Monday, June 01, 2015](https://sourceforge.net/p/freertos/discussion/382005/thread/81ad22a0/#6a14/ead9): No, the statement is correct, API functions that have the potential to cause a context switch must not be called when the scheduler is suspended as they function will return when it should not and there will be a logic error. That is very different to an interrupt attempting to cause a context switch, and having the context switch held pending. Regards.