Due to the board design constraints, customers are unable to directly measure low-power current on the development board. The presence of LEDs, CP2102, pull-up resistors, and pull-down resistors on the board can cause unnecessary current consumption. If you intend to develop a low-power application using the ESP32-C3, it is recommended to directly use the ESP32-C3 module and design your own custom board. The low-power description mentioned in the datasheet specifically refers to the low-power capabilities of the module itself.
Thank you.
ESP32-C3 power consumption doesn't match to the datasheet
Re: ESP32-C3 power consumption doesn't match to the datasheet
I am experiencing the same unexpectedly high current draw issue but have fully isolated all peripheral hardware from the ESP32-C3-MINI-1 module by cutting the 3.3 volt trace after the feed-in point to the module itself. Before isolation I was experiencing 600 uA current draw in deep sleep. With isolation I am getting 300 uA in deep sleep.
Hardware: ESP32-C3-DevKitM-1 with power minimizing hardware modifications.
Software:
-ESP-IDF v5.02
-Eclipse with IDF plugin
-"Deep Sleep" Example from version 5.02 of the IDF examples.
--"Deep Sleep" example has been modified in numerous ways from using as is, removing all wakeup sources in code, to surgically clearing all forced powerups and setting all force power down options in the rtc_sleep_configs. Nothing has lowered the 300 uA minimum current thus far.
I am powering directly from the 3.3V pin. I added a 10uF decoupling capacitor between the 3.3V input and ground since that was disconnected in the trace cutting process. I have connected a switch across the broken 3.3V trace so ESP32-C3-DevKitM-1 hardware can still be used for programming/debugging purposes. I have also disconnected all other periperal board components and resistors from the module to ensure full isolation. In essence I have reduced the hardware connections to the ESP32-C3-MINI-1 module to a capacitor and a pull-up on the EN pin. I have verified the minimization of the extra hardware on the board by pulling the EN pin down and recording a current draw of only 1 uA on the 3.3V line. I have verified interal low power voltage levels for RTC supply have been set at the lowest option. I have also manually disabled the UART clock in code to ensure that was not staying on at some level. I verified floating pins were not causing any issues by pulling each pin up and down while in deep sleep to measure current effects. The currents either remained static low or went up depending on whether some select pins were pulled up or down. GPIO8 was the only GPIO that cause the current to go up and was pulled up at the time.
My fundamental question is, can the ideal 5uA deep sleep current draw be achieved on the ESP32-C3-MINI-1 module? In order to achieve the lowest deep sleep possbile, will a board with a custom SOC based implentation have to be used instead of the module? Of course, any other insights into how to reduce the deep sleep current are welcome.
Code below is latest attempt at deep sleep reduction. I have also modified sleep.c and other rtc source files to manually set power down options prior to entering deep sleep.
rtc_sleep_config_t below is what sleep configs are set to immediatly prior to entering deep sleep. (Sleep function in sleep_modes.c: result = rtc_deep_sleep_start(s_config.wakeup_triggers, reject_triggers);)
config rtc_sleep_config_t {...}
lslp_mem_inf_fpu uint32_t 0
rtc_mem_inf_follow_cpu uint32_t 0
rtc_fastmem_pd_en uint32_t 1
rtc_slowmem_pd_en uint32_t 1
rtc_peri_pd_en uint32_t 1
wifi_pd_en uint32_t 1
bt_pd_en uint32_t 1
cpu_pd_en uint32_t 1
int_8m_pd_en uint32_t 1
dig_peri_pd_en uint32_t 1
deep_slp uint32_t 1
wdt_flashboot_mod_en uint32_t 0
dig_dbias_wak uint32_t 23
dig_dbias_slp uint32_t 5
rtc_dbias_wak uint32_t 23
rtc_dbias_slp uint32_t 5
dbg_atten_monitor uint32_t 0
bias_sleep_monitor uint32_t 0
dbg_atten_slp uint32_t 15
bias_sleep_slp uint32_t 1
pd_cur_monitor uint32_t 0
pd_cur_slp uint32_t 1
vddsdio_pd_en uint32_t 1
xtal_fpu uint32_t 0
deep_slp_reject uint32_t 1
light_slp_reject uint32_t 1
Apologies for the long post.
Hardware: ESP32-C3-DevKitM-1 with power minimizing hardware modifications.
Software:
-ESP-IDF v5.02
-Eclipse with IDF plugin
-"Deep Sleep" Example from version 5.02 of the IDF examples.
--"Deep Sleep" example has been modified in numerous ways from using as is, removing all wakeup sources in code, to surgically clearing all forced powerups and setting all force power down options in the rtc_sleep_configs. Nothing has lowered the 300 uA minimum current thus far.
I am powering directly from the 3.3V pin. I added a 10uF decoupling capacitor between the 3.3V input and ground since that was disconnected in the trace cutting process. I have connected a switch across the broken 3.3V trace so ESP32-C3-DevKitM-1 hardware can still be used for programming/debugging purposes. I have also disconnected all other periperal board components and resistors from the module to ensure full isolation. In essence I have reduced the hardware connections to the ESP32-C3-MINI-1 module to a capacitor and a pull-up on the EN pin. I have verified the minimization of the extra hardware on the board by pulling the EN pin down and recording a current draw of only 1 uA on the 3.3V line. I have verified interal low power voltage levels for RTC supply have been set at the lowest option. I have also manually disabled the UART clock in code to ensure that was not staying on at some level. I verified floating pins were not causing any issues by pulling each pin up and down while in deep sleep to measure current effects. The currents either remained static low or went up depending on whether some select pins were pulled up or down. GPIO8 was the only GPIO that cause the current to go up and was pulled up at the time.
My fundamental question is, can the ideal 5uA deep sleep current draw be achieved on the ESP32-C3-MINI-1 module? In order to achieve the lowest deep sleep possbile, will a board with a custom SOC based implentation have to be used instead of the module? Of course, any other insights into how to reduce the deep sleep current are welcome.
Code below is latest attempt at deep sleep reduction. I have also modified sleep.c and other rtc source files to manually set power down options prior to entering deep sleep.
- #include <stdio.h>
- #include <string.h>
- #include <stdlib.h>
- #include <time.h>
- #include <sys/time.h>
- #include <inttypes.h>
- #include "sdkconfig.h"
- #include "soc/soc_caps.h"
- #include "freertos/FreeRTOS.h"
- #include "freertos/task.h"
- #include "esp_sleep.h"
- #include "esp_log.h"
- #include "driver/rtc_io.h"
- #include "soc/rtc.h"
- #include "nvs_flash.h"
- #include "nvs.h"
- void app_main(void)
- {
- vTaskDelay(20000 / portTICK_PERIOD_MS);
- esp_sleep_pd_config(ESP_PD_DOMAIN_XTAL, ESP_PD_OPTION_OFF);
- esp_sleep_pd_config(ESP_PD_DOMAIN_CPU, ESP_PD_OPTION_OFF);
- esp_sleep_pd_config(ESP_PD_DOMAIN_RTC8M, ESP_PD_OPTION_OFF);
- esp_sleep_pd_config(ESP_PD_DOMAIN_VDDSDIO, ESP_PD_OPTION_OFF);
- esp_sleep_disable_wakeup_source(ESP_SLEEP_WAKEUP_ALL);
- // enter deep sleep
- esp_deep_sleep_start();
- }
config rtc_sleep_config_t {...}
lslp_mem_inf_fpu uint32_t 0
rtc_mem_inf_follow_cpu uint32_t 0
rtc_fastmem_pd_en uint32_t 1
rtc_slowmem_pd_en uint32_t 1
rtc_peri_pd_en uint32_t 1
wifi_pd_en uint32_t 1
bt_pd_en uint32_t 1
cpu_pd_en uint32_t 1
int_8m_pd_en uint32_t 1
dig_peri_pd_en uint32_t 1
deep_slp uint32_t 1
wdt_flashboot_mod_en uint32_t 0
dig_dbias_wak uint32_t 23
dig_dbias_slp uint32_t 5
rtc_dbias_wak uint32_t 23
rtc_dbias_slp uint32_t 5
dbg_atten_monitor uint32_t 0
bias_sleep_monitor uint32_t 0
dbg_atten_slp uint32_t 15
bias_sleep_slp uint32_t 1
pd_cur_monitor uint32_t 0
pd_cur_slp uint32_t 1
vddsdio_pd_en uint32_t 1
xtal_fpu uint32_t 0
deep_slp_reject uint32_t 1
light_slp_reject uint32_t 1
Apologies for the long post.
Re: ESP32-C3 power consumption doesn't match to the datasheet
Figured it out. On my dev board resistor to the smart LED hardware was not fully removed and the source of the high deep sleep current.
Who is online
Users browsing this forum: No registered users and 96 guests