Skip to content

Conversation

@bjoernQ
Copy link
Contributor

@bjoernQ bjoernQ commented Jan 20, 2026

This at least partially addresses #3751 (not sure if we should close that and open new issues instead) - might also address #3873 (at least it seems like it does)

ESP32 seems to have a few more problems - e.g. the UART-baudrate is none of the common baud-rates (and definitely not the default 115200) after returning from light-sleep

Testing:

Add this e.g. after init

    // Start adding sleep code STOPSHIP
    let sleep_config = esp_hal::rtc_cntl::sleep::RtcSleepConfig::default();

    let delay = esp_hal::delay::Delay::new();
    delay.delay_millis(100);

    let timer =
        esp_hal::rtc_cntl::sleep::TimerWakeupSource::new(core::time::Duration::from_secs(5));

    let mut rtc = esp_hal::rtc_cntl::Rtc::new(peripherals.LPWR);
    esp_println::println!("sleep");
    delay.delay_millis(100);

    delay.delay_millis(100);

    rtc.sleep(&sleep_config, &[&timer]);
    delay.delay_millis(100);

With this change WiFi etc. works after a light-sleep w/o powering down the modem (or PLL) - for that I think we probably need to do more (e.g. it seems there are rom functions used as callbacks for enter/exit light-sleep - and more)

cfg.set_pwrctl_init(true);
cfg.set_rtc_dboost_fpd(true);
cfg.set_cpu_waiti_clk_gate(true);
cfg.set_bbpll_fpu(true);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at all the other chips this is a better default

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we really need to keep the main PLL running in sleep? I'd like to measure the change in power consumption after this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to measure the change in power consumption after this

Sure - that's very welcome - IIRC it wasn't much difference but I might be wrong. In any case a user can always opt-out (and end up with non-working radio after the light sleep)

.modify(|_, w| w.wifi_force_pu().clear_bit().wifi_pd_en().set_bit());
} else {
rtc_cntl.dig_pwc().modify(|_, w| w.wifi_pd_en().clear_bit());
rtc_cntl.options0().modify(|_, w| {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

revert the base-settings

@bjoernQ bjoernQ marked this pull request as ready for review January 20, 2026 16:30
@bugadani
Copy link
Contributor

Can we have a QA test for this? I don't agree with these changes but if they work, we need a way to easily see we don't break wifi.

@bjoernQ bjoernQ force-pushed the s3-c2-light-sleep-wifi branch from daf8cef to fb16204 Compare January 26, 2026 13:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants