Souvent difficile de connaître les raisons d’un reboot d un ESP
Savez vous que l esp possède une mini boite noire qui enregistre la raison du reboot juste avant ce dernier ?
Ce serait extrêmement utile d afficher cette valeur dans la page données brutes pour donner les bonnes pistes de diagnostics
Pour cela il suffit de lire la valeur de esp_reset_reason_t()
esp_reset_reason() — valeurs possibles
0 ESP_RST_UNKNOWN Raison indéterminée
1 ESP_RST_POWERON Mise sous tension (alimentation coupée puis rétablie)
2 ESP_RST_EXT Reset externe appliqué sur la broche EN/RESET
3 ESP_RST_SW Reset logiciel demandé par le code (ESP.restart() / esp_restart())
4 ESP_RST_PANIC Exception ou panic (crash logiciel : déréférencement nul, LoadProhibited...)
5 ESP_RST_INT_WDT Interrupt watchdog : une ISR ou une section critique a bloqué trop longtemps
6 ESP_RST_TASK_WDT Task watchdog : une tâche n'a pas rendu la main (boucle sans yield/delay)
7 ESP_RST_WDT Autre watchdog (RTC WDT, Timer Group WDT)
8 ESP_RST_DEEPSLEEP Sortie de deep sleep
9 ESP_RST_BROWNOUT Brownout : tension d'alimentation descendue sous le seuil
10 ESP_RST_SDIO Reset provoqué via l'interface SDIO
Ajoutés avec l'IDF 5.x (core Arduino ESP32 3.x) :
11 ESP_RST_USB Reset provoqué par le périphérique USB
12 ESP_RST_JTAG Reset provoqué par JTAG
13 ESP_RST_EFUSE Erreur de vérification des eFuses
14 ESP_RST_PWR_GLITCH Glitch d'alimentation détecté par le matériel
15 ESP_RST_CPU_LOCKUP Double exception (CPU bloqué)
La petite limite est qu on a uniquement la valeur du dernier reboot, mais il est facile d enregistrer en rtc ram ou en nvs cette valeur pour avoir l historique au cas ou l esp a rebooté plusieurs fois dans la nuit.
Ça permet tout de suite d orienter la recherche vers un problème hardware ou un bug logiciel ou un problème de comm. C est grâce à ça que j ai compris d ou venait le reboot d un de mes F1ATB => il manque des vTaskDelay(1) dans pas mal de boucle d attentes qui ne laissent pas le temps d exécuter les autres tâches et finissent par un esp_reset_reason =ESP_RST_TASK_WDT
On accuse souvent l alimentation de l esp à tort ou à raison
Le ESP_RST_BROWNOUT sera là pour juger.
Le stockage en rtc_ram pourrait aussi être très utile pour conserver les compteurs après un reset et donc ne pas perdre des actions basées sur les compteurs , pistes à creuser aussi
Savez vous que l esp possède une mini boite noire qui enregistre la raison du reboot juste avant ce dernier ?
Ce serait extrêmement utile d afficher cette valeur dans la page données brutes pour donner les bonnes pistes de diagnostics
Pour cela il suffit de lire la valeur de esp_reset_reason_t()
esp_reset_reason() — valeurs possibles
0 ESP_RST_UNKNOWN Raison indéterminée
1 ESP_RST_POWERON Mise sous tension (alimentation coupée puis rétablie)
2 ESP_RST_EXT Reset externe appliqué sur la broche EN/RESET
3 ESP_RST_SW Reset logiciel demandé par le code (ESP.restart() / esp_restart())
4 ESP_RST_PANIC Exception ou panic (crash logiciel : déréférencement nul, LoadProhibited...)
5 ESP_RST_INT_WDT Interrupt watchdog : une ISR ou une section critique a bloqué trop longtemps
6 ESP_RST_TASK_WDT Task watchdog : une tâche n'a pas rendu la main (boucle sans yield/delay)
7 ESP_RST_WDT Autre watchdog (RTC WDT, Timer Group WDT)
8 ESP_RST_DEEPSLEEP Sortie de deep sleep
9 ESP_RST_BROWNOUT Brownout : tension d'alimentation descendue sous le seuil
10 ESP_RST_SDIO Reset provoqué via l'interface SDIO
Ajoutés avec l'IDF 5.x (core Arduino ESP32 3.x) :
11 ESP_RST_USB Reset provoqué par le périphérique USB
12 ESP_RST_JTAG Reset provoqué par JTAG
13 ESP_RST_EFUSE Erreur de vérification des eFuses
14 ESP_RST_PWR_GLITCH Glitch d'alimentation détecté par le matériel
15 ESP_RST_CPU_LOCKUP Double exception (CPU bloqué)
La petite limite est qu on a uniquement la valeur du dernier reboot, mais il est facile d enregistrer en rtc ram ou en nvs cette valeur pour avoir l historique au cas ou l esp a rebooté plusieurs fois dans la nuit.
Ça permet tout de suite d orienter la recherche vers un problème hardware ou un bug logiciel ou un problème de comm. C est grâce à ça que j ai compris d ou venait le reboot d un de mes F1ATB => il manque des vTaskDelay(1) dans pas mal de boucle d attentes qui ne laissent pas le temps d exécuter les autres tâches et finissent par un esp_reset_reason =ESP_RST_TASK_WDT
On accuse souvent l alimentation de l esp à tort ou à raison
Le ESP_RST_BROWNOUT sera là pour juger.
Le stockage en rtc_ram pourrait aussi être très utile pour conserver les compteurs après un reset et donc ne pas perdre des actions basées sur les compteurs , pistes à creuser aussi
