Hallo Kollegen, nach etlichen erfolglosen Experimenten und eifrigen Suchens habe ich keine befriedigende Antwort auf die WDG Architektur des ESP32 gefunden. Es gibt laut Beschreibung 2 WDG's: einmal für Interrupts und einmal für Tasks. Aber anscheinend keinen WDG, der wie bei anderen µC einen echten HW Reset ausführt. Ich habe auch schon versucht einen WDG mit Timern zu implementieren, was letztlich einen ESP32.reset() auslöst, aber das funktioniert auch nur bedingt. Zum einen setzt die genannte Systemfunktion nicht alle Peripheriebaugruopen zurück und der ESP32 gerät z.B. durch Unterbrechung des WLAN's in einen Zustand, wo nur ein echter Reset hilft. Man könnte natürlich einen externen Baustein dazu verwenden, aber es sollte doch eine Möglichkeit für einen echten WDG on Chip geben. Frage: hab ich was übersehen, oder geht das tatsächlich nicht ? Dake für Eure Hilfe, Gruß Thomas
Es gibt laut Beschreibung 2 WDG's: einmal für Interrupts und einmal für Tasks.
Laut https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/system/wdts.html
gibt es zwei Hardware-Watchdogs, einer in der RTC, ein "Normaler".
Die sind durch die HAL und FreeRTOS abstrahiert, das was du als "Interrupt" und "Task"-Watchdog siehst, greift beides auf den MWDT_WDT zu.
Und der sollte eigentlich einen "echten" Reset ausführen.
OK, danke für den Tip, ich werde das gelegentlich testen und dann berichten.
vielleicht hilft das
https://iotassistant.io/esp32/enable-hardware-watchdog-timer-esp32-arduino-ide
Nee, das hilft leider nicht, weil es sich auch auf den Task WDT bezieht. Aber, ich habe das Problem gelöst:
Der Tip mit dem RTC WDT ist korrek t, weil dieses Modul löst entweder für die RTC oder(!) fürs System einen Reset aus. Und nur das macht einen echten Systemreset !
esp_restart() startedt nur die CPU neu, wenn die Peripherie abgeschmiert ist, in meinem Fall das WLAN Modul, ist der ESP32 trotzdem tot.
Die SW Lösung ist total easy, aber echt gut versteckt:
"https://github.com/espressif/esp-idf/blob/master/components/esp_hw_support/include/rtc_wdt.h" das ist das Headerfile für den RTC_WDT ist die Lösung dokumentiert:
Sieht dann so aus:
// Initialisierung bei mir auf 10 sec. mit RTC_WDT_TIMEOUT
void WatchdogSetup(void){
rtc_wdt_protect_off();
rtc_wdt_disable();
rtc_wdt_set_length_of_reset_signal(RTC_WDT_SYS_RESET_SIG, RTC_WDT_LENGTH_3_2us);
rtc_wdt_set_stage(RTC_WDT_STAGE0, RTC_WDT_STAGE_ACTION_RESET_SYSTEM); //RTC_WDT_STAGE_ACTION_RESET_SYSTEM or RTC_WDT_STAGE_ACTION_RESET_RTC
rtc_wdt_set_time(RTC_WDT_STAGE0, RTC_WDT_TIMEOUT); // timeout rtd_wdt 7000ms.
rtc_wdt_enable();
rtc_wdt_protect_on();
#if(WDG_DEBUG >0)
ESP_LOGI(TAG, "!!! ESP WDG INIT !!!!");
#endif
}
///////////////////////////////////////////////////////////
void WatchdogReset(void)
{
rtc_wdt_feed();
}
wird periodisch bei mir von der NTP Uhr zyklisch aufgerufen.
Und das wars wohl, zumindest die Test waren bisher positiv, ich werde das Ganze erst auf einem Knoten eine Weil laufen lassen und dann überall ausrollen.
Danke nochmals für die Hilfe,
Gruß Thomas
Kam mir irgendwie bekannt vor:
Espressif: Vermeldung von Fehlern im ESP32-C5.
Der „FehlerTeufel“ macht auch vor Espressif Systems nicht halt. In einem vor wenigen Stunden veröffentlichten Beratung verkündigen die Chinesen die folgende Fehlerliste, die den vergleichsweise neuen ESP32-C5 betrifft:
• PSRAM Reset Hang – When ESP32-C5 series chips run ESP-IDF v5.5.1 with PSRAM enabled, CPU or digital reset operations may hang. This triggers a secondary RTC WDT reset. If the rollback feature (CONFIG_BOOTLOADER_APP_ROLLBACK_ENABLE, disabled by default) is enabled, this sequence may result in an OTA rollback.• AES and SHA Access to PSRAM – When ESP32-C5 chips run ESP-IDF v5.5.1, PSRAM data may be corrupted when AES or SHA hardware accesses buffers that are not aligned to a 16-byte boundary.• Sleep Coexistence Stability – When ESP32-C5 series chips run ESP-IDF v5.5.1 with ESP_WIFI_ENHANCED_LIGHT_SLEEP enabled, task watchdog timeouts may occur during Wi-Fi/BLE/IEEE 802.15.4 dual-mode or tri-mode coexistence, and the system may fail to recover after a CPU reset.
CNX-Software berichtet unter der URL https://www.cnx-software.com/2026/02/28/esp32-c5-bug-advisory-identifies-and-fixes-psram-and-sleep-coexistence-issues/ detailliert über Mitigationsmaßnahmen. Im „Allgemeinen“ gilt allerdings, dass die Behebung dieses Problems keine neue Hardware voraussetzt - wer seine ESP_IDF-Version aktuell hält, wird über kurz oder lang mit einem Software-Workaround für diese Fehler versorgt werden.
Nun eher nicht, im September 2024 stand die Version 3.0.4, im Oktober 2024 folgte dann die 3.1.0.
Der Fehler, den du gerade meinst ist aktuell und tritt nur in 5.5.1 auf.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.