-
Notifications
You must be signed in to change notification settings - Fork 7.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sleep mode doesn't work (IDFGH-6346) #8007
Comments
Hit the same issue with v4.3.2-102-gda6c5be6c1, esp32 does not wakeup from deepsleep if ESP32_RTC_CLK_SRC_INT_8MD256 is used. |
@Alvin1Zhang |
Hi, The same is happening with me. I am using release/v4.3 -- commit: 5fc5125 |
To clarify, deep sleep works, wakeup doesn't :) I seem to be experiencing this issue, with EXT0 as my wakeup source. Using Weirdly, I don't remember this issue in esp-idf v4.3, but I hit it with v4.4. Hardware is ESP32-WROVER-IE |
The same issue also happens on ESP32C3 if CONFIG_ESP32_RTC_CLK_SRC_INT_8MD256=y, tested on v4.3.2-355-g047adc5ebc. |
Hi |
ESP32S2 also has the same issue if CONFIG_ESP32_RTC_CLK_SRC_INT_8MD256=y. |
Hi support team, |
You can use the following code to power on the Internal 8MHz OSC power domain before deep sleep. |
Hi @boris92git , @AxelLin , @MLStoltzenburg , Thanks for reporting this issue. I see all the commits you reporting that have such issue, have a common commit: e44ead5. I guess it's not related to this commit: 73384ad Could you help to comment these lines and have a look? cc68fbf1679ce4376c2b26cf73c7b69498a0564e5973c2f4fdf125ba69b064ceR192 In this commit, a new control bit is introduced - int_8m_pd_en, which is true by default. This makes the code run into the second path (disable 8M, which doesn't exist before), which will bypass the protection in above lines. In previous code, if using lightsleep, the code will run into the first path (power up 8M). We are working on this. But if I can get your confirmation, it will be great. |
@ginkgm
|
@AxelLin |
@ginkgm |
@AxelLin the fix for this issue is finished and is under review now, it's a bit different than the linked PR. We'll try to merge it soon. |
There are two fixes together fix this issue. The first one has been merged to master: cc37f63 The backport and the second part are on the way. Thanks for reporting and patience. |
introduced in e44ead5 1. The int8M power domain config by default is PD. While LEDC is using RTC8M as clock source, this power domain will be kept on. But when 8MD256 is used as RTC clock source, the power domain should also be kept on. On ESP32, there was protection for it, but broken by commit e44ead5. Currently the power domain will be forced on when LEDC is using RTC8M as clock source && !int8m_pd_en (user enable ESP_PDP_DOMAIN_RTC8M in lightsleep). Otherwise the power domain will be powered off, regardless of RTC clock source. In other words, int8M domain will be forced off (even when 8MD256 used as RTC clock source) if LEDC not using RTC8M as clock source, user doesn't enable ESP_PDP_DOMAIN_RTC8M, or in deep sleep. On later chips, there's no such protection, so 8MD256 could't be used as RTC clock source in sleep modes. This commit adds protection of 8MD256 clock to other chips. Fixes the incorrect protection logic overriding on ESP32. Now the power domain will be determiend by the logic below (order by priority): 1. When RTC clock source uses 8MD256, power up 2. When LEDC uses RTC8M clock source, power up 3. In deepsleep, power down 4. Otherwise determined by user config of ESP_PDP_DOMAIN_RTC8M, power down by default. (This is preferred to have highest priority, but it's kept as is because of current code structure.) 2. Before, after the macro `RTC_SLEEP_CONFIG_DEFAULT` decides dbias, the protection above may force the int8m PU. This may cause the inconsistent of dbias and the int8m PU status. This commit lifts the logic of pd int8m/xtal fpu logic to upper layer (sleep_modes.c). Related: #8007, #8089 temp
introduced in e44ead5 1. The int8M power domain config by default is PD. While LEDC is using RTC8M as clock source, this power domain will be kept on. But when 8MD256 is used as RTC clock source, the power domain should also be kept on. On ESP32, there was protection for it, but broken by commit e44ead5. Currently the power domain will be forced on when LEDC is using RTC8M as clock source && !int8m_pd_en (user enable ESP_PDP_DOMAIN_RTC8M in lightsleep). Otherwise the power domain will be powered off, regardless of RTC clock source. In other words, int8M domain will be forced off (even when 8MD256 used as RTC clock source) if LEDC not using RTC8M as clock source, user doesn't enable ESP_PDP_DOMAIN_RTC8M, or in deep sleep. On later chips, there's no such protection, so 8MD256 could't be used as RTC clock source in sleep modes. This commit adds protection of 8MD256 clock to other chips. Fixes the incorrect protection logic overriding on ESP32. Now the power domain will be determiend by the logic below (order by priority): 1. When RTC clock source uses 8MD256, power up 2. When LEDC uses RTC8M clock source, power up 3. In deepsleep, power down 4. Otherwise determined by user config of ESP_PDP_DOMAIN_RTC8M, power down by default. (This is preferred to have highest priority, but it's kept as is because of current code structure.) 2. Before, after the macro `RTC_SLEEP_CONFIG_DEFAULT` decides dbias, the protection above may force the int8m PU. This may cause the inconsistent of dbias and the int8m PU status. This commit lifts the logic of pd int8m/xtal fpu logic to upper layer (sleep_modes.c). Related: #8007, #8089 temp
The other part of fix is here: 1f6fad6 Backport to 4.4 and earlier version is on the way |
@ginkgm |
introduced in e44ead5 1. The int8M power domain config by default is PD. While LEDC is using RTC8M as clock source, this power domain will be kept on. But when 8MD256 is used as RTC clock source, the power domain should also be kept on. On ESP32, there was protection for it, but broken by commit e44ead5. Currently the power domain will be forced on when LEDC is using RTC8M as clock source && !int8m_pd_en (user enable ESP_PDP_DOMAIN_RTC8M in lightsleep). Otherwise the power domain will be powered off, regardless of RTC clock source. In other words, int8M domain will be forced off (even when 8MD256 used as RTC clock source) if LEDC not using RTC8M as clock source, user doesn't enable ESP_PDP_DOMAIN_RTC8M, or in deep sleep. On later chips, there's no such protection, so 8MD256 could't be used as RTC clock source in sleep modes. This commit adds protection of 8MD256 clock to other chips. Fixes the incorrect protection logic overriding on ESP32. Now the power domain will be determiend by the logic below (order by priority): 1. When RTC clock source uses 8MD256, power up 2. When LEDC uses RTC8M clock source, power up 3. In deepsleep, power down 4. Otherwise determined by user config of ESP_PDP_DOMAIN_RTC8M, power down by default. (This is preferred to have highest priority, but it's kept as is because of current code structure.) 2. Before, after the macro `RTC_SLEEP_CONFIG_DEFAULT` decides dbias, the protection above may force the int8m PU. This may cause the inconsistent of dbias and the int8m PU status. This commit lifts the logic of pd int8m/xtal fpu logic to upper layer (sleep_modes.c). Related: #8007, #8089 temp
Hi guys, this patch does not work for ESP32S3 |
Environment
git describe --tags
to find it):v4.4-dev-3565-g697f829d60
xtensa-esp32-elf-gcc --version
to find it):build it via docker(espressif/idf@sha256:bdcb958b9fc25a4109f2c18b9569adaae0d81abac03dd4dcf02983fd857fabc8)
Problem Description
ESP32 doesn't wake up from sleep mode if RTC clock source is set like an Internal 8.5MHz oscillator, divided by 256
Expected Behavior
I expect the ESP32 to wake up 5 seconds after running this test code.
Actual Behavior
ESP32 doesn't wake up(((
Steps to reproduce
Set RTC clock source:
menuconfig->Component config->ESP32-specific->RTC clock source: Internal 8.5MHz oscillator, divided by 256
and flash the code from the section below.
Code to reproduce this issue
I think the problem occurs due to this commit:
73384ad
If I remove lines or set RTC source like internal 160kHz RC oscillator.
The test code is correctly working.
The text was updated successfully, but these errors were encountered: