ESP32-H2 will nicht schlafen

[Olli Z. (z80freak)]

Ich habe ein kleines Projekt erstellt in dem ich mit einem ESP32-H2 eine 
Art Zeitschaltuhr gebaut habe. Das ganze ist Batteriebetrieben und soll 
möglichst wenig Strom verbrauchen. Dazu schalte ich mittels

esp_light_sleep_start();

den ESP nach kurze Inaktivität bei der Bedienung in den Schlafmodus. 
Hier hätte ich erwartet das die Stromaufnahme deutlich sinkt, tut sie 
aber nicht, im Gegenteil, es entstehen "Bursts", so als wolle er nicht 
wirklich ruhen. Irgendwas reißt ihn mit 200 HZ aus dem Schlaf.

Mein Sleep-Code schaut aktuell so aus:

void go_to_sleep() {
    ESP_LOGI(TAG, "Time to sleep! zzzzZZZ...\n");
    vTaskDelay(pdMS_TO_TICKS(100));

    iot_button_stop();
    xTimerStop(inactivity_timer, 0);

    esp_sleep_disable_wakeup_source(ESP_SLEEP_WAKEUP_ALL); // disable ALL wakeup sources (just for safety)

    gpio_wakeup_enable(BUTTON_GPIO, GPIO_INTR_HIGH_LEVEL); // LOW -> HIGH wakeup
    esp_sleep_enable_gpio_wakeup();

    // USB-CDC vor Sleep deaktivieren
    usb_serial_jtag_driver_uninstall();

    sleep_indicator_sleeping(); // set GPIO4 to HIGH

    // SLEEP
    esp_light_sleep_start();

    sleep_indicator_awake(); // set GPIO4 to LOW

    // USB-CDC nach Sleep neu starten
    reinit_usb_cdc();

    ESP_LOGI(TAG, "Uuaaa, i woke up!\n");
    esp_sleep_wakeup_cause_t wakeup_reason = esp_sleep_get_wakeup_cause();
    ESP_LOGI(TAG, "Wakeup reason: %d", wakeup_reason);

    iot_button_resume();
    vTaskDelay(pdMS_TO_TICKS(500));
    
    xTimerReset(inactivity_timer, 0);
}

Problem bei der Sache ist auch das Debugging. Wenn ich das Super-Mini 
Board am USB lasse für Logmeldungen, kann ich keine Strommessung 
durchführen weil es ja direkt vom USB versorgt wird und im anderen Fall 
habe ich kein USB und somit kein Log :-/ Und im reinen USB-Modus sehe 
ich nach dem Sleep nichts mehr weil sich die Console abkoppelt und nicht 
automatisch wieder aufnimmt.

[Nemopuk (nemopuk)]

Unterscheide zwischen Light- und Deep- Sleep, dann verstehst du das 
beobachtete Verhalten. Works as designed.

[Niklas G. (erlkoenig)]

Olli Z. schrieb:
> Irgendwas reißt ihn mit 200 HZ aus dem Schlaf.

Das ist doch der Tick vom RTOS. Der Light-Sleep ist sowieso nicht 
besonders effektiv, ist eher so wie der "Idle" Mode beim Cortex-M  (also 
nur WFI) - praktisch die Alternative zu Busy-Wait, aber ohne dass die 
Peripherie (und damit auch der Tick Timer) davon beeinflusst würden.

Daher brauchst du den Deep-Sleep.

[Olli Z. (z80freak)]

Deep-Sleep kann (will) ich nicht nehmen, da während dem Sleep das PWM 
weiter erzeugt werden soll der meine externe LED auch während dem Sleep 
weiter auf Helligkeit hält.

Also ihr seid der Meinung das das OK so ist? Wenn ich ein Mittel nehme, 
dann ist es vor dem Sleep 16,5 mA und während dem Sleep 5,5 mA. Immerhin 
ein Drittel weniger.

Im Sleep kann doch von RTOS nichts mehr ausgeführt werden, wie soll das 
denn bitteschön gehen? Die CPU ist angehalten. Davon ab ist die RTOS 
Tick Frequenz bei mir auf Default 100 Hz.

[Niklas G. (erlkoenig)]

Olli Z. schrieb:
> Das finde ich seltsam, warum sollte der Hersteller das so designen?

Weil's billiger ist. Low-Power Halbleiter Herstellung kostet halt, und 
das Hauptargument für die ESP32 ist der Preis.

Olli Z. schrieb:
> Und im Sleep kann doch von RTOS nichts mehr ausgeführt werden, wie soll
> das denn bitteschön gehen?

Der Sinn ist doch, dass nichts mehr ausgeführt wird, um Energie zu 
sparen...

Olli Z. schrieb:
> Die CPU ist angehalten.

Wenn die CPU an ist, verbraucht sie Strom - im Falle der ESP32 halt 
viel Strom.

Olli Z. schrieb:
> da während dem Sleep das PWM weiter erzeugt werden soll.

PWM und Stromsparend geht nicht bei ESP32.

Andere Controller wie z.B. die STM32Uxx haben spezielle Low-Power Timer 
die auch im "Stop" Mode eine PWM ausgeben können. Dafür ist natürlich 
trotzdem eine Taktquelle nötig, z.B. der 32 kHz Uhrenquartz - das grenzt 
die PWM-Frequenz und -Auflösung ein. Das verbraucht dann Größenordnung 
10-30 μA.

[Olli Z. (z80freak)]

Hm, wenn ich in meinem Code "esp_light_sleep_start();" durch 
"esp_deep_sleep_start();" ersetze ändert das nichts an der Stromaufnahme 
und Charakteristik. Ist das auch "by Design"?

[Olli Z. (z80freak)]

Niklas G. schrieb:

> Andere Controller wie z.B. die STM32Uxx haben spezielle Low-Power Timer
> die auch im "Stop" Mode eine PWM ausgeben können. Dafür ist natürlich
> trotzdem eine Taktquelle nötig, z.B. der 32 kHz Uhrenquartz - das grenzt
> die PWM-Frequenz und -Auflösung ein. Das verbraucht dann Größenordnung
> 10-30 μA.

Genau das kann der ESP32 auch und so habe ich es auch konfiguriert. Das 
klappt aber nur im Light-Sleep.

[Niklas G. (erlkoenig)]

Leg doch mal ein Minimal-Programm an das nur esp_deep_sleep_start() 
aufruft und sonst nichts. Vielleicht muss man da auch was im menuconfig 
aktivieren

[Niklas G. (erlkoenig)]

Olli Z. schrieb:
> Genau das kann der ESP32 auch und so habe ich es auch konfiguriert. Das
> klappt aber nur im Light-Sleep.

Kann er nicht, weil er dafür den aktiven Haupttakt benötigt. Was nur im 
Light-Sleep der Fall ist, weil da das ganze System "an" ist, nur die CPU 
selbst nicht. Spezifische Low-Power-Controller wie u.a. die STM32Uxx 
können es auch ohne Haupttakt.

[Olli Z. (z80freak)]

Niklas G. schrieb:
> Leg doch mal ein Minimal-Programm an das nur esp_deep_sleep_start()
> aufruft und sonst nichts. Vielleicht muss man da auch was im menuconfig
> aktivieren

Genau das hatte ich jetzt auch gemacht um mal alle anderen Fehlerquellen 
auszuschließen. Dazu verwende ich nur die Power-Meter Funktion vom PPK2 
und übergehe sogar den Spannungsregler auf dem EPS32-H2 Super-Mini Board 
indem ich direkt 3,3V auf dem ausgeführten Pin erzeuge. Das Board habe 
ich komplett unbeschaltet mit folgendem Code

#include <stdio.h>
#include "freertos/FreeRTOS.h" // FreeRTOS
#include "freertos/task.h" // Tasks
#include "esp_log.h"    // Logging
#include "esp_sleep.h" // Sleep

static const char *TAG = "sleep-test";
void app_main(void)
{
    while (1)
    {
        vTaskDelay(pdMS_TO_TICKS(10000));
        //esp_light_sleep_start();
        esp_deep_sleep_start();
    }
}

Im Deep-Sleep verbraucht er dann 345 µA (viel zu hoch) und im 
Light-Sleep 480 µA (auch zu hoch, aber wäre ok).

[Niklas G. (erlkoenig)]

Grundsätzlich gibt es eine Menge möglicher Ursachen für zu hohen 
Stromverbrauch im Standby.

Floatende Pins sind der Klassiker, weil dann der Input-Schmitt-Trigger 
oszilliert. Typischerweise sollte man alle unbeschalteten Pins und alle 
Input-Pins auf Pull-Up/Down setzen, bei den STM32 hingegen auf "Analog".

Eventuell sind noch irgendwelche Peripherie-Einheiten aktiv, Flash nicht 
abgeschaltet, zusätzliche ICs auf dem ESP32-Modul nicht 
abgeschaltet/abschaltbar, irgendwelche Interrupts sind "Pending" beim 
Sleep-Eintritt...

[Rolf (rolf22)]

Olli Z. schrieb:
> Im Sleep kann doch von RTOS nichts mehr ausgeführt werden, wie soll das
> denn bitteschön gehen? Die CPU ist angehalten.

Die CPU könnte durch vorprogrammierte Interrupts zwischendurch kurz 
aufgeweckt werden und dann eine Interruptbehandlungs-Routine oder mehr 
durchlaufen.

[Olli Z. (z80freak)]

Ok, dann vielleicht nochmal von vorn. Ich nehme einen nackten ESP32-H2 
auf einem Board (Waveshare-Super-Mini Clone von Wrtysully). Ich 
programmiere das in Visual Studio Code (VS Code) mit dem Espressif-IDF 
5.5.2 (ESP-IDF), habe also grundsätzlich vollen Zugriff auf alles was 
der ESP32 so kann.

Die Sleep-Modes sind hier erklärt (API): 
https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/system/sleep_modes.html

Ich verwende folgenden, minimalistischen Code

#include <stdio.h>
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "esp_sleep.h"
#include "esp_log.h"
#include "esp_err.h"

static const char *TAG = "EPS32-SLEEP-TEST";

void app_main(void)
{
    ESP_LOGI(TAG, "Sleep Test with USB disconnected (Battery driven, after LDO)");

    vTaskDelay(pdMS_TO_TICKS(5000));
    
    // Alle Wakeup-Signale deaktivieren
    esp_sleep_disable_wakeup_source(ESP_SLEEP_WAKEUP_ALL);

    ESP_LOGI(TAG, "Entering sleep NOW");
    vTaskDelay(pdMS_TO_TICKS(100));
    
    esp_deep_sleep_start();
    
    vTaskDelay(pdMS_TO_TICKS(100));
    
    ESP_LOGI(TAG, "Woke up! Wakeup cause: %d", esp_sleep_get_wakeup_cause());
    
    while(1) {
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

Den Flashe ich auf den ESP und schaue mir erstmal die Debug-Console an:

PS D:\Dev\code\sleep-test>  & 'C:\Users\localuser\.espressif\python_env\idf5.5_py3.11_env\Scripts\python.exe' 'C:\Users\localuser\esp\v5.5.1\esp-idf\tools\idf_monitor.py' -p COM6 -b 115200 --toolchain-prefix riscv32-esp-elf- --make '''C:\Users\localuser\.espressif\python_env\idf5.5_py3.11_env\Scripts\python.exe'' ''C:\Users\localuser\esp\v5.5.1\esp-idf\tools\idf.py''' --target esp32h2 'd:\Dev\code\sleep-test\build\sleep-test.elf'
--- Warning: GDB cannot open serial ports accessed as COMx
--- Using \\.\COM6 instead...
--- esp-idf-monitor 1.8.0 on \\.\COM6 115200
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H
I (118) esp_image: segment 3: paddr=0002cf54 vaddr=408005fc sizeESP-ROM:esp32h2-20221101
Build:Nov  1 2022
rst:0x15 (USB_UART_HPSYS),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x408037e2
--- 0x408037e2: rv_utils_wait_for_intr at C:/Users/localuser/esp/v5.5.1/esp-idf/components/riscv/include/riscv/rv_utils.h:79
--- (inlined by) esp_cpu_wait_for_intr at C:/Users/localuser/esp/v5.5.1/esp-idf/components/esp_hw_support/cpu.c:62
SPIWP:0xee
mode:DIO, clock div:1
load:0x408460f0,len:0x1700
load:0x4083c2d0,len:0xf78
load:0x4083efd0,len:0x2fdc
entry 0x4083c2da
I (23) boot: ESP-IDF v5.5.1 2nd stage bootloader
I (23) boot: compile time Dec  1 2025 20:00:32
I (24) boot: chip revision: v0.1
I (25) boot: efuse block revision: v0.3
I (26) boot.esp32h2: SPI Speed      : 64MHz
I (30) boot.esp32h2: SPI Mode       : DIO
I (34) boot.esp32h2: SPI Flash Size : 2MB
I (38) boot: Enabling RNG early entropy source...
I (42) boot: Partition Table:
I (45) boot: ## Label            Usage          Type ST Offset   Length
I (51) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (58) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (64) boot:  2 factory          factory app      00 00 00010000 00100000
I (71) boot: End of partition table
I (74) esp_image: segment 0: paddr=00010020 vaddr=42018020 size=079f4h ( 31220) map
I (90) esp_image: segment 1: paddr=00017a1c vaddr=40800000 size=005fch (  1532) load
I (92) esp_image: segment 2: paddr=00018020 vaddr=42000020 size=14f2ch ( 85804) map
I (118) esp_image: segment 3: paddr=0002cf54 vaddr=408005fc size=0c42ch ( 50220) load
I (134) esp_image: segment 4: paddr=00039388 vaddr=4080ca30 size=017b4h (  6068) load
I (137) esp_image: segment 5: paddr=0003ab44 vaddr=50000000 size=00080h (   128) load
I (142) boot: Loaded app from partition at offset 0x10000
I (143) boot: Disabling RNG early entropy source...
I (160) cpu_start: Unicore app
D (160) cpu_start: Pro cpu up
D (168) clk: RTC_SLOW_CLK calibration value: 3568288
D (173) cpu_start: calling init function: 0x42000232 on core: 0
--- 0x42000232: __esp_system_init_fn_init_efuse_check at C:/Users/localuser/esp/v5.5.1/esp-idf/components/efuse/src/esp_efuse_startup.c:37
D (174) cpu_start: calling init function: 0x42001486 on core: 0
--- 0x42001486: __esp_system_init_fn_init_show_cpu_freq at C:/Users/localuser/esp/v5.5.1/esp-idf/components/esp_system/startup_funcs.c:64
I (175) cpu_start: Pro cpu start user code
I (177) cpu_start: cpu freq: 96000000 Hz
D (181) cpu_start: calling init function: 0x420000e0 on core: 0
--- 0x420000e0: __esp_system_init_fn_init_show_app_info at C:/Users/localuser/esp/v5.5.1/esp-idf/components/esp_app_format/esp_app_desc.c:123
I (187) app_init: Application information:
I (190) app_init: Project name:     sleep-test
I (194) app_init: App version:      1
I (198) app_init: Compile time:     Dec 27 2025 14:11:52
I (203) app_init: ELF file SHA256:  f2e8d38af...
I (207) app_init: ESP-IDF:          v5.5.1
D (211) cpu_start: calling init function: 0x42000246 on core: 0
--- 0x42000246: __esp_system_init_fn_init_efuse_show_app_info at C:/Users/localuser/esp/v5.5.1/esp-idf/components/efuse/src/esp_efuse_startup.c:47
I (217) efuse_init: Min chip rev:     v0.0
I (220) efuse_init: Max chip rev:     v1.99
I (224) efuse_init: Chip rev:         v0.1
D (228) cpu_start: calling init function: 0x42003422 on core: 0
--- 0x42003422: __esp_system_init_fn_init_heap at C:/Users/localuser/esp/v5.5.1/esp-idf/components/heap/heap_caps_init.c:26
D (234) memory_layout: Checking 5 reserved memory ranges:
D (239) memory_layout: Reserved memory range 0x40800000 - 0x4080ca30
--- 0x40800000: _vector_table at C:/Users/localuser/esp/v5.5.1/esp-idf/components/riscv/vectors_intc.S:54
D (245) memory_layout: Reserved memory range 0x4080ca30 - 0x4080f280
D (251) memory_layout: Reserved memory range 0x4084fee0 - 0x40850000
D (257) memory_layout: Reserved memory range 0x50000000 - 0x50000080
--- 0x50000000: esp_wake_stub_entry at C:/Users/localuser/esp/v5.5.1/esp-idf/components/esp_hw_support/sleep_modes.c:374
D (263) memory_layout: Reserved memory range 0x50000fe8 - 0x50001000
D (269) memory_layout: Building list of available memory regions:
D (275) memory_layout: Available memory region 0x4080f280 - 0x40810000
D (282) memory_layout: Available memory region 0x40810000 - 0x40820000
D (288) memory_layout: Available memory region 0x40820000 - 0x40830000
D (294) memory_layout: Available memory region 0x40830000 - 0x40840000
D (300) memory_layout: Available memory region 0x40840000 - 0x4084d380
D (307) memory_layout: Available memory region 0x4084d380 - 0x4084fee0
D (313) memory_layout: Available memory region 0x50000080 - 0x50000fe8
I (319) heap_init: Initializing. RAM available for dynamic allocation:
D (325) heap_init: New heap initialised at 0x4080f280
I (330) heap_init: At 4080F280 len 0003E100 (248 KiB): RAM
I (335) heap_init: At 4084D380 len 00002B60 (10 KiB): RAM
D (340) heap_init: New heap initialised at 0x50000080
I (345) heap_init: At 50000080 len 00000F68 (3 KiB): RTCRAM
D (350) cpu_start: calling init function: 0x42001202 on core: 0
--- 0x42001202: __esp_system_init_fn_esp_timer_init_nonos at C:/Users/localuser/esp/v5.5.1/esp-idf/components/esp_timer/src/esp_timer_init.c:28
D (356) cpu_start: calling init function: 0x420075f6 on core: 0
--- 0x420075f6: __esp_system_init_fn_init_libc at C:/Users/localuser/esp/v5.5.1/esp-idf/components/newlib/src/init.c:12
D (362) cpu_start: calling init function: 0x420014fe on core: 0
--- 0x420014fe: __esp_system_init_fn_init_brownout at C:/Users/localuser/esp/v5.5.1/esp-idf/components/esp_system/startup_funcs.c:79
D (368) intr_alloc: Connected src 2 to int 1 (cpu 0)
D (372) cpu_start: calling init function: 0x42001520 on core: 0
--- 0x42001520: __esp_system_init_fn_init_newlib_time at C:/Users/localuser/esp/v5.5.1/esp-idf/components/esp_system/startup_funcs.c:104
D (378) cpu_start: calling init function: 0x42007604 on core: 0
--- 0x42007604: __esp_system_init_fn_init_libc_stdio at C:/Users/localuser/esp/v5.5.1/esp-idf/components/newlib/src/init.c:18
D (384) cpu_start: calling init function: 0x42001530 on core: 0
--- 0x42001530: __esp_system_init_fn_init_flash at C:/Users/localuser/esp/v5.5.1/esp-idf/components/esp_system/startup_funcs.c:111
D (389) spi_flash: trying chip: gd
I (392) spi_flash: detected chip: gd
I (395) spi_flash: flash io: dio
W (398) spi_flash: Detected size(4096k) larger than the size in the binary image header(2048k). Using the size in the binary image header.
D (410) cpu_start: calling init function: 0x420003a0 on core: 0
--- 0x420003a0: __esp_system_init_fn_init_efuse at C:/Users/localuser/esp/v5.5.1/esp-idf/components/efuse/src/esp_efuse_startup.c:158
D (416) efuse: BLK0 REG2 [24-27], len=4 bits
D (420) efuse: BLK0 REG2 [28-31], len=4 bits
D (424) efuse: BLK0 REG3 [0-3], len=4 bits
D (428) efuse: BLK0 REG3 [4-7], len=4 bits
D (432) efuse: BLK0 REG3 [8-11], len=4 bits
D (436) efuse: BLK0 REG3 [12-15], len=4 bits
D (440) cpu_start: calling init function: 0x408059fe
--- 0x408059fe: enable_timer_group0_for_calibration at C:/Users/localuser/esp/v5.5.1/esp-idf/components/esp_hw_support/port/esp32h2/rtc_time.c:279
D (444) cpu_start: calling init function: 0x40805e7c
--- 0x40805e7c: tlsf_set_rom_patches at C:/Users/localuser/esp/v5.5.1/esp-idf/components/esp_rom/patches/esp_rom_tlsf.c:167
D (449) cpu_start: calling init function: 0x4200294e on core: 0
--- 0x4200294e: __esp_system_init_fn_esp_hw_stack_guard_init at C:/Users/localuser/esp/v5.5.1/esp-idf/components/esp_system/hw_stack_guard.c:15
D (455) cpu_start: calling init function: 0x4200abba on core: 0
--- 0x4200abba: _lp_clkrst_ll_enable_rng_clock at C:/Users/localuser/esp/v5.5.1/esp-idf/components/hal/esp32h2/include/hal/lp_clkrst_ll.h:66
--- (inlined by) __esp_system_init_fn_init_rng at C:/Users/localuser/esp/v5.5.1/esp-idf/components/esp_hw_support/hw_random.c:109  
D (460) cpu_start: calling init function: 0x420037e8 on core: 0
--- 0x420037e8: __esp_system_init_fn_esp_security_init at C:/Users/localuser/esp/v5.5.1/esp-idf/components/esp_security/src/init.c:42
D (466) cpu_start: calling init function: 0x4200425a on core: 0
--- 0x4200425a: __esp_system_init_fn_esp_sleep_startup_init at C:/Users/localuser/esp/v5.5.1/esp-idf/components/esp_hw_support/sleep_gpio.c:225
I (472) sleep_gpio: Configure to isolate all GPIO pins in sleep state
I (478) sleep_gpio: Enable automatic switching of GPIO sleep configuration
D (484) cpu_start: calling init function: 0x42013cde on core: 0
--- 0x42013cde: __esp_system_init_fn_sleep_clock_startup_init at C:/Users/localuser/esp/v5.5.1/esp-idf/components/esp_hw_support/lowpower/port/esp32h2/sleep_clock.c:112
D (490) cpu_start: calling init function: 0x42001582 on core: 0
--- 0x42001582: __esp_system_init_fn_init_pm at C:/Users/localuser/esp/v5.5.1/esp-idf/components/esp_system/startup_funcs.c:142
D (507) cpu_start: calling init function: 0x42007ce4 on core: 0
--- 0x42007ce4: __esp_system_init_fn_usb_serial_jtag_conn_status_init at C:/Users/localuser/esp/v5.5.1/esp-idf/components/esp_driver_usb_serial_jtag/src/usb_serial_jtag_connection_monitor.c:75
D (508) cpu_start: calling init function: 0x42001592 on core: 0
--- 0x42001592: __esp_system_init_fn_init_disable_rtc_wdt at C:/Users/localuser/esp/v5.5.1/esp-idf/components/esp_system/startup_funcs.c:179
D (508) intr_alloc: Connected src 7 to int 2 (cpu 0)
D (512) app_start: Starting scheduler on CPU0
D (516) intr_alloc: Connected src 45 to int 5 (cpu 0)
I (516) main_task: Started on CPU0
D (516) heap_init: New heap initialised at 0x4084d380
D (516) intr_alloc: Connected src 42 to int 8 (cpu 0)
I (526) main_task: Calling app_main()
I (526) EPS32-SLEEP-TEST: Sleep Test with USB disconnected (Battery driven, after LDO)
I (5536) EPS32-SLEEP-TEST: Entering sleep NOW
--- Error: ClearCommError failed (PermissionError(13, 'Das Gerät erkennt den Befehl nicht.', None, 22))
--- Waiting for the device to reconnect........

Soweit ok, der ESP geht in den Deep-Sleep und dann bricht natürlich die 
Console ab.

Nun das ganze ohne USB und im Strommessbetrieb vom PPK2 hinter dem LDO 
vom ESP-Board versorgt => weiterhin 340 µA, viel zu hoch.

Was könnte ich nun falsch gemacht haben? Auf dem Board ist keine LED an 
und auch sonst keine weitere, besondere Zusatzhardware

[Niklas G. (erlkoenig)]

Olli Z. schrieb:
> Ich verwende folgenden, minimalistischen Code

Da mal Code einfügen um floating Pins zu vermeiden... Oder extern alle 
Pins auf einen definierten Pegel legen

[Nemopuk (nemopuk)]

Olli Z. schrieb:
> Auf dem Board ist keine LED an und auch sonst keine weitere, besondere
> Zusatzhardware

Kannst du mal einen Link zum Schaltplan posten?

[Alexander (alecxs)]

Ich hatte da vor kurzem ähnliches Problem, der ESP.restart() war nicht 
wirklich ein Reset. Geholfen hat mir dann die Lösung von Thomas M. 
(tom_holzwurm) https://www.mikrocontroller.net/topic/goto_post/7742869

Damit Copilot gefüttert und bezüglich esp_deep_sleep_start() nachgehakt. 
Kannste ja mal testen (zusätzlich zum Tipp von  Niklas):

#include "esp_sleep.h"
#include "esp_log.h"
#include "driver/usb_serial_jtag.h"
#include "esp_system.h"

void app_main(void)
{
    vTaskDelay(pdMS_TO_TICKS(2000));

    // USB-JTAG deaktivieren
    usb_serial_jtag_driver_uninstall();

    // Brownout aus
    esp_brownout_disable();

    // RTC-Peripherie aus
    esp_sleep_pd_config(ESP_PD_DOMAIN_RTC_PERIPH, ESP_PD_OPTION_OFF);
    esp_sleep_pd_config(ESP_PD_DOMAIN_RTC_SLOW_MEM, ESP_PD_OPTION_OFF);
    esp_sleep_pd_config(ESP_PD_DOMAIN_RTC_FAST_MEM, ESP_PD_OPTION_OFF);

    // Alle Wakeups aus
    esp_sleep_disable_wakeup_source(ESP_SLEEP_WAKEUP_ALL);

    // Deep Sleep
    esp_deep_sleep_start();
}

[Olli Z. (z80freak)]

Niklas G. schrieb:
> Olli Z. schrieb:
> Da mal Code einfügen um floating Pins zu vermeiden... Oder extern alle
> Pins auf einen definierten Pegel legen

Habe ich versucht mittels

   // ALLE GPIOs explizit konfigurieren, außer "kritischen" Pins:
    // GPIO 15 - 17 = INTERNAL
    // GPIO 18, 19 = USB D+/D-
    // GPIO 20 - 21 = INTERNAL
    // GPIO 22-27 = SPI Flash (CS, SCLK, MISO, MOSI, WP, HD)
    for (int gpio_num = 0; gpio_num < 15; gpio_num++) {
        gpio_reset_pin(gpio_num);
        gpio_set_direction(gpio_num, GPIO_MODE_INPUT);
        gpio_set_pull_mode(gpio_num, GPIO_PULLDOWN_ONLY);
        
        // GPIO Zustand im Deep Sleep halten
        gpio_hold_en(gpio_num);
    }

Hatte keinen Effekt.

[Olli Z. (z80freak)]

Nemopuk schrieb:
> Kannst du mal einen Link zum Schaltplan posten?
Hatte ich dem Post darüber beigefügt und mir schwant das ich da noch 
etwas vom Board löten sollte... die WS2812B ist permanent verbunden, der 
Lade-Controller ggf. auch der LDO könnten Ruheströme verursachen.

[Olli Z. (z80freak)]

Alexander schrieb:
> Ich hatte da vor kurzem ähnliches Problem, der ESP.restart() war nicht
> wirklich ein Reset. Geholfen hat mir dann die Lösung von Thomas M.
> (tom_holzwurm) https://www.mikrocontroller.net/topic/goto_post/7742869
Danke für den Code! Die RTC Powerdomains gibt es im H2 nicht, da kann 
ich nur XTAL und CPU abschalten, was aber eh schon passiert:

    esp_sleep_pd_config(ESP_PD_DOMAIN_XTAL, ESP_PD_OPTION_OFF);
    esp_sleep_pd_config(ESP_PD_DOMAIN_CPU, ESP_PD_OPTION_OFF);

Beides erzeugt einen PANIC mit Reset bei der Codeausführung.

Der usb_serial_jtag_driver_uninstall(); bring keinen erkennbaren 
Unterschied.

Und auch Brownout-Detection kann beim H2 und der aktuellen ESP-IDF 5.5.2 
nicht mehr per Code deaktiviert werden, das muss man im "sdkconfig" 
mittels
CONFIG_ESP_BROWNOUT_DET=n
tun. Bringt aber auch keinen Vorteil.

[Olli Z. (z80freak)]

HA! Habe den LDO, den Batterieladeregler und die RGB-LED runtergelötet 
und siehe da, ich komme im Deep-Sleep auf 15 µA, ganz ohne weitere 
Tricks in der Software.

[Alexander (alecxs)]

Hattest Du das nicht bereits getan?

Olli Z. schrieb:
> Genau das hatte ich jetzt auch gemacht um mal alle anderen Fehlerquellen
> auszuschließen. Dazu verwende ich nur die Power-Meter Funktion vom PPK2
> und übergehe sogar den Spannungsregler auf dem EPS32-H2 Super-Mini Board

Olli Z. schrieb:
> Was könnte ich nun falsch gemacht haben? Auf dem Board ist keine LED an
> und auch sonst keine weitere, besondere Zusatzhardware

[Olli Z. (z80freak)]

Alexander schrieb:
> Hattest Du das nicht bereits getan?
Nein, ich bin nur hinter dem LDO mit 3,3V drauf gegangen und haben keine 
EXTERNEN Bauteile, im Sinne von "nicht auf dem ESP-Board" vorhandene, 
mehr angeschlossen.

[Olli Z. (z80freak)]

Auch der Light-Sleep sieht nun endlich sauber aus und geht auf 315 µA 
was ich ok finde.

Durch die Entfernung der Hardware habe ich vermutlich:
* TP4054 entfernt → ~50-100 µA gespart
* ME6217 LDO entfernt → ~40 µA gespart
* WS2812B RGB-LED entfernt → ~300 µA gespart

Ich löte die Bauteile jetzt nach und nach nochmal drauf und messe das 
nach. Hätte ich so nicht erwartet. Ok, das mit der RGB-LED vielleicht 
schon, denn die hängt direkt an 3,3V, aber beim LDO und BMS. Bin mal 
gespannt welches Bauteil die "Spikes" vom Anfang auslöst...

[Joachim B. (jar)]

Olli Z. schrieb:
> Ok

du bist seit 10 Jahren hier angemeldet, was hast du an:

Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

nicht verstanden?

[Olli Z. (z80freak)]

Inzwischen bin ich auch etwas schlauer geworden bezüglich der "Spikes" 
aus dem ersten Schaubild. Da hatte ich den PPK2 zwischen Batterie und 
Eingang vom Buck/Boost Controller als Amperemeter geschaltet und auch 
nach entlöten der Bauteile auf dem ESP-Board sind diese Spikes noch da.

Direkt hinter dem Regler schaut dagegen alles friedlich aus (siehe 
Screenshot an diesem Post).

Im Zustand mit den Spikes hat der Akku gute 3,9 V, der Regler arbeitet 
also im Buck-Modus. Ich schaue mir das ganze nochmal im Boost an sobald 
der Akku leerer wird und der Regler in den Boost-Modus geht. Der Regler 
ist mit einem TPS63020 bestück und auf 3,3V Ausgangsspannung kodiert 
(das Bild zeigt noch eine andere Kodierung).

Die Spikes treten auch im "Leerlauf" des Reglers auf, also auch wenn 
dahinter nichts angeschlossen ist. Daher vermute ich mal das dieses 
Verhalten die Aufladung der Spule/Kondensatoren zeigt und von daher ganz 
normal ist? Der echte Stromverbrauch am Akku hängt aber damit natürlich 
um einiges höher (fast 6 mA!). Das irritiert mich noch, denn eigentlich 
ist dieser Regler hat hocheffizient und es ist im Datenblatt von 25 µA 
Leerlaufstrom die Rede. Die Pins "EN", "PS" und "PG" habe ich nicht 
beschaltet. EN und PS sind immer HIGH und PG ist dauerhaft LOW 
(vermutlich weil laut Datenblatt einfach "offen" rausgeführt ohne 
Pullup).

Einen Schaltplan von dem Reglerboard konnte ich bislang nicht erhalten, 
normalerweise verwenden die Chinesen hier aber gern die Schaltvorschläge 
aus dem Datenblatt.

[Niklas G. (erlkoenig)]

Olli Z. schrieb:
> Der Regler ist mit einem TPS63020 bestück

Der hat einen Power-Save Mode, bei dem er immer nur kurz einschaltet und 
kurze "Pakete" wandelt, und dazwischen nichts tut. Das ist genau für 
solche Low-Power Anwendungen gemacht. Das Resultat ist dass der 
Verbrauch am Eingang aus solchen Spitzen besteht - natürlich nur wenn 
die Last auch gerade wenig Strom zieht.

[Olli Z. (z80freak)]

Niklas G. schrieb:
> Olli Z. schrieb:
>> Der Regler ist mit einem TPS63020 bestück
> Der hat einen Power-Save Mode, bei dem er immer nur kurz einschaltet und
> kurze "Pakete" wandelt, und dazwischen nichts tut. Das ist genau für
Ja, das war mir bekannt und ist im Datenblatt auch gut beschrieben. 
Unterhalb von 100 mA geht er in den PWM-Modus, aber doch nur wenn PS auf 
LOW liegt, was bei mir aber nicht der Fall ist. Wenn ich das mal tue 
steigt der Stromfluß auf fast 40 mA an. Das ist doch paradox, im 
Power-Save Mode verbraucht er fast achtmal soviel?

[Olli Z. (z80freak)]

Ich habe jetzt einfach mal ein anderes Board ausprobiert, auch mit 
TPS63020 drauf. Da zeigt sich ein ganz anderes Verhalten.

Was auch wieder interessant ist, denn bestellt hatte ich diesen hier: 
https://www.amazon.de/Lithiumbatterie-Automatisches-Boost-Buck-Step-Up-Down-Mikrocontroller-Leistung-Welligkeit/dp/B0DKTF2SG3 
(V1.0) und bekommen habe ich die V1.1 die ohne LED und ohne Pullup auf 
PS daher kommt, was mir ja sogar zugute kommt, dann muss ich nichts 
runter löten. Das Bild hier ist von meiner Version 1.1. So ist das halt 
mit den Chinesischen Händlern, immer eine Wundertüte...

Gemessen habe ich wieder mit dem PPK2 als Amperemeter zwischen Batterie 
und Vin geschaltet. Man erkennt das im Aktivbetrieb des ESP ca. 10 mA 
gezogen werden. Im Light-Sleep geht es dann auf 27 µA AVG zurück. 
Anstelle dem Sägezahn sieht man hier nur mal kleine Stromspitzen bis zu 
10 mA. Es wirkt als wäre das ein ganz anderer Buck-Boost Controller, wie 
kann es zu diesem doch sehr unterschiedlichen Verhalten kommen?
Eines fällt an diesem Board natürlich auf, die fehlenden Kondensatoren, 
da sind nur ein paar kleine Kerkos drauf. Daher hat man evtl. nur diese 
"Nadeln" anstelle dem Sägezahn? Dennoch sind im Mittel 27 µA perfekt, 
kein Vergleich mit dem anderen Regler.

[Nemopuk (nemopuk)]

Olli Z. schrieb:
> wie kann es zu diesem doch sehr unterschiedlichen Verhalten kommen?

Fake Chips verhalten sich in solchen Details oft anders, als das 
Original.

[Niklas G. (erlkoenig)]

Olli Z. schrieb:
> Im Light-Sleep geht es dann auf 27 µA AVG zurück.

Bei aktivierter PWM-Ausgabe?

[Olli Z. (z80freak)]

Und dann habe ich hier noch einen, den teuersten Regler im Bunde von 
Pololu, ein S9V11F3S5CMA (3,3 Volt Festspannungsregler, Buck-Boost) für 
gut 20,- €. Seine Stromaufnahme ist im Normalbetrieb mehr als doppelt so 
groß wie von dem vorherigen Regler für 3,- €. Auch im Light-Sleep zieht 
er primärseitig deutlich mehr, fast 10x soviel. Das ist schon etwas 
enttäuschend für einen so teuren Regler.

[Olli Z. (z80freak)]

Nemopuk schrieb:
> Olli Z. schrieb:
>> wie kann es zu diesem doch sehr unterschiedlichen Verhalten kommen?
> Fake Chips verhalten sich in solchen Details oft anders, als das
> Original.
Ja, die Chinesen kopieren gern, auch sich selbst. Gut möglich das ich 
mit dem einen Board eine schlechte und mit dem anderen eine bessere 
Kopie bekommen habe. Original sind beide ganz sicher nicht...

[Olli Z. (z80freak)]

Niklas G. schrieb:
> Olli Z. schrieb:
>> Im Light-Sleep geht es dann auf 27 µA AVG zurück.
>
> Bei aktivierter PWM-Ausgabe?

Meinst Du von meinem ESP? Nein, das habe ich nie mit gemessen denn das 
ist ja "Nutzlast", genauso wie die dahinter geschaltete LED. Mich 
interessiert ja der grundsätzliche Standby-Strom.

[Niklas G. (erlkoenig)]

Olli Z. schrieb:
> Meinst Du von meinem ESP? Nein, das habe ich nie mit gemessen denn das
> ist ja "Nutzlast", genauso wie die dahinter geschaltete LED

Du könntest ja mal die PWM auf einen offenen Pin ausgeben. Dann könntest 
du den Verbrauch des ESP32 für die PWM-Ausgabe messen.