Hi, davdav You do not need to reconfigure the GPIO mode before entering deep-sleep. When `gpio_deep_sleep_hold_en` is called, all digital GPIOs will remain in their current state. But after the chip wakes up from deep sleep and calls `gpio_deep_sleep_hold_dis`, all digital GPIOs will be reset to th...

Hi everybody, I have the necessity to isolate some GPIO (not RTC) like GPIO16, GPIO18, GPIO22 and GPIO23 during deepsleep in ESP32-WROOM32D module. In my case GPIO22 and GPIO23 are outputs and using gpio_hold_en(); gpio_deep_sleep_hold_en(); I'm able to fix their status during deep-sleep and wakeup ...

Non-rtcio pins aka digital pins shouldn't be leaking in deep sleep I'm trying to understand if GPIO (non-RTC), for example GPIO22, GPO23,GPIO5, etc.., are "automatically" isolated when ESP32 goes into deep-sleep or I have to take some care depending on the external circuit (if there is a pull-up, p...

WiFive wrote: ↑

Tue May 21, 2019 11:31 am

gpio_hold_en

Uhm..it seems to work.

At this point: I'm a little confused. gpio_hold_en() should be used when device is NOT in deep_sleep.
Need to study the docs again..

Thanks

Hi Everybody, I need to retain a GPIO which is not in RTC controller (in my case GPIO22) in deepsleep. Below it is a simple test: -application setup GPIO22 as output and it is turned on. -a wake-up timer of 5 seconds is setup -esp32 is put in deep_sleep -a wake stub is provided to setup GPIO22 as ou...

Thanks @ESP_igrr! Works great from both main program (using rtc_gpio_hold_en / dis) and from ULP (using individual registers and bits). EDIT: A short description how to use hold enable / disable functionality together with an ULP program is available under https://github.com/krzychb/ulp-loop Hi @kr...

Thanks @WiFive. Got it.

Hi eveybody, I'm testing mDNS component and I have setup it using this simple code: //initialize mDNS service esp_err_t err = mdns_init(); if (err) { ESP_LOGW(TAG_WIFI, "MDNS Init failed: 0x%X\n", err); } else { //set hostname mdns_hostname_set("avior"); //set default instance mdns_instance_name_set...

Thanks @ESP_Angus for confirmation.

I will go through the proposed solution.

Thank you.

I flashed the "adc" example in ESP-IDF which route to GPIO26 the Vref. I was expected to find 1114mV, but in reality I measure 1100mV (the "per-design" reference voltage). A difference of 114mV seems abnormal. Are you sure you're measurement equipment is correct? Could you also call espefuse.py sum...