esp-idf-hal icon indicating copy to clipboard operation
esp-idf-hal copied to clipboard

GPIO pins receive current during deep sleep

Open ivmarkov opened this issue 3 years ago • 6 comments
trafficstars

(Originally submitted by @mihai-dinculescu against esp-idf-sys.)

Running the code below keeps the led on during the deep sleep, which is different from what I've experienced using the Arduino libs. Afaik unless gpio_hold_en(gpio_num_t gpio_num) is called alongside gpio_deep_sleep_hold_en(), the pin should go back to low during deep sleep.

Chip type:         ESP32 (revision 1)
Crystal frequency: 40MHz
Flash size:        4MB
Features:          WiFi, BT, Dual Core, Coding Scheme None
[dependencies]
anyhow = { version = "1.0", features = ["backtrace"] }
esp-idf-hal = "0.31"
esp-idf-sys = { version = "0.29", features = ["binstart", "native"] }
use anyhow::Context;
use esp_idf_hal::delay;
use esp_idf_hal::prelude::*;

fn main() -> anyhow::Result<()> {
    esp_idf_sys::link_patches();

    let peripherals = Peripherals::take().context("failed to get peripherals")?;
    let pins = peripherals.pins;

    let mut led = pins.gpio25.into_output_od()?;
    led.set_high()?;

    let mut delay = delay::Ets;
    delay.delay_ms(3000_u32);

    println!("going to sleep...");
    unsafe {
        esp_idf_sys::esp_sleep_enable_timer_wakeup(30 * 1_000_000u64);
        esp_idf_sys::esp_deep_sleep_start();
    }

    Ok(())
}

ivmarkov avatar Jan 09 '22 16:01 ivmarkov

This issues is still present. I've notice that it occurs when dropping the PinDriver which produce this log on the serial: I (7358) gpio: GPIO[13]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0

Which is the same log than when I initiate the pin driver as output.
I've try multiple workaround. changing the Pindriver using into_disable, changing the drop feature using this change: https://github.com/esp-rs/esp-idf-hal/pull/220/files.

nihuynh avatar May 08 '23 11:05 nihuynh

Don't drop the PinDriver or mem::forget it before entering deep sleep.

ivmarkov avatar May 08 '23 11:05 ivmarkov

The behaviour is the same if I don't drop the PinDriver. The pin has current after calling the function: esp_idf_sys::esp_deep_sleep(10 * 1000000); How I've fix it : I've manage to achieve my goal using this to start the sleep: esp_idf_sys::rtc_gpio_pullup_dis(esp_idf_sys::gpio_num_t_GPIO_NUM_13); esp_idf_sys::esp_sleep_enable_timer_wakeup(30 * 1_000_000u64); println!("Going to deep sleep for 30 secs."); esp_idf_sys::esp_deep_sleep_start(); The issues is that setting a RTC IO like the gpio13 as output is also setting a pull-up on that pin. The function esp_idf_sys::rtc_gpio_pullup_dis disable it during the deep sleep. PS: I could be wrong

nihuynh avatar May 08 '23 11:05 nihuynh

@nihuynh OK so saying:

This issues is still present.
I've notice that it occurs when dropping the PinDriver which produce this log on the serial:
I (7358) gpio: GPIO[13]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0

...was misleading right? If I understand you correctly, it is NOT about dropping the driver keeps the current in deep sleep, but it is about the fact that to get rid of the current, you have to explicitly call certain ESP IDF APIs? Can you please confirm that?

ivmarkov avatar May 13 '23 10:05 ivmarkov

The issue that i had was that : I set a pin connected to a small motor as output using PinDriver::output(peripherals.pins.gpio13)? Everything work as expected (i could set the pin as high or low) until going to deep sleep. The issues was that the motor was on (with reduce speed) during deep sleep. The log : I (7358) gpio: GPIO[13]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0 made me belive that after droping the pindriver the pin keeps the PullUp setting. My fix is to disable this, with that: esp_idf_sys::rtc_gpio_pullup_dis(esp_idf_sys::gpio_num_t_GPIO_NUM_13);

nihuynh avatar May 26 '23 08:05 nihuynh

Ok but then again: NOT dropping the driver does not fix anything, right?

ivmarkov avatar May 26 '23 09:05 ivmarkov

i think this is addressed in #344 Feel free to reopen it if you think otherwise.

Vollbrecht avatar Jun 21 '24 09:06 Vollbrecht