ESP32-H2 will nicht schlafen

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

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.

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.

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.

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"?

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.

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

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.

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

1

#include <stdio.h>

2

#include "freertos/FreeRTOS.h" // FreeRTOS

3

#include "freertos/task.h" // Tasks

4

#include "esp_log.h"    // Logging

5

#include "esp_sleep.h" // Sleep

6

7

static const char *TAG = "sleep-test";

8

void app_main(void)

9

{

10

    while (1)

11

    {

12

        vTaskDelay(pdMS_TO_TICKS(10000));

13

        //esp_light_sleep_start();

14

        esp_deep_sleep_start();

15

    }

16

}

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

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...

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.

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

1

#include <stdio.h>

2

#include "freertos/FreeRTOS.h"

3

#include "freertos/task.h"

4

#include "esp_sleep.h"

5

#include "esp_log.h"

6

#include "esp_err.h"

7

8

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

9

10

void app_main(void)

11

{

12

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

13

14

    vTaskDelay(pdMS_TO_TICKS(5000));

15

16

    // Alle Wakeup-Signale deaktivieren

17

    esp_sleep_disable_wakeup_source(ESP_SLEEP_WAKEUP_ALL);

18

19

    ESP_LOGI(TAG, "Entering sleep NOW");

20

    vTaskDelay(pdMS_TO_TICKS(100));

21

22

    esp_deep_sleep_start();

23

24

    vTaskDelay(pdMS_TO_TICKS(100));

25

26

    ESP_LOGI(TAG, "Woke up! Wakeup cause: %d", esp_sleep_get_wakeup_cause());

27

28

    while(1) {

29

        vTaskDelay(pdMS_TO_TICKS(1000));

30

    }

31

}

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

1

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'

2

--- Warning: GDB cannot open serial ports accessed as COMx

3

--- Using \\.\COM6 instead...

4

--- esp-idf-monitor 1.8.0 on \\.\COM6 115200

5

--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H

6

I (118) esp_image: segment 3: paddr=0002cf54 vaddr=408005fc sizeESP-ROM:esp32h2-20221101

7

Build:Nov  1 2022

8

rst:0x15 (USB_UART_HPSYS),boot:0x8 (SPI_FAST_FLASH_BOOT)

9

Saved PC:0x408037e2

10

--- 0x408037e2: rv_utils_wait_for_intr at C:/Users/localuser/esp/v5.5.1/esp-idf/components/riscv/include/riscv/rv_utils.h:79

11

--- (inlined by) esp_cpu_wait_for_intr at C:/Users/localuser/esp/v5.5.1/esp-idf/components/esp_hw_support/cpu.c:62

12

SPIWP:0xee

13

mode:DIO, clock div:1

14

load:0x408460f0,len:0x1700

15

load:0x4083c2d0,len:0xf78

16

load:0x4083efd0,len:0x2fdc

17

entry 0x4083c2da

18

I (23) boot: ESP-IDF v5.5.1 2nd stage bootloader

19

I (23) boot: compile time Dec  1 2025 20:00:32

20

I (24) boot: chip revision: v0.1

21

I (25) boot: efuse block revision: v0.3

22

I (26) boot.esp32h2: SPI Speed      : 64MHz

23

I (30) boot.esp32h2: SPI Mode       : DIO

24

I (34) boot.esp32h2: SPI Flash Size : 2MB

25

I (38) boot: Enabling RNG early entropy source...

26

I (42) boot: Partition Table:

27

I (45) boot: ## Label            Usage          Type ST Offset   Length

28

I (51) boot:  0 nvs              WiFi data        01 02 00009000 00006000

29

I (58) boot:  1 phy_init         RF data          01 01 0000f000 00001000

30

I (64) boot:  2 factory          factory app      00 00 00010000 00100000

31

I (71) boot: End of partition table

32

I (74) esp_image: segment 0: paddr=00010020 vaddr=42018020 size=079f4h ( 31220) map

33

I (90) esp_image: segment 1: paddr=00017a1c vaddr=40800000 size=005fch (  1532) load

34

I (92) esp_image: segment 2: paddr=00018020 vaddr=42000020 size=14f2ch ( 85804) map

35

I (118) esp_image: segment 3: paddr=0002cf54 vaddr=408005fc size=0c42ch ( 50220) load

36

I (134) esp_image: segment 4: paddr=00039388 vaddr=4080ca30 size=017b4h (  6068) load

37

I (137) esp_image: segment 5: paddr=0003ab44 vaddr=50000000 size=00080h (   128) load

38

I (142) boot: Loaded app from partition at offset 0x10000

39

I (143) boot: Disabling RNG early entropy source...

40

I (160) cpu_start: Unicore app

41

D (160) cpu_start: Pro cpu up

42

D (168) clk: RTC_SLOW_CLK calibration value: 3568288

43

D (173) cpu_start: calling init function: 0x42000232 on core: 0

44

--- 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

45

D (174) cpu_start: calling init function: 0x42001486 on core: 0

46

--- 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

47

I (175) cpu_start: Pro cpu start user code

48

I (177) cpu_start: cpu freq: 96000000 Hz

49

D (181) cpu_start: calling init function: 0x420000e0 on core: 0

50

--- 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

51

I (187) app_init: Application information:

52

I (190) app_init: Project name:     sleep-test

53

I (194) app_init: App version:      1

54

I (198) app_init: Compile time:     Dec 27 2025 14:11:52

55

I (203) app_init: ELF file SHA256:  f2e8d38af...

56

I (207) app_init: ESP-IDF:          v5.5.1

57

D (211) cpu_start: calling init function: 0x42000246 on core: 0

58

--- 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

59

I (217) efuse_init: Min chip rev:     v0.0

60

I (220) efuse_init: Max chip rev:     v1.99

61

I (224) efuse_init: Chip rev:         v0.1

62

D (228) cpu_start: calling init function: 0x42003422 on core: 0

63

--- 0x42003422: __esp_system_init_fn_init_heap at C:/Users/localuser/esp/v5.5.1/esp-idf/components/heap/heap_caps_init.c:26

64

D (234) memory_layout: Checking 5 reserved memory ranges:

65

D (239) memory_layout: Reserved memory range 0x40800000 - 0x4080ca30

66

--- 0x40800000: _vector_table at C:/Users/localuser/esp/v5.5.1/esp-idf/components/riscv/vectors_intc.S:54

67

D (245) memory_layout: Reserved memory range 0x4080ca30 - 0x4080f280

68

D (251) memory_layout: Reserved memory range 0x4084fee0 - 0x40850000

69

D (257) memory_layout: Reserved memory range 0x50000000 - 0x50000080

70

--- 0x50000000: esp_wake_stub_entry at C:/Users/localuser/esp/v5.5.1/esp-idf/components/esp_hw_support/sleep_modes.c:374

71

D (263) memory_layout: Reserved memory range 0x50000fe8 - 0x50001000

72

D (269) memory_layout: Building list of available memory regions:

73

D (275) memory_layout: Available memory region 0x4080f280 - 0x40810000

74

D (282) memory_layout: Available memory region 0x40810000 - 0x40820000

75

D (288) memory_layout: Available memory region 0x40820000 - 0x40830000

76

D (294) memory_layout: Available memory region 0x40830000 - 0x40840000

77

D (300) memory_layout: Available memory region 0x40840000 - 0x4084d380

78

D (307) memory_layout: Available memory region 0x4084d380 - 0x4084fee0

79

D (313) memory_layout: Available memory region 0x50000080 - 0x50000fe8

80

I (319) heap_init: Initializing. RAM available for dynamic allocation:

81

D (325) heap_init: New heap initialised at 0x4080f280

82

I (330) heap_init: At 4080F280 len 0003E100 (248 KiB): RAM

83

I (335) heap_init: At 4084D380 len 00002B60 (10 KiB): RAM

84

D (340) heap_init: New heap initialised at 0x50000080

85

I (345) heap_init: At 50000080 len 00000F68 (3 KiB): RTCRAM

86

D (350) cpu_start: calling init function: 0x42001202 on core: 0

87

--- 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

88

D (356) cpu_start: calling init function: 0x420075f6 on core: 0

89

--- 0x420075f6: __esp_system_init_fn_init_libc at C:/Users/localuser/esp/v5.5.1/esp-idf/components/newlib/src/init.c:12

90

D (362) cpu_start: calling init function: 0x420014fe on core: 0

91

--- 0x420014fe: __esp_system_init_fn_init_brownout at C:/Users/localuser/esp/v5.5.1/esp-idf/components/esp_system/startup_funcs.c:79

92

D (368) intr_alloc: Connected src 2 to int 1 (cpu 0)

93

D (372) cpu_start: calling init function: 0x42001520 on core: 0

94

--- 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

95

D (378) cpu_start: calling init function: 0x42007604 on core: 0

96

--- 0x42007604: __esp_system_init_fn_init_libc_stdio at C:/Users/localuser/esp/v5.5.1/esp-idf/components/newlib/src/init.c:18

97

D (384) cpu_start: calling init function: 0x42001530 on core: 0

98

--- 0x42001530: __esp_system_init_fn_init_flash at C:/Users/localuser/esp/v5.5.1/esp-idf/components/esp_system/startup_funcs.c:111

99

D (389) spi_flash: trying chip: gd

100

I (392) spi_flash: detected chip: gd

101

I (395) spi_flash: flash io: dio

102

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.

103

D (410) cpu_start: calling init function: 0x420003a0 on core: 0

104

--- 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

105

D (416) efuse: BLK0 REG2 [24-27], len=4 bits

106

D (420) efuse: BLK0 REG2 [28-31], len=4 bits

107

D (424) efuse: BLK0 REG3 [0-3], len=4 bits

108

D (428) efuse: BLK0 REG3 [4-7], len=4 bits

109

D (432) efuse: BLK0 REG3 [8-11], len=4 bits

110

D (436) efuse: BLK0 REG3 [12-15], len=4 bits

111

D (440) cpu_start: calling init function: 0x408059fe

112

--- 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

113

D (444) cpu_start: calling init function: 0x40805e7c

114

--- 0x40805e7c: tlsf_set_rom_patches at C:/Users/localuser/esp/v5.5.1/esp-idf/components/esp_rom/patches/esp_rom_tlsf.c:167

115

D (449) cpu_start: calling init function: 0x4200294e on core: 0

116

--- 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

117

D (455) cpu_start: calling init function: 0x4200abba on core: 0

118

--- 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

119

--- (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  

120

D (460) cpu_start: calling init function: 0x420037e8 on core: 0

121

--- 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

122

D (466) cpu_start: calling init function: 0x4200425a on core: 0

123

--- 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

124

I (472) sleep_gpio: Configure to isolate all GPIO pins in sleep state

125

I (478) sleep_gpio: Enable automatic switching of GPIO sleep configuration

126

D (484) cpu_start: calling init function: 0x42013cde on core: 0

127

--- 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

128

D (490) cpu_start: calling init function: 0x42001582 on core: 0

129

--- 0x42001582: __esp_system_init_fn_init_pm at C:/Users/localuser/esp/v5.5.1/esp-idf/components/esp_system/startup_funcs.c:142

130

D (507) cpu_start: calling init function: 0x42007ce4 on core: 0

131

--- 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

132

D (508) cpu_start: calling init function: 0x42001592 on core: 0

133

--- 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

134

D (508) intr_alloc: Connected src 7 to int 2 (cpu 0)

135

D (512) app_start: Starting scheduler on CPU0

136

D (516) intr_alloc: Connected src 45 to int 5 (cpu 0)

137

I (516) main_task: Started on CPU0

138

D (516) heap_init: New heap initialised at 0x4084d380

139

D (516) intr_alloc: Connected src 42 to int 8 (cpu 0)

140

I (526) main_task: Calling app_main()

141

I (526) EPS32-SLEEP-TEST: Sleep Test with USB disconnected (Battery driven, after LDO)

142

I (5536) EPS32-SLEEP-TEST: Entering sleep NOW

143

--- Error: ClearCommError failed (PermissionError(13, 'Das Gerät erkennt den Befehl nicht.', None, 22))

144

--- 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

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

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?

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):

1

#include "esp_sleep.h"

2

#include "esp_log.h"

3

#include "driver/usb_serial_jtag.h"

4

#include "esp_system.h"

5

6

void app_main(void)

7

{

8

    vTaskDelay(pdMS_TO_TICKS(2000));

9

10

    // USB-JTAG deaktivieren

11

    usb_serial_jtag_driver_uninstall();

12

13

    // Brownout aus

14

    esp_brownout_disable();

15

16

    // RTC-Peripherie aus

17

    esp_sleep_pd_config(ESP_PD_DOMAIN_RTC_PERIPH, ESP_PD_OPTION_OFF);

18

    esp_sleep_pd_config(ESP_PD_DOMAIN_RTC_SLOW_MEM, ESP_PD_OPTION_OFF);

19

    esp_sleep_pd_config(ESP_PD_DOMAIN_RTC_FAST_MEM, ESP_PD_OPTION_OFF);

20

21

    // Alle Wakeups aus

22

    esp_sleep_disable_wakeup_source(ESP_SLEEP_WAKEUP_ALL);

23

24

    // Deep Sleep

25

    esp_deep_sleep_start();

26

}

Niklas G. schrieb:

Olli Z. schrieb im Beitrag #7985397: Da mal Code einfügen um floating Pins zu vermeiden... Oder extern alle Pins auf einen definierten Pegel legen

Habe ich versucht mittels

1

   // ALLE GPIOs explizit konfigurieren, außer "kritischen" Pins:

2

    // GPIO 15 - 17 = INTERNAL

3

    // GPIO 18, 19 = USB D+/D-

4

    // GPIO 20 - 21 = INTERNAL

5

    // GPIO 22-27 = SPI Flash (CS, SCLK, MISO, MOSI, WP, HD)

6

    for (int gpio_num = 0; gpio_num < 15; gpio_num++) {

7

        gpio_reset_pin(gpio_num);

8

        gpio_set_direction(gpio_num, GPIO_MODE_INPUT);

9

        gpio_set_pull_mode(gpio_num, GPIO_PULLDOWN_ONLY);

10

11

        // GPIO Zustand im Deep Sleep halten

12

        gpio_hold_en(gpio_num);

13

    }

Hatte keinen Effekt.

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.

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:

1

    esp_sleep_pd_config(ESP_PD_DOMAIN_XTAL, ESP_PD_OPTION_OFF);

2

    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.

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.

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

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.

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...

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?

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.

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.

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?

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.

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.

Olli Z. schrieb:

Im Light-Sleep geht es dann auf 27 µA AVG zurück.

Bei aktivierter PWM-Ausgabe?

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.

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...

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.

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.