Additional current draw in Deep Sleep+ULP if WiFi.begin() called

[boarchuz]

I have a ULP program that reads a rotary encoder and wakes the cores when input is detected, then WiFi is connected to do work, then back into Deep Sleep. While testing low power consumption, I observed this (where 'WiFi.begin?' = Whether or not WiFi.begin() was called before entering Deep Sleep; 'ULP Program?' = Whether or not ULP program is loaded and running):

Code: Select all

WiFi.begin? - ULP Program? - Deep Sleep (uA)
      N     -       N      -       ~8
      Y     -       N      -       ~8
      N     -       Y      -      142
      Y     -       Y      -      270

(The 142uA is as expected, based on a ULP wakeup period of 1ms)

But if WiFi.begin() is called before entering Deep Sleep, it rises to 270uA!? Why? That one line, WiFi.begin(), is literally the only difference; comment it out and it's back to 142uA. On the other hand, if I include WiFi.begin and I comment out ulp_run, then everything also successfully powers down and current draw is <10uA.

Put simply: It's only when the two - WiFi and ULP - are in combination that the mysterious extra current is drawn.

Additionally, it seems to scale with the frequency of the ULP program running (ie. by varying ulp_set_wakeup_period).

Code: Select all

ULP Interval (ms) - WiFi.begin (uA) - No WiFi (uA) - Difference (uA)
         1        -       270       -     142      -      128
         2        -       153       -      86      -       67
         3        -       109       -      63      -       46
         5        -        70       -      43      -       27
        10        -        40       -      26      -       14

This would seem to indicate that the mysterious extra current caused by WiFi.begin is only being drawn when the ULP coprocessor is actually running the program, not while sleeping.

Why would this be? Is there anything I can do to power down whatever WiFi.begin() is causing to be powered while the ULP coprocessor is running in Deep Sleep?

More:

• Waking from high current, then going back to Deep Sleep without WiFi.begin resets current draw back down to expected

• Going back to Deep Sleep from a wake stub does not reset it, ie. high current draw persists

[dmaxben]

Ive noticed this problem too...

In my program, if I initialize WiFi and then want to put the ESP32 in light-sleep, it uses 1.5-2mA more than if I never initialized WiFi at all.

Ive tried calling:

esp_wifi_stop()
WiFi.mode(WIFI_OFF);
esp_wifi_set_mode(WIFI_MODE_NULL)

None of them COMPLETELY shut off the WiFi. There is an odd 1.5-2mA additional current draw if the WiFi has been initialized previously by the problem. Ive also tried suspending the task that the WiFi stuff is running in.

Comment out WiFi.begin (never start WiFi at all), and it does not draw that extra phantom current...

Ben

[ESP_igrr]

This is a regression in recent versions of ESP-IDF. We are working on a fix. For now you can add a call 'adc_power_off();' (from driver/adc.h) right before entering deep sleep.

[dmaxben]

This is a regression in recent versions of ESP-IDF. We are working on a fix. For now you can add a call 'adc_power_off();' (from driver/adc.h) right before entering deep sleep.

Excellent! Thank you.

Do we have to call adc_power_on(); when the ESP32 wakes up from light sleep? Or is ADC re-enabled when it wakes up from light-sleep?

[boarchuz]

This is a regression in recent versions of ESP-IDF. We are working on a fix. For now you can add a call 'adc_power_off();' (from driver/adc.h) right before entering deep sleep.

Tested and confirmed! Thankyou!

[ESP_igrr]

Do we have to call adc_power_on(); when the ESP32 wakes up from light sleep? Or is ADC re-enabled when it wakes up from light-sleep?

If you are using ADC1 or ADC2, then you need to enable it after waking up. Otherwise if you aren't using the ADC you don't need to do this.