Low power deep sleep issues WROOM-32 vs PICO-D4 (IDFGH-3624)

[tabulous]

this code give completely differnet results on the above modules.

WROOM-32 deep sleeps at 5uA this is as expected.
PICO-D4 will only deep sleep at 500uA.... !!!!!!

I believe there is a silicon issue on the PICO-D4 ? why would they be so diffferent ?

void app_main(void)
{

while(true)
{

printf("Sleeping in 5 second(s)");
vTaskDelay(5000 / portTICK_PERIOD_MS);

printf("Entering deep sleep now!!");
esp_sleep_enable_timer_wakeup(10 * 1000000);
esp_deep_sleep_start();

}
}

note both units are on mininal boards i.e. only pullup on EN and decoupling caps.....

[tabulous]

Here is the units under test, as you can see these boards are bare, just the modules and some decouple caps.

IMG_20200706_143523.jpg (1.4 MiB) Viewed 8091 times

[tabulous]

Bump.........
Come on support !!! where are you ?

[ESP_Angus]

Hi tabulous,

Thanks for being patient while someone got back to you.

You're right that 500uA is much higher than expected for ESP32-PICO-D4 deep sleep power consumption. The deep sleep consumption is tested as part of the manufacturing process, but it may be that you have a bad chip somehow.

I have a few questions to try and eliminate other causes:

• Have you enabled 32kHz crystal in config? I see what looks like a 32kHz crystal on the PICO-D4 board, is it possible this is causing increased consumption (either by being used, or from being connected and disabled?) We wouldn't expect a normal 32kHz crystal in deep sleep to increase by more than ~1uA, but good to rule this out.
• It is technically possible for floating I/Os to increase power consumption in low power modes. Although the input drivers should be disabled in the deep sleep mode as no pin wakeups are enabled in your app. Will double check this, but if you're able to try temporarily bridging some of the unused IO to ground and check for a change of consumption then this will also quickly rule it out.
• Which ESP-IDF version are you using?
• Are you able to share the MAC address of the PICO-D4, please? We can check the deep sleep consumption that was recorded during manufacturing test for comparison.

Thanks,

Angus

[tabulous]

Hi Angus,
here is my answers to your questions

32Khz - even with this removed and the sdkconfig set to defaults "RTC and high-resolution timer" and "Internal 150khz RC Osc" its still 500uA

On the PINs - i would expect this is cause an issue with the zoom module too then, but it doesn't. I can try this but its no easy to pull all the pins low.

ESP-IDF version is - 4.0-beta2

MAC of the PICO-D4 - Ive now removed all the part from the board an am awaiting some new samples.

I also see you have a newer varient out of this, the PICO-V3 what is the reason and what does this revision address ?

KR

Lee

[ESP_Angus]

Hi Lee,

Thanks for the extra details. I'm able to reproduce this here on a PICO-D4. We'll continue investigating.

Similar hardware setups (with PICO-D4) have been measured at much lower power consumption in the past, so I am fairly sure this is a software regression. The internal configuration of the WROOM and the PICO-D4 is similar but not 100% the same.

I've added our internal tracking number to the title of the thread.

I also see you have a newer varient out of this, the PICO-V3 what is the reason and what does this revision address ?

The PICO-V3 is a new product with very similar features. The main differences are that it uses ESP32 ECO3 silicon revision [PDF] , and that the flash pins are no longer broken out to pads. Consequently they are not 100% pin compatible. Consult the ESP32-PICO-V3 datasheet [PDF] section 3.2 "Compatibility with ESP32-PICO-D4" for the full list of differences.

[tabulous]

Hi Angus
thankyou for this, will look forward to your response and hopefully a solution

KR

[ESP_Angus]

Hi Lee,

Unfortunately, I re-tested the PICO today and realised I made a mistake - after cleaning the board of flux residue properly and removing some components that I thought were not contributing to deep sleep power draw, I can no longer reproduce this. We're seeing proper deep sleep currents (<10uA) for PICO-D4 chips on minimal boards, similar to your setup.

We still think it's possible that some of the floating IOs on the board are picking up stray charge and causing the input gates to leak current. This is not normally a problem, but a bare PCB like this with long unconnected traces is close to worst-case. Exactly where the charge ends up and which IO it may charge to ~0.5V VCC is hard to predict which may explain why one board layout shows this and the other doesn't.

You can explicitly disconnect all of the IO pads in deep sleep by running the following code immediately before going to deep sleep:

Code: Select all

#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "esp_sleep.h"
#include "driver/rtc_io.h"

void app_main(void)
{
    printf("Sleeping in 5 second(s)\n");
    vTaskDelay(5000 / portTICK_PERIOD_MS);

    printf("Entering deep sleep now!!\n");
    esp_sleep_enable_timer_wakeup(5 * 1000000);

    for (int i = 0; i < 32; i++) {
        rtc_gpio_isolate(i);
    }

    esp_deep_sleep_start();
}

(This is also the code I used for testing, based on your original code.)

(Note: On master branch this code logs a number of errors as we brute-force isolate every GPIO, not just the RTC-enabled GPIOs. The non-RTC GPIOs log an error line. No errors are logged on v4.0-beta2 - the function returns an error, but caller doesn't check it.)

Again, a heavy-handed approach like this is not usually necessary but it should rule out the IOs being a factor.

Some more questions to help rule things out:

• As you've removed the PICO, could you please double-check the current consumption of the board without the PICO on it? This is to help rule out anything else on the board, or something in the board itself like a high-resistance bridge between two power traces, etc.
• What supply voltage are you using?
• If you get another sample and it exhibits the same behaviour, we can look up the MAC to double-check the expected deep sleep consumption that was recorded at manufacturing time.