the hunt for esp32-s3 deep sleep current leakage

[rozzie]

Hello again. I am designing what will be a high-volume product that is based on the ESP32-S3-WROOM-1-N8R2.

The design has relatively complex firmware, and a fairly simple hardware design of just a regulator and a couple simple i2c peripherals.

It is existential that the design is able to achieve reasonably low current draw in its 'active idle' state, which involves putting the ESP32 in deep sleep while the ESP32 powers-down the peripherals. The target budget is approx 10uA for the entire module.

I am reasonably experienced at low power design, and the typical things that one runs into when designing for boards that operate in the 5-10uA range. In the past I've mostly used stm32l4's, and this is my first experience trying to do a low-power design with the esp32.

With that as background, I've just done my first spin and I'm having significant challenges. The purpose of this note is NOT to try to get you to do my job. But if you can point me in the right direction through hints or elimination, it will save me a lot of time and I would deeply appreciate it.

My hardware design uses a variety of non-RTC GPIOs to control the mosfets that gate power to the peripherals, and it uses RTC GPIOs for the inputs that must cause wakeup from deep sleep. Before entering deep sleep, my firmware ensures that all the non-RTC GPIOs use "hold" to keep outputs configured as low, high, or 'floating' (disabled) as appropriate, and that all the RTC GPIO inputs are configured appropriately. (Happy to supply details if this matters.)

My firmware requires retaining deep sleep state in the 8kb RTC ram. I am a straight (if large) esp-idf app. I built the hardware with a 32Khz crystal and use a combination of the RTC timer and the RTC gpio's to wake up either by timer or by external event.

Finally, I'll say that going into deep sleep, coming out of deep sleep, etc., is working perfectly.

However, when in deep sleep the best current draw I can achieve is about 970µA, which is of course insanely high given that the datasheet (4.4 Table 12) says that 8µA should be my expectation with RTC memory and peripherals enabled as they are.

I have spent two solid days trying to verify that all the peripherals are truly powered off, and that there is no leakage through the obvious paths of pulldowns and whatnot. When I measure voltages on the pins of the module, the only pins where I see any voltage at all are 3V3, EN, and IO0, as it should be. All UART and I2C pins are disabled/floating and there are no external pullups.

And so ... the simple question for you is ... is there something obvious that I'm missing here in terms of calls that I need to make to shut off some internal power domains, etc., that would account for the stray ~950µA current draw? Anything related to the radio? JTAG?

If this were 5-10uA I was hunting for, it's a hunt that I'm super familiar with. But this level is kind of crazy.

Any ideas would be greatly appreciated. Thanks.

[boarchuz]

What ammeter are you using? Where exactly are you measuring this current? What power supply are you using?

What regulator are you using? What other external peripherals are connected? Can you share a schematic?

Do you have external bias resistors on the MOSFET gates? Have you confirmed Vgs is as expected on each?

Do you have a minimal S3 breakout board to test only the S3 current? Are you able to electrically isolate (desolder) external components to test their impact one-by-one? If you remove the 32kHz crystal, and change config to use internal oscillator, is there any change?

If you create a new project where you only rtc_gpio_isolate all RTC pins then enter deep sleep, what current do you see?

Can you reduce the code down to the bare minimum to reproduce this and share?

[rozzie]

Joulescope.

ISL9122AIINZ-T because low iQ

Yes the mosfet design is fine.

The next step is to destroy the pcb by removing the (smt) peripherals one by one. To date I have removed all the obvious things such as pull-ups, etc, but nothing that would be functionally destructive. The reason for this post was simply to ask what I might be missing prior to this step.

I hadn't even considered that the crystal would be a possibility but will also try removing that. It's just a standard ABS07-32.768KHZ-7-T plus caps, across IO15/IO16. (I use the crystal because I need my calendar-clock and ms timer both to advance accurately while potentially sleeping for hours or days,)

I will create a minimal project that can be shared.

In the meantime, it would be helpful if you can answer the question I was asking about firmware. I have been focused on hardware sources of leakage because I have been assuming that esp-idf knows what it is doing and is 'complete' in its powerdown. Assuming that all pins were disconnected except 32K crystal, and assuming the basic structure below, is there *anything* I need to do in *software* to disable drivers or power domains in order to achieve the 8uA target?

Or, conversely, are you confident that esp_deep_sleep_start() itself disables all internal peripherals?

To be super clear, these drivers are loaded and enabled at the moment of entering deep sleep: PSRAM and Flash, WiFi/LwIP, I2C units 0 (master) and 1 (slave), UART units 0 and 1, either JTAG or TinyUSB, RNG, ADC on a voltage measurement pin with a 4M/6M divider, WDT, and (obviously) 32Khz RTC and RTC RAM. IO0 and EN both remain pulled up to 3V3 under the assumption that these are not problematic. I have done RTC gpio isolate on the other strapping pins (which are NC) as a cautious measure.

If your experience dictates that I can have absolute confidence in the fact that esp_deep_sleep_start is complete in its shutdown of internal functions and power domains without my software needing to cooperatively unwind things, I will proceed to get out the microscope and soldering iron.

Thanks for your guidance.

##

// Enable RTC pin power domain
esp_sleep_pd_config(ESP_PD_DOMAIN_RTC_PERIPH, ESP_PD_OPTION_ON);

// Enable ext1 for wake-up on select RTC GPIO pins
esp_sleep_enable_ext1_wakeup(wakeupLowToHighPins, ESP_EXT1_WAKEUP_ANY_HIGH);

// Isolate and set pins to hold LOW to keep peripherals powered off
<omitted for brevity>

// Enable the timer wakeup
esperr = esp_sleep_enable_timer_wakeup(timeoutSecs * 1000000);
if (esperr != ESP_OK) {
return false;
}

// Enter deep sleep
esp_deep_sleep_start();

##

[boarchuz]

Yes, you should be able to achieve the specified deep sleep current.

An external RTC crystal will increase this, however. I've never used one so I don't know by how much exactly. There's a good chance this is the culprit, at least partially.

Yes, ESP-IDF will power down everything possible automatically upon entering deep sleep. You're not missing anything in software.

[rozzie]

Good news: I found the issue.

Bad news which should probably be paid attention to by Espressif engineers: it's arguably a bug in esp_deep_sleep_start().

By reduction, I found that this was the line of code that caused the sleep current to increase to 995µA. (I'd previously reported 970, but it was an error in my notes.)

Code: Select all

    adc_oneshot_unit_init_cfg_t init_config = { .unit_id = ADC_UNIT_1 };
    esperr = adc_oneshot_new_unit(&init_config, &adc_handle);

And so, just before the call to esp_deep_sleep_start(), I added:

Code: Select all

adc_oneshot_del_unit(adc_handle);

Now, during the deep sleep, the current is measured at 14.4µA, which is close enough to my 10µA budget for now.

Quite a relief to have found this. Thanks for your time.