I want to implement a kind of generic handler to reach standby mode of our STM32 controllers. Since not any idle can be a switch to that mode, I need to check some additional things to make sure I am actually allowed to switch.
The main input will be direct feedback from the tasks (basically setting a “from my point of view standby is ok” bit), but as a fallback I’d also like to check whether any(!) software timers are still running.
How do I do that? Is there a generic way or to I need to step through the whole list manually. And is there even a central list I am supposed to access from the outside?
I found eTaskConfirmSleepModeStatus, but this will always return eStandardSleep, since tasks need to cyclically wake to trigger a watchdog (which will of course be handled differently during standby).
Currently , there is no central list for the timers created by the user. So , currently the option is to go through the list manually and call xTimerIsActive for each created timer.
For your design requirement, why is eStandardSleep not achieving the purpose, because you will be going into STANDBY mode and not the SLEEP mode ?
Standard sleep means timer ARE running, so Standby would not be allowed (since standby results in restart via reset vector, so nothing FreeRTOS can support itself).
Issue is that it will never return eNoTasksWaitingTimeout since endless sleep in “normal” sleep context (down to the stop modes, ) would collide with the watchdog management.
You got me thinking whether I can change things in a way that eNoTasksWaitingTimeout is reached and the direct trigger for Standby allowed, but I think that would compromise the quality of the watchdog checks.
By the way: I had a look at the actual code of eTaskConfirmSleepModeStatus and it looks like eNoTasksWaitingTimeout is only happening if INCLUDE_vTaskSuspend is enabled. Which should not be necessary since according to the documentation Endless blocking (through portMAX_DELAY) should also lead to that result.
But portMAX_DELAY doesn’t mean “Endless blocking” unless INCLUDE_vTaskSuspend is true, if you don’t enable the suspending of tasks, portMAX_DELAY just means delay for that many ticks, which if the tick is only 16 bits, might not be that long (at 1 ms ticks, it is only about a minute).
I think this might be your best bet. Function eTaskConfirmSleepModeStatus() returns eNoTasksWaitingTimeout only when no timers are active (and of course only when no tasks are waiting for timeouts as the name implies). Status eNoTasksWaitingTimeout is a great prompt to use STANDBY mode.
You’re probably on the brink of a brilliant, elegant enhancement to your watchdog management!
For completions sake:
I now added dedicated functions to do endless vTaskDelay() and xTaskNotifyDelayIndexed()with watchdog monitoring disabled.
So deactivating the watchdog monitoring can not be done explicitly, but it is still possible to switch a monitored task to endless sleep. That way I can use eNoTasksWaitingTimeout
Thank you for sharing your solution!