esp32c6 gpio wakeup stop working if CONFIG_PM_POWER_DOWN_PERIPHERAL_IN_LIGHT_SLEEP=y (IDFGH-12693)

[AxelLin]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v5.3-dev-3593-g64a1ed07d9, v5.4-dev-12-g3d813afa01

Espressif SoC revision.

ESP32C6

Operating System used.

Linux

How did you build your project?

Command line with idf.py

If you are using Windows, please specify command line type.

None

Development Kit.

Custom Board

Power Supply used.

USB

What is the expected behavior?

esp32c6 gpio wakeup stop working if CONFIG_PM_POWER_DOWN_PERIPHERAL_IN_LIGHT_SLEEP=y
Note, this was working in v5.2.1-443-g2ba5320112

What is the actual behavior?

press the gpio button seems has no effect.(device does not wake up from sleep)

Steps to reproduce.

I test it with my application code which I cannot share here.
The gpio wakeup related code are as below:

#if CONFIG_PM_POWER_DOWN_PERIPHERAL_IN_LIGHT_SLEEP
gpio_hold_en(MY_GPIO_BUTTON);
#endif

esp_sleep_enable_gpio_wakeup();
esp_light_sleep_start();

#if CONFIG_PM_POWER_DOWN_PERIPHERAL_IN_LIGHT_SLEEP
gpio_hold_dis(MY_GPIO_BUTTON);
#endif

esp_sleep_wakeup_cause_t wakeup_reason = esp_sleep_get_wakeup_cause();
// check wakeup reason..

It should be easy to reproduce it with some modification of examples/system/light_sleep/ example code.

Debug Logs.

No response

More Information.

No response

[esp-lis]

@AxelLin In the design of the esp32c6 chip, GPIO (Digital IO is located in the TOP power domain), Configuring CONFIG_PM_POWER_DOWN_PERIPHERAL_IN_LIGHT_SLEEP=y means that the TOP domain will power down during sleep, it means that Digital IO cannot be used as a wake source, In this case you can use LPIO or EXT1 as the wake source, behaving in the same way as GPIO (Digital IO).

Use of EXT1 or LPIO wake configurations can be found sleep_modes.html#external-wakeup-ext1

[AxelLin]

@esp-lis
I don't get it.
It works if build with esp-idf-5.2 branch. It stop working after switch to 5.3+.

[esp-lis]

@AxelLin Our recently optimized power domain management strategy (which should be included in version 5.3+), I guess on esp-idf-5.2 branch, CONFIG_PM_POWER_DOWN_PERIPHERAL_IN_LIGHT_SLEEP=y doesn't really power down TOP domain.

You can you the follow code to check the TOP domain state during system go to sleep.
esp_rom_printf(DRAM_STR("pd_flags:%x\n"), pd_flags)
put it into sleep_modes.c#L707, the TOP domain is powered down during sleep if the pd_flags's BIT(0) is set.

[AxelLin]

@esp-lis

v5.2: pd_flags:2c15
master (v5.4-dev-12-g3d813afa01) : pd_flags:2c15

so the pd_flags is the same for v5.2 and master.

BTW, I have apply this fix for my v5.2. (#11858 (comment) to make modem_domain_pd_allowed() return true)

[esp-lis]

@esp-lis

v5.2: pd_flags:2c15 master (v5.4-dev-12-g3d813afa01) : pd_flags:2c15

so the pd_flags is the same for v5.2 and master.

BTW, I have apply this fix for my v5.2. (#11858 (comment) to make modem_domain_pd_allowed() return true)

This is strange, pd_flags:2c15 means that the TOP domain will be powered down during sleep.

#if CONFIG_PM_POWER_DOWN_PERIPHERAL_IN_LIGHT_SLEEP
gpio_hold_en(MY_GPIO_BUTTON);
#endif

esp_sleep_enable_gpio_wakeup();
esp_light_sleep_start();

#if CONFIG_PM_POWER_DOWN_PERIPHERAL_IN_LIGHT_SLEEP
gpio_hold_dis(MY_GPIO_BUTTON);
#endif

esp_sleep_wakeup_cause_t wakeup_reason = esp_sleep_get_wakeup_cause();
// check wakeup reason..

Based on the above code, I can't see any more problems, Can you share more information about GPIO wakeup configuration?

[AxelLin]

There is nothing special for the GPIO wakeup configuration.
As I said the same code works if build with IDF-5.2, there must be some thing in newer IDF causes this regression.

[esp-lis]

There is nothing special for the GPIO wakeup configuration. As I said the same code works if build with IDF-5.2, there must be some thing in newer IDF causes this regression.

I'm unable to construct a case like this, could you please provide the simplest project that has this issue? It can help me locate the problem.