High Current Draw & Missed Presses with `button` Component v4.1.2 in Light Sleep (AEGHB-1051)

[michaelboeding]

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.

General issue report

High Current Draw & Missed Presses with button Component v4.1.2 in Light Sleep (enable_power_save=true) - Regression from v3.5.x

Component

Component: espressif/button
Version: v4.1.2 (Regression likely introduced after v3.5.x)

Environment

• IDF Version: v5.3.1
• Target: ESP32-S3
• Component Version: espressif/button v4.1.2
• Power Configuration: Light Sleep enabled, DFS enabled (CONFIG_PM_DFS_ENABLE), Auto Light Sleep enabled (esp_pm_config_t.auto_light_sleep = true), External 32kHz clock source.

Description

After upgrading the espressif/button component from a v3.5.x version to v4.1.2, we are experiencing issues when using a GPIO button configured with enable_power_save = true in conjunction with ESP-IDF's auto light sleep feature and DFS. This configuration worked correctly in the previous version (v3.5.x) without these issues.

The button is connected to an RTC-capable GPIO pin and uses an external 10kΩ pull-up resistor.

button_gpio_config_t Configuration

button_gpio_config_t gpio_cfg = {
    .gpio_num = /* Your RTC GPIO Pin */,
    .active_level = 0,         // Active low
    .enable_power_save = true, // Power save enabled
    .disable_pull = true       // External pull-up exists
};

Problem Details

Button Responsiveness & System Instability

• After running for a period of time with light sleep active, button presses eventually stop being recognized entirely.
• Most notably, neither the short press nor long press callbacks fire in this failure state.
• It is possible to enter a state where the system gets very close to firing the long press callback, but it never completes.
• When this happens, the system locks up completely and begins drawing approximately 25 mA, indicating that it is no longer operating in a low-power mode and may be stuck in an internal loop or deadlock.

Expected Behavior

• Button presses should be reliably detected, including the press that wakes the device from light sleep and subsequent presses.
• Both short press and long press callbacks should fire consistently when the respective press durations are met.
• The system should remain responsive and in low-power states when idle.

Actual Behavior

• Button responsiveness degrades over time when auto light sleep with DFS is active.
• Eventually, all button presses stop being detected.
• In some edge cases, holding the button triggers behavior that nearly fires the long press callback — but instead locks up the entire system.
• In this failure state, the system pulls a constant 25 mA and does not respond until manually reset.

Steps to Reproduce

1. Configure an ESP32-S3 project using ESP-IDF v5.3.1.
2. Enable light sleep and related power management features:
   • CONFIG_PM_ENABLE
   • CONFIG_PM_DFS_ENABLE
   • CONFIG_FREERTOS_USE_TICKLESS_IDLE
   • Use an external 32kHz crystal oscillator.
3. Configure esp_pm_config_t.auto_light_sleep = true.
4. Add the espressif/button component, version 4.1.2.
5. Initialize a GPIO button connected to an RTC pin using the configuration mentioned above (enable_power_save = true, disable_pull = true). Ensure an external pull-up is present.
6. Allow the device to idle and automatically enter light sleep.
7. Repeatedly press or hold the button and observe:
   • Callback behavior (short and long press)
   • System responsiveness
   • Whether the device becomes unresponsive or draws excess current

Possible Cause / Further Information

The issue seems related to the interaction between:

• The button component's enable_power_save logic,
• ESP-IDF's auto light sleep and DFS configuration,
• Internal use of esp_timer and how timers behave across light sleep wakeup,
• Potential ISR or debounce misbehavior around light sleep transitions.

This appears to be a regression from v3.5.x, where the same configuration worked reliably.

The changelog for espressif/button mentions power-saving improvements in:

• v3.2.0
• v3.2.3

And significant refactoring in:

• v4.0.0

This regression may stem from how internal timers and wakeup sources are handled across frequency scaling and low-power transitions.

[lijunru-hub]

I followed your configuration and added an external passive crystal oscillator, but I didn’t encounter the issue you mentioned. However, I do have a few questions:

I couldn’t find the configuration option CONFIG_PM_DFS_ENABLE in the ESP-IDF settings.
I suspect you might be referring to CONFIG_PM_DFS_INIT_AUTO.

Another observation: when I disconnect the external crystal, the chip enters an abnormal power consumption state, and the button stops responding.

I suspect your external crystal might be damaged or the connection is unstable. Please double-check this.

[michaelboeding]

Hey @lijunru-hub interesting yes I was talking about the below

#
# Power Management
#
CONFIG_PM_ENABLE=y
CONFIG_PM_DFS_INIT_AUTO=y
# CONFIG_PM_PROFILING is not set
# CONFIG_PM_TRACE is not set
CONFIG_PM_SLP_IRAM_OPT=y
CONFIG_PM_RTOS_IDLE_OPT=y
CONFIG_PM_SLP_DISABLE_GPIO=y
CONFIG_PM_SLP_DEFAULT_PARAMS_OPT=y
CONFIG_PM_LIGHTSLEEP_RTC_OSC_CAL_INTERVAL=1
CONFIG_PM_POWER_DOWN_CPU_IN_LIGHT_SLEEP=y
CONFIG_PM_RESTORE_CACHE_TAGMEM_AFTER_LIGHT_SLEEP=y
# CONFIG_PM_LIGHT_SLEEP_CALLBACKS is not set
# end of Power Management

I believe the crystal is working correctly but I will check on another board - I guess the reason I think this is that everything else is working auto light sleep with ble enabled etc.

In the version of 3.5.0 it seems the power management is directly defined by menuconfig but with the latest version I see references to CONFIG_PM_POWER_DOWN_PERIPHERAL_IN_LIGHT_SLEEP which I don't see as an option? Could it be related to that? I do have the experimental features enabled and still don't see that.

[michaelboeding]

To add to this I see it more often whenever WIFI is running also

[lijunru-hub]

This does not indicate that the button component is causing the issue. Please try disabling the button component module and see if the issue still occurs.