Sleep mode doesn't work (IDFGH-6346) #8007

boris92git · 2021-12-03T12:07:57Z

Environment

Module or chip used: ESP32-WROVER-E
IDF version (run git describe --tags to find it):
v4.4-dev-3565-g697f829d60
Build System: Make
Compiler version (run xtensa-esp32-elf-gcc --version to find it):
build it via docker(espressif/idf@sha256:bdcb958b9fc25a4109f2c18b9569adaae0d81abac03dd4dcf02983fd857fabc8)
Operating System: Linux
Using an IDE?: No
Power Supply: [USB|external 5V|external 3.3V|Battery]

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

#include <stdio.h>
#include "sdkconfig.h"
#include "esp_log.h"
#include <esp_sleep.h>

extern "C" {
void app_main();
}

void app_main(void)
{
    esp_deep_sleep(5000000);
}

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:

AxelLin · 2021-12-27T01:53:53Z

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.

AxelLin · 2022-01-14T08:10:36Z

@Alvin1Zhang
Anyone from espressif can take a look at the issue? (The mentioned PR fixed the issue).

MLStoltzenburg · 2022-01-28T16:21:08Z

Hi,

The same is happening with me.
If I enable CONFIG_ESP32_RTC_CLK_SRC_INT_8MD256, the deep sleep mode doesn't work.

I am using release/v4.3 -- commit: 5fc5125

bugadani · 2022-02-17T15:52:09Z

To clarify, deep sleep works, wakeup doesn't :) I seem to be experiencing this issue, with EXT0 as my wakeup source. Using CONFIG_ESP32_RTC_CLK_SRC_INT_RC works.

Weirdly, I don't remember this issue in esp-idf v4.3, but I hit it with v4.4. Hardware is ESP32-WROVER-IE

AxelLin · 2022-03-02T01:00:19Z

The same issue also happens on ESP32C3 if CONFIG_ESP32_RTC_CLK_SRC_INT_8MD256=y, tested on v4.3.2-355-g047adc5ebc.

AxelLin · 2022-03-02T01:07:28Z

@Alvin1Zhang @igrr

Hi
Can someone from espressif check this issue? This is clearly a regression.

AxelLin · 2022-03-03T09:20:03Z

ESP32S2 also has the same issue if CONFIG_ESP32_RTC_CLK_SRC_INT_8MD256=y.

AxelLin · 2022-03-24T08:10:02Z

Hi support team,
This is a regression in stable branches (it was working fine in older esp-idf version), and
it has been reported for more than 3 months.
Any one can help to fix it?

esp-lis · 2022-03-25T04:00:15Z

Hi support team, This is a regression in stable branches (it was working fine in older esp-idf version), and it has been reported for more than 3 months. Any one can help to fix it?

You can use the following code to power on the Internal 8MHz OSC power domain before deep sleep.
ESP_ERROR_CHECK(esp_sleep_pd_config(ESP_PD_DOMAIN_RTC8M, ESP_PD_OPTION_ON));

ginkgm · 2022-03-27T19:01:48Z

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.

AxelLin · 2022-03-28T01:02:45Z

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

@ginkgm
If you mean below changes, it does not work. (tested on esp32-wroom-32e).
Tested by calling esp_deep_sleep(5000000); in app_main, I think you can also verify it.

diff --git a/components/esp_hw_support/port/esp32/rtc_sleep.c b/components/esp_hw_support/port/esp32/rtc_sleep.c
index dff1b49acd..8d7f24c593 100644
--- a/components/esp_hw_support/port/esp32/rtc_sleep.c
+++ b/components/esp_hw_support/port/esp32/rtc_sleep.c
@@ -186,11 +186,11 @@ void rtc_sleep_init(rtc_sleep_config_t cfg)
         REG_CLR_BIT(RTC_CNTL_CLK_CONF_REG, RTC_CNTL_CK8M_FORCE_PU);
     }
     //Keep the RTC8M_CLK on in light_sleep mode if the ledc low-speed channel is clocked by RTC8M_CLK.
-    if (!cfg.int_8m_pd_en && GET_PERI_REG_MASK(RTC_CNTL_CLK_CONF_REG, RTC_CNTL_DIG_CLK8M_EN_M)) {
+    if (!cfg.deep_slp && GET_PERI_REG_MASK(RTC_CNTL_CLK_CONF_REG, RTC_CNTL_DIG_CLK8M_EN_M)) {
         REG_CLR_BIT(RTC_CNTL_CLK_CONF_REG, RTC_CNTL_CK8M_FORCE_PD);
         REG_SET_BIT(RTC_CNTL_CLK_CONF_REG, RTC_CNTL_CK8M_FORCE_PU);
-    } else {
-        REG_CLR_BIT(RTC_CNTL_CLK_CONF_REG, RTC_CNTL_CK8M_FORCE_PU);
+    //} else {
+    //    REG_CLR_BIT(RTC_CNTL_CLK_CONF_REG, RTC_CNTL_CK8M_FORCE_PU);
     }
 
     /* enable VDDSDIO control by state machine */

ginkgm · 2022-03-28T04:15:36Z

@AxelLin
wow..... thanks a lot.. Will look into this issue again..

AxelLin · 2022-04-25T08:28:00Z

@ginkgm
Do you have any update?

AxelLin · 2022-05-09T13:52:43Z

@ginkgm @esp-lis
This issue has been reported for 6 months, and people still hit this issue.
It's a big surprise that this regression is still not yet fixed.
Any one has reviewed this PR?: #8089 (It works with the PR fix)

igrr · 2022-05-09T14:12:49Z

@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.

ginkgm · 2022-05-13T08:19:02Z

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

ginkgm · 2022-06-04T17:07:09Z

The other part of fix is here: 1f6fad6

Backport to 4.4 and earlier version is on the way

AxelLin · 2022-07-13T00:16:04Z

@ginkgm
v4.3 branch still does not include this fix.

AxelLin · 2022-08-14T12:20:57Z

The other part of fix is here: 1f6fad6

Backport to 4.4 and earlier version is on the way

@ginkgm
I wait yet another month for the fix but the v4.3 branch still does not include this fix.

AxelLin · 2022-09-29T02:05:00Z

@ginkgm @igrr
There is another wrong wake up time issue with CONFIG_ESP32_RTC_CLK_SRC_INT_8MD256=y, #9455 .
So CONFIG_ESP32_RTC_CLK_SRC_INT_8MD256=y still does not work well with deepsleep.
Sigh, I didn't expect such long time to fix the wakeup from sleep mode issue.

AxelLin · 2022-10-14T05:43:11Z

@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.

This still does not work well because of wrong wake up time, #9455 .
I'm not sure if anyone is working on this because there is no response for months.

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

Sync configuration from other chips Closes: #8007, #8089

KonssnoK · 2023-05-10T07:30:45Z

Hi guys, this patch does not work for ESP32S3
see
#11362

espressif-bot added the Status: Opened Issue is new label Dec 3, 2021

github-actions bot changed the title ~~Sleep mode doesn't work~~ Sleep mode doesn't work (IDFGH-6346) Dec 3, 2021

boris92git mentioned this issue Dec 15, 2021

Fix deep sleep bug if RTS source is set as 8MD256 (IDFGH-6430) #8089

Open

AxelLin mentioned this issue Mar 25, 2022

DFS + CONFIG_ESP32_RTC_CLK_SRC_INT_8MD256=y causes reading ADC hang (IDFGH-6499) #8152

Closed

espressif-bot added Status: In Progress Work is in progress and removed Status: Opened Issue is new labels Apr 3, 2022

AxelLin mentioned this issue May 5, 2022

wake up deep sleep from timer with rtc clock set at 8MHz /256 (IDFGH-7311) #8899

Open

espressif-bot closed this as completed in 6f507d5 May 15, 2022

espressif-bot added Resolution: Done Issue is done internally Status: Done Issue is done internally and removed Status: In Progress Work is in progress labels May 16, 2022

This was referenced Jul 15, 2022

Failed to wakeup from deepsleep (IDFGH-7750) #9291

Closed

CONFIG_ESP32_RTC_CLK_SRC_INT_8MD256=y causes no recovery from light or deep sleep (IDFGH-7875) #9402

Closed

espressif-bot pushed a commit that referenced this issue Nov 12, 2022

rtc: fixed 8MD256 can't be used as RTC slow src on ESP32

b56b459

Sync configuration from other chips Closes: #8007, #8089

ESP-Marius mentioned this issue Nov 16, 2022

Failed to wakeup from light sleep (IDFGH-8746) #10182

Closed

3 tasks

AxelLin mentioned this issue Dec 8, 2022

When ESP32_RTC_CLK_SRC_INT_8MD256=y , wakeup from deep sleep time wrong (IDFGH-7938) #9455

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Sleep mode doesn't work (IDFGH-6346) #8007

Sleep mode doesn't work (IDFGH-6346) #8007

boris92git commented Dec 3, 2021 •

edited

Loading

AxelLin commented Dec 27, 2021

AxelLin commented Jan 14, 2022

MLStoltzenburg commented Jan 28, 2022

bugadani commented Feb 17, 2022 •

edited

Loading

AxelLin commented Mar 2, 2022

AxelLin commented Mar 2, 2022

AxelLin commented Mar 3, 2022

AxelLin commented Mar 24, 2022

esp-lis commented Mar 25, 2022

ginkgm commented Mar 27, 2022 •

edited

Loading

AxelLin commented Mar 28, 2022

ginkgm commented Mar 28, 2022

AxelLin commented Apr 25, 2022

AxelLin commented May 9, 2022

igrr commented May 9, 2022

ginkgm commented May 13, 2022 •

edited

Loading

ginkgm commented Jun 4, 2022 •

edited

Loading

AxelLin commented Jul 13, 2022

AxelLin commented Aug 14, 2022

AxelLin commented Sep 29, 2022

AxelLin commented Oct 14, 2022

KonssnoK commented May 10, 2023

Sleep mode doesn't work (IDFGH-6346) #8007

Sleep mode doesn't work (IDFGH-6346) #8007

Comments

boris92git commented Dec 3, 2021 • edited Loading

Environment

Problem Description

Expected Behavior

Actual Behavior

Steps to reproduce

Code to reproduce this issue

AxelLin commented Dec 27, 2021

AxelLin commented Jan 14, 2022

MLStoltzenburg commented Jan 28, 2022

bugadani commented Feb 17, 2022 • edited Loading

AxelLin commented Mar 2, 2022

AxelLin commented Mar 2, 2022

AxelLin commented Mar 3, 2022

AxelLin commented Mar 24, 2022

esp-lis commented Mar 25, 2022

ginkgm commented Mar 27, 2022 • edited Loading

AxelLin commented Mar 28, 2022

ginkgm commented Mar 28, 2022

AxelLin commented Apr 25, 2022

AxelLin commented May 9, 2022

igrr commented May 9, 2022

ginkgm commented May 13, 2022 • edited Loading

ginkgm commented Jun 4, 2022 • edited Loading

AxelLin commented Jul 13, 2022

AxelLin commented Aug 14, 2022

AxelLin commented Sep 29, 2022

AxelLin commented Oct 14, 2022

KonssnoK commented May 10, 2023

boris92git commented Dec 3, 2021 •

edited

Loading

bugadani commented Feb 17, 2022 •

edited

Loading

ginkgm commented Mar 27, 2022 •

edited

Loading

ginkgm commented May 13, 2022 •

edited

Loading

ginkgm commented Jun 4, 2022 •

edited

Loading