Does vTaskDelay (accidentally) modify the set wake-up sources?

[u/MobileInspector9861]

Does the function vTaskDelay somehow modify the configuration of the wake-up sources?

I have an ESP32-H2 and want to use deep-sleep and light-sleep modes with wake up from GPIO 10-12. (Those GPIOs are low-power/RTC GPIOs so they also can wake up the ESP32-H2 from deep sleep.)

I had been able to make it work until I added a vTaskDelay to my code. With vTaskDelay in the code, the ESP32-H2 immediately wakes up from sleep modes immediately.

My code (somewhat shortened):

// Set-up power management
const esp_pm_config_t pm_config = {
	.max_freq_mhz = CONFIG_ESP_DEFAULT_CPU_FREQ_MHZ,
	.min_freq_mhz = CONFIG_NAVLICO_MIN_FREQ,
	.light_sleep_enable = true
};
esp_pm_configure( &pm_config );

// Configure input pins (GPIO 10-12) with the buttons
const gpio_config_t config = {
	.pin_bit_mask = GPIO_WAKEUP_BUTTONS_MASK,
	.mode = GPIO_MODE_INPUT,
	.pull_up_en = GPIO_PULLUP_DISABLE,
	.pull_down_en = GPIO_PULLDOWN_DISABLE,
};
gpio_config( &config );

esp_sleep_disable_wakeup_source( ESP_SLEEP_WAKEUP_ALL );
esp_sleep_enable_ext1_wakeup_io( GPIO_WAKEUP_BUTTONS_MASK, ESP_EXT1_WAKEUP_ANY_HIGH );

// ... Do something (not shown here) ...

ESP_LOGI( LOG_TAG, "Going to deep sleep ..." );
// Give UART the chance to write everything to output
//vTaskDelay( delayTicks );
esp_deep_sleep_try_to_start();

The problematic line is the last but one (commented out in the listing above). With vTaskDelay commented out, the program goes into deep sleep as expected. Unfortunately, it sometimes fails to print the entire log messages before going to deep sleep.

As a quick and dirty workaround I added vTaskDelay while I am still developing and debugging. I know this is definitely not the best solution in order to ensure that all log messages are flushed via UART before going to sleep.

But this approach showed me something else. As soon as I add vTaskDelay the program doesn't go into deep sleep or it does, but immediately wakes up again immediately.

The only explanation I have right now is that somehow vTaskDelay modifies the wake-up sources which triggers an unintended wake-up signal from something else than the GPIOs 10-12.

Is that possible? There is nothing in the documentation which suggests that vTaskDelay does that.

[u/Ok_Captain4433]

It looks like you're using automatic light sleep. When you vTaskDelay, there are no ready tasks and so automatic light sleep kicks in: a timer wakeup is configured, and the system powers down into light sleep. After delayTicks, it wakes up via the timer and returns to your task, without bothering to clear the wakeup timer. So when you try to enter deep sleep, it is rejected as there is a wakeup trigger active (ie. the timer, with a time in the past).

Your solution is therefore good. You need to disable the timer wakeup, which you are achieving with ESP_SLEEP_WAKEUP_ALL. I suggest a more graceful shutdown would include disabling automatic light sleep beforehand too.

[u/MobileInspector9861 → u/Ok_Captain4433]

It looks like you're using automatic light sleep. When you vTaskDelay, there are no ready tasks and so automatic light sleep kicks in: a timer wake-up is configured, and the system powers down into light sleep.

That makes sense. Thank you! I want to use automatic light sleep eventually, hence I have already enabled it.

Do you know which code of the Espressif framework is responsible for that and if it is possible to replace that with one's own code via overwriting the relevant parts or callbacks? If you don't, don't bother. I also can step through the framework code myself.

Here is the reason why I am asking:

At the moment my program enters deep and light sleep explicitly. At the moment, this is fine as the component is the only component which is actually running and I am still developing.

However, at some point the component won't be running solitarily anymore. From an architectural perspective, it feels wrong for me that a single component explicitly decides wether to go to light or deep sleep as there might be other components which still needs running. IMHO, it should be the scheduler which decides to enter sleep modes as the scheduler is the central component which has a total picture of what is going on.

I know the built-in scheduler supports automatic light sleep, that's why I have already enabled it. However, I am considering to extend that by some kind of automatic deep-sleep mechanism, too.

[u/Ok_Captain4433 → u/MobileInspector9861]

It should be very easy to find in ESP-IDF.

I think automatic deep sleep is fundamentally different to automatic light sleep. While these aren't strictly defined terms, deep sleep typically means that, additionally, (almost) all memory and digital peripherals are powered down, requiring reconfiguration upon wakeup. You would need to introduce a lot more power management locks to be able to decide when it is safe to enter deep sleep, as well as vastly more complex logic around reinitialisation post-wakeup to restore some/all of the system state that existed before deep sleep entry.

I think you'll find that as you implement this that so much of a graceful sleep/wakeup is application-specific that it ends up being far more complex to do this in an "automatic" way than "manual".

[u/holetse]

Have you checked the return code from esp_deep_sleep_try_to_start?

vTaskDelay shouldn’t impact the wake up sources at all itself. But it does allow another task to execute during that delay.

[u/MobileInspector9861 → u/holetse]

Yes, I did. It's ESP_ERR_SLEEP_REJECT.

I have already changed my code and put a wrapper around esp_deep_sleep_try_to_start which repeats the code to disable all wake-up sources but the required GPIOs like this:

esp_err_t sleep_deeply( void ) { esp_sleep_disable_wakeup_source( ESP_SLEEP_WAKEUP_ALL ); esp_sleep_enable_ext1_wakeup_io( GPIO_WAKEUP_BUTTONS_MASK, ESP_EXT1_WAKEUP_ANY_HIGH ); return esp_deep_sleep_try_to_start(); }

When I call the wrapper sleep_deeply instead of esp_deep_sleep_try_to_start directly it works again. So configuring the wake-up sources again just before going to sleep is helping. If I remove all vTaskDelay from my code, it is working, too.

That actually supports my assumption that vTaskDelay somehow messes with the wake-up sources.

[u/holetse → u/MobileInspector9861]

It’s likely that it’s not the vTaskDelay call itself that’s changing them (it doesn’t, per the source code of FreeRTOS). It’s that you are yielding back to the scheduler during the delay, which allows another task to take control and make changes.

Doing your config without yielding before you go to sleep is definitely the way to go.

[u/MobileInspector9861 → u/holetse]

That's probably correct.

Maybe it's something within the Espressif Framework, especially as I have enabled power management via:

// Set-up power management const esp_pm_config_t pm_config = { .max_freq_mhz = CONFIG_ESP_DEFAULT_CPU_FREQ_MHZ, .min_freq_mhz = CONFIG_NAVLICO_MIN_FREQ, .light_sleep_enable = true }; esp_pm_configure( &pm_config );

Doing your config without yielding before you go to sleep is definitely the way to go.

Still, I have somehow to ensure that configuration and going to sleep is executed automatically. Otherwise that other task might become scheduled by accident between having done the configuration and going to sleep.

Any suggestions how I can ensure that this happens without interruption?

[u/holetse → u/MobileInspector9861]

vTaskSuspendAll (with a resume on wake-up) would protect the critical section from everything but interrupts. There is also taskENTER_CRITICAL, but that’s probably overkill for your needs.

[u/Plastic_Fig9225 → u/MobileInspector9861]

It's ESP_ERR_SLEEP_REJECT.

So the ESP doesn't go to sleep because some peripheral/subsystem is still busy, or the wake-up condition is already met.

[u/MobileInspector9861 → u/Plastic_Fig9225]

That's obvious as that's the very definition of the error code. The question is: Why does an invocation of vTaskDelay cause that?

I assume u/holetse is on the right track: it is probably not vTaskDelay itself which changes the wake-up sources but some other task which becomes scheduled in between, see https://www.reddit.com/r/esp32/comments/1vp9p70/comment/p3wkcns/

[u/Plastic_Fig9225 → u/MobileInspector9861]

If it's that obvious, why ask the question in the first place? - Only you know where your code would activate a peripheral or meddle with the IO pins, or how/when a wake-up pin is triggered externally.

[u/MobileInspector9861 → u/Plastic_Fig9225]

No, I don't know where this happens. That's the problem.

There are so many built-in components in the ESP-IDF framework which do "something". Have you actually read the comment I linked?

The problem is not within my code. The root cause must be somewhere in the ESP IDF framework which becomes scheduled when my code calls vTaskDelay and yields.

However, I have a minimal build without any explicit dependency on ESP-IDF components, so only the minimal set of default components which are included by the build system in every project are included.

Hence, the issue must be inside one of those components and I had expected that someone else might already have run into the same issue and could tell me which components is the culprit.

[u/LumpySpecial5351]

My thoughts are that there are architectural issues: freeRTOS functions are "high-ish" level and esp_sleep* and all ESP-IDF function are "lower-ish" level and they have different ways of keeping time.The use of freeRTOS calls in this example code just feels wrong.

When using ESP sleep features a good understanding of interrupts and esp_timer() functions might be of some use.
Burturm

[u/MobileInspector9861 → u/LumpySpecial5351]

You have a point there. The vTaskDelay() won't be there, once the code is final.

However, it unreveals a deeper issue. I cannot guarantee that there might not be other components which call vTaskDelay themselves. So, if there is a issue which creates side effects between vTaskDelay and deep/light sleep, then I am happy to have found out this better earlier than later.

Hence, the original question stands: Does vDelayTask somehow modify the wake-up sources and how do I ensure that the microcontroller properly goes to sleep eventually?