ESP32 Deep Sleep Current Draw with MCUboot

[tuna-f1sh]

Hello!

Got a challenging one. I'm developing for a ESP32S3 WROOM1 N16R16 - custom board with a workspace 'boards/' definition.

I successfully configured deep sleep when flashing the app directly. Current draw is ~140 uA (LDO and other bits on board create higher than ESP32S3 datasheet 8 uA, this is ok). If I build with --sysbuild, no hardware changes, only partitioning the deep sleep current increases by a factor > 10 to ~1.8 mA.

I've configured to use the SPIRAM with CONFIG_SPIRAM_MODE_OCT but this is the same for both the non-sysbuild and sysbuild. I'm using a RTC GPIO as the wake source, configured with:

esp_sleep_disable_wakeup_source(ESP_SLEEP_WAKEUP_ALL);
esp_sleep_disable_ext1_wakeup_io(0);
...
esp_sleep_enable_ext1_wakeup_io(BIT(vdd_det.pin), ESP_EXT1_WAKEUP_ANY_HIGH);

Deep sleep is entered with sys_poweroff().

I wonder if anyone with experience developing the ESP32 support has any ideas on what could being configured differently with MCUboot? I feel like it must be something at the MCUboot init stage and jump to the app.

What I've tried but doesn't seem to have made a difference:

• Adding esp_sleep_config_gpio_isolate(); ref
• Adding CONFIG_ESP_SLEEP_FLASH_LEAKAGE_WORKAROUND=y, CONFIG_ESP_SLEEP_PSRAM_LEAKAGE_WORKAROUND=y, CONFIG_ESP_SLEEP_MSPI_NEED_ALL_IO_PU=y - I know these should only relate to light sleep but...
  ref

Thanks!

[tuna-f1sh]

I think I got to the problem after checking peripheral register stages and finding no difference, manually setting esp_sleep_pd_config(..) for peripherals etc. with no fix.

I was calling sys_poweroff() to go into deep sleep. If call esp_deep_sleep_start() directly, the current draw is the same and as expected (140 uA) for the MCUboot build too. I still am not sure why there would be a difference between solo app and --sysbuild since they both call

zephyr/soc/espressif/esp32s3/poweroff.c

Line 10 in 3568e1b

void z_sys_poweroff(void)

.

I believe the issue is

zephyr/soc/espressif/esp32s3/poweroff.c

Line 13 in 3568e1b

esp_sleep_pd_config(ESP_PD_DOMAIN_RTC_PERIPH, ESP_PD_OPTION_ON);

forcing esp_sleep_pd_config(ESP_PD_DOMAIN_RTC_PERIPH, ESP_PD_OPTION_ON);.

I'm not sure why this is forced since it's handled in the HAL depending on if EXT0 is used: https://github.com/zephyrproject-rtos/hal_espressif/blob/c95b9e4781390ca2eafe10342b69fb11673e514e/components/esp_system/sleep_modes.c#L1280

[sylvioalves]

@raffarost would you take a look?

[tuna-f1sh]

Thanks for pinging this. I understand it's a hard thing to suggest and debug. Whilst using esp_deep_sleep_start seems to help on my custom hardware bringing the delta from mA range to uA, I still have a delta of between 10-45 uA when MCUboot is enabled.

I've been able to reproduce this with the deep_sleep sample with a ESP32S3 WROOM 1U DevKitC (D5 and R24 removed for powering from power profiler).

The difference on a esp32s3_devkitc is ~ 10 uA between --sysbuild and not. Any ideas? I disable the wake timer for the sample test: no-timer.patch

west build -b esp32s3_devkitc/esp32s3/procpu:

west build -b esp32s3_devkitc/esp32s3/procpu -d build-sys --sysbuild

[tuna-f1sh]

I noticed the spike in the power on region on the --sysbuild build not present on the single image. The MCUboot load does seem to spike at 177 mA vs ~135 mA for the deep sleep sample. So I'm thinking there are some differently configured peripherals that are left in deep sleep?

[richardnhunt]

I have spent a couple of days isolating a similar situation on my ESP32 WROOM32E custom board. Without mcuboot/sysbuild the idle current was 0.8mA in deep sleep (high due to some known board issues), but building with it the current became 2.2mA. I confirmed mcuboot wasn't enabling anything extra that my app wasn't already configuring, force/power down flags all the same, and registers associated with sleep the same.

In the end I methodically tracked the code through modules\hal\espressif\components\esp_hw_supportsleep_modes.c into misc_modules_sleep_prepare(). Here the function ends with:

    // TODO: IDF-7370
    //
    if (!s_adc_tsen_enabled) {
        sar_periph_ctrl_power_disable();
    }
}

Commenting out the check of !s_adc_tsen_enabled resolves my issue, i.e. this gets me back to 0.8mA:

    // TODO: IDF-7370
    //
    //if (!s_adc_tsen_enabled)
    {
        sar_periph_ctrl_power_disable();
    }
}

I haven't investigated yet what is causing this flag to be set, but the Espressif TODO: IDF-7370 is a little suspicious! Not sure how relates to your resolution, perhaps just a coincidence with the same magnitude issue - either way hopefully the above will help others who find this page.

[richardnhunt]

I had just about root caused my issue, having been prompted by the comment below, when I found the solution in https://chromium.googlesource.com/chromiumos/third_party/zephyrproject/+/d60d59f9f65477998d014dd54552bb428ad7bee4%5E%21/#F0 which describes the issue perfectly. This patch fixes my problem above on WROOM32 ESP32.

[tuna-f1sh]

Good to hear. This looks lke the same diff as #118348 so should be fixed in main now.

[tuna-f1sh]

Yet to test but #118348 sounds like a potential fix.