ESP32 Brownout Detector was triggered : causes et solutions

Le message ESP32 Brownout detector was triggered signifie que la tension d'alimentation de la carte est passée un instant sous une limite sûre et que la puce a redémarré pour se protéger. Le problème ne vient presque jamais du code, mais de l'alimentation : un port USB faible, un câble fin et long, un régulateur trop juste, ou des servos et des rubans LED alimentés par la même ligne que l'ESP32. La deuxième grande raison pour laquelle un ESP32 redémarre sans arrêt, ce sont les plantages logiciels ; dans ce cas le moniteur série affiche des lignes comme Guru Meditation Error, task_wdt ou Stack canary.

La bonne nouvelle : l'ESP32 te dit lui-même pourquoi il a redémarré, à condition de savoir lire ses messages. Dans ce guide, tu vas d'abord apprendre à reconnaître les codes rst des lignes de démarrage et les messages d'erreur, puis régler le brownout pour de bon grâce à l'alimentation, au câble et à un condensateur. Ensuite, nous verrons les erreurs Guru Meditation comme LoadProhibited et StoreProhibited, le débordement de pile, les pointeurs nuls et les délais du watchdog, et tu remonteras un plantage jusqu'à la ligne de code avec ESP Exception Decoder. Pour finir, nous regarderons les broches de strapping (GPIO0, 2, 12 et 15) qui peuvent perturber le démarrage.

Pourquoi l'ESP32 redémarre-t-il sans arrêt ? Lis d'abord le message

Avant de commencer le diagnostic, ouvre le moniteur série à 115200 bauds et appuie sur le bouton EN de la carte. À chaque démarrage, le chargeur d'amorçage en ROM de l'ESP32 affiche d'abord une ligne de date comme "ets Jun 8 2016 00:22:57", puis une ligne du type rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT). La partie rst indique pourquoi la carte a redémarré, la partie boot dans quel mode elle a démarré. Si la carte tourne en boucle, tu trouveras juste au-dessus de ces lignes le message d'erreur, les dernières paroles de l'exécution précédente. Le tableau résume les messages que tu verras et par où commencer :

Que signifie "Brownout detector was triggered" et d'où vient-il ?

Un brownout est une baisse de tension brève, sans coupure complète. L'ESP32 contient un détecteur de brownout qui surveille l'alimentation en permanence ; dans le core Arduino, son seuil est réglé au niveau le plus bas, environ 2,43 V. Dès que la tension passe sous cette valeur, la puce protège la radio et la mémoire flash, écrit "Brownout detector was triggered" dans le moniteur série et redémarre. La raison est simple : à basse tension, la flash peut être mal lue, les données enregistrées peuvent être corrompues et le processeur peut exécuter des instructions au hasard. Le détecteur fait redémarrer proprement la carte au lieu de la laisser se comporter de façon imprévisible. Le module ESP32-WROOM-32 est conçu pour fonctionner entre 3,0 et 3,6 V ; quand la ligne atteint 2,43 V, elle a donc quitté la zone sûre depuis longtemps.

Après un message de brownout, la ligne de démarrage affiche rst:0xc (SW_CPU_RESET) ou rst:0x3 (SW_RESET) selon la version du core Arduino, car l'interruption du détecteur écrit le message puis redémarre la puce par logiciel. Ne te laisse pas tromper : ce même code note dans la mémoire de la puce que la cause était un brownout, et esp_reset_reason() renvoie ESP_RST_BROWNOUT. Quand c'est la remise à zéro matérielle du brownout qui agit, la ligne indique rst:0xf (RTCWDT_BROWN_OUT_RESET). Dans les cores 3.x, basés sur ESP-IDF 5, cette ligne est devenue un message de journal (log) de niveau info (I BOD: Brownout detector was triggered). Comme les bibliothèques précompilées du core Arduino n'écrivent que les messages de niveau erreur, elle n'apparaît le plus souvent pas du tout et la carte redémarre en silence ; si tu vois un rst:0x3 ou rst:0xc inexpliqué au démarrage, vérifie la cause du redémarrage avec le croquis de diagnostic plus bas. Pour comprendre pourquoi la tension chute, il faut regarder le courant consommé par l'ESP32 :

Cet écart est le cœur du problème : tant que ton code n'active pas le Wi-Fi, la carte tourne tranquillement à environ 50 mA, mais à la ligne WiFi.begin() le courant est multiplié par cinq ou six en quelques microsecondes. Si l'alimentation, le câble et le régulateur ne suivent pas cette demande soudaine, la tension s'effondre. C'est pourquoi Espressif recommande pour l'ESP32 une alimentation capable de fournir au moins 500 mA. Le symptôme est bien connu : la carte démarre, écrit quelques lignes dans le moniteur série, redémarre au moment où le Wi-Fi ou le Bluetooth se lance, et cela tourne en boucle sans fin. La même chose peut arriver quand un servo bouge, qu'un relais commute ou qu'un ruban LED passe au blanc.

Les causes les plus fréquentes du brownout

• Câble USB fin ou long : les fils d'alimentation fins des câbles bon marché peuvent atteindre 0,5 Ω aller-retour. D'après la loi d'Ohm, un pic de 400 mA perd 0,2 V dans un tel câble.
• Port USB faible ou hub : les ports des claviers et des écrans, les hubs non alimentés et les ports en façade de certains ordinateurs portables laissent chuter la tension lors des pics de courant.
• Chute de tension du régulateur : l'AMS1117 de la plupart des cartes a besoin de 1,0 à 1,3 V d'écart entre son entrée et sa sortie. Si la tension sur la broche 5V descend sous environ 4,3 V, la sortie ne peut plus tenir 3,3 V.
• Brancher une batterie directement : une batterie lithium de 3,7 V sur la broche 5V fait tomber la sortie sous 3 V à cause de la chute du régulateur ; deux piles AA passent vite sous le minimum de l'ESP32 en charge.
• La broche 3.3V de l'Arduino Uno : il est conseillé de ne tirer qu'environ 50 mA de cette broche ; c'est loin d'être suffisant pour un ESP32 avec le Wi-Fi actif.
• Charges sur la même ligne : si des servos, des relais, un buzzer, des moteurs à courant continu ou un ruban WS2812B sont alimentés par le même 5 V que l'ESP32, chaque mouvement tire la tension vers le bas.
• Breadboard et fils de connexion : les contacts lâches et les fils dupont fins ajoutent un peu de résistance à chaque connexion ; faire passer l'alimentation par la breadboard aggrave le problème.
• ESP32-CAM : quand la caméra, le Wi-Fi et la LED flash fonctionnent en même temps, le courant monte beaucoup ; cette carte veut du 5 V et au moins 2 A. Plus de détails dans le guide ESP32-CAM.

Solution 1 : améliore l'alimentation et le câble

La première étape, et la plus efficace, consiste à renforcer l'alimentation. Branche la carte avec un câble de données court, épais et dont tu es sûr, directement sur un port USB à l'arrière de ton ordinateur ou sur un chargeur 5 V d'au moins 1 A. Les ports USB 2.0 sont prévus pour fournir 500 mA et les ports USB 3.0, 900 mA ; les 500 mA recommandés par Espressif sont pile la limite d'un port USB 2.0, et dès qu'on ajoute les pertes du câble, les ennuis commencent. Si changer seulement de câble règle l'erreur, sa résistance était très probablement en cause. Tu peux calculer la tension perdue dans un câble avec V = I × R grâce à l'outil Loi d'Ohm.

Les projets sur batterie demandent de la prudence. Un accu lithium comme le 18650 donne 4,2 V chargé et environ 3,0 V déchargé. Cette plage ne convient ni à un branchement direct sur la broche 3V3 (4,2 V dépasse la limite de 3,6 V) ni à la broche 5V avec son AMS1117. La bonne solution consiste soit à envoyer la batterie sur la broche 5V via un module élévateur (boost) 5 V, soit à alimenter directement la ligne 3V3 avec un régulateur LDO à faible chute capable de fournir au moins 500 mA (par exemple ME6211 ou HT7833) et un condensateur. Tu peux estimer l'autonomie de ton projet avec l'outil Autonomie de batterie et découvrir le circuit de charge dans le guide du module de charge TP4056.

Solution 2 : ajoute un condensateur entre 3V3 et GND

Un condensateur agit comme un petit réservoir qui fournit lui-même l'énergie pendant un pic de courant, le temps que le régulateur et le câble réagissent. Place entre les broches 3V3 et GND, aussi près que possible de la carte, un condensateur électrolytique de 100 à 470 µF et, à côté, un condensateur céramique de 100 nF. L'électrolytique couvre les chutes de l'ordre de la milliseconde, le céramique les variations très brèves à haute fréquence. Tu peux estimer l'effet avec ΔV = I × Δt / C : même si un condensateur de 470 µF fournit à lui seul 200 mA de plus pendant 200 µs, la tension ne baisse que de 0,085 V. Le marquage 104 sur un condensateur céramique signifie 100 nF ; tu peux décoder les autres avec l'outil Code des condensateurs.

Solution 3 : alimente à part les servos, les moteurs et les rubans LED

Même si l'ESP32 lui-même est bien alimenté, les charges branchées sur la même ligne peuvent faire chuter la tension. Même un petit servo comme le SG90 tire quelques centaines de mA en démarrant ; une LED WS2812B consomme environ 60 mA en blanc maximal, donc un ruban de 30 LED peut monter à 1,8 A. Alimente ces charges non pas par la broche 5V ou 3V3 de l'ESP32, mais par une source 5 V séparée ; tu peux par exemple abaisser un chargeur 12 V à 5 V avec un module abaisseur LM2596. La règle la plus importante est de relier les GND des deux sources ; sans masse commune, la ligne de signal n'a pas de référence et le servo ou le ruban se comporte au hasard. Nous détaillons ce sujet dans Ton Arduino redémarre tout seul ? et GND et masse commune.

Désactiver le détecteur de brownout, est-ce une solution ?

La "solution" la plus souvent proposée sur Internet consiste à couper le détecteur en une seule ligne. Le code ci-dessous désactive le détecteur en remettant à zéro le registre de brownout de l'ESP32, et le message d'erreur disparaît. Mais les chutes de tension continuent ; simplement, plus personne ne te prévient. N'utilise ce code que pour le diagnostic : si la carte fonctionne bien avec le détecteur coupé, tu as la confirmation que le problème vient bien de l'alimentation. Supprime ensuite la ligne et répare l'alimentation.

1#include "soc/soc.h"
2#include "soc/rtc_cntl_reg.h"
3
4void setup() {
5  // YALNIZ TEŞHİS İÇİN: brownout dedektörünü kapat / DIAGNOSIS ONLY: disable the brownout detector
6  WRITE_PERI_REG(RTC_CNTL_BROWN_OUT_REG, 0);
7
8  Serial.begin(115200);
9  Serial.println("Brownout dedektoru kapali / brownout detector disabled");
10}
11
12void loop() {
13}

Codes rst : l'ESP32 te dit pourquoi il a redémarré

La valeur rst: affichée par la ROM à chaque démarrage indique comment s'est terminée l'exécution précédente. Lors d'un démarrage normal, la valeur boot est 0x13 (SPI_FAST_FLASH_BOOT), c'est-à-dire que la carte lance son programme depuis la flash. Le tableau résume les codes que tu rencontreras le plus souvent. Les codes de la ROM ne suffisent pas toujours : ESP.restart() et le redémarrage après un Guru Meditation apparaissent tous deux avec le code 0xc, et un brownout s'affiche en 0xc ou en 0x3 selon la version du core. Pour les distinguer, utilise le croquis avec esp_reset_reason() de la section suivante.

Croquis de diagnostic : afficher la cause du redémarrage, la mémoire et la pile

Téléverse le code ci-dessous comme croquis séparé, ou ajoute ses lignes dans le setup() et le loop() de ton projet à problème. À chaque démarrage, la carte écrit dans le moniteur série la cause du redémarrage en texte lisible, le nombre de démarrages et l'état de la mémoire. Le compteur marqué RTC_DATA_ATTR est stocké dans la mémoire RTC : il survit donc aux redémarrages logiciels et au sommeil profond, et n'est remis à zéro que lorsque l'alimentation est complètement coupée. Si le compteur augmente toutes les quelques secondes, tu sais tout de suite que la carte est coincée dans une boucle de redémarrages.

1#include <esp_system.h>
2
3RTC_DATA_ATTR uint32_t bootCount = 0;   // yazılım resetinde korunur / survives software resets
4
5// Reset nedenini okunabilir yazıya çevir / turn the reset reason into readable text
6const char* reasonText(esp_reset_reason_t r) {
7  switch (r) {
8    case ESP_RST_POWERON:   return "POWERON: guc acilisi ya da EN / power-on or EN button";
9    case ESP_RST_SW:        return "SW: ESP.restart()";
10    case ESP_RST_PANIC:     return "PANIC: Guru Meditation";
11    case ESP_RST_INT_WDT:   return "INT_WDT: kesme watchdog'u / interrupt watchdog";
12    case ESP_RST_TASK_WDT:  return "TASK_WDT: gorev watchdog'u / task watchdog";
13    case ESP_RST_WDT:       return "WDT: diger watchdog / other watchdog";
14    case ESP_RST_DEEPSLEEP: return "DEEPSLEEP: derin uykudan uyanma / deep sleep wake-up";
15    case ESP_RST_BROWNOUT:  return "BROWNOUT: gerilim dusmesi / supply voltage dropped";
16    default:                return "UNKNOWN: bilinmiyor / unknown";
17  }
18}
19
20void setup() {
21  Serial.begin(115200);
22  delay(1000);                          // Seri Monitör'ün açılmasını bekle / wait for the Serial Monitor
23  bootCount++;
24  Serial.printf("Acilis sayisi / boot count: %u\n", (unsigned)bootCount);
25  Serial.printf("Reset nedeni / reset reason: %s\n", reasonText(esp_reset_reason()));
26}
27
28void loop() {
29  // Bellek durumu / memory status
30  Serial.printf("Bos heap / free heap: %u B, en dusuk / minimum: %u B, en buyuk blok / largest block: %u B\n",
31                (unsigned)ESP.getFreeHeap(), (unsigned)ESP.getMinFreeHeap(), (unsigned)ESP.getMaxAllocHeap());
32  // loopTask yığınında hiç kullanılmamış en küçük alan / smallest unused space on the loopTask stack
33  Serial.printf("loopTask bos yigin / free stack: %u B\n", (unsigned)uxTaskGetStackHighWaterMark(NULL));
34  delay(5000);
35}

Les valeurs affichées dans la boucle révèlent aussi des problèmes silencieux. Si le tas libre (free heap) baisse un peu à chaque tour, ton programme a une fuite de mémoire et la carte finira par planter. Si le plus grand bloc est bien plus petit que le tas libre, la mémoire est fragmentée ; cela vient généralement d'objets String qui grossissent et rétrécissent sans cesse dans la boucle. Si la pile libre de loopTask descend sous quelques centaines d'octets, le débordement de pile n'est pas loin. Si la cause du redémarrage est BROWNOUT, concentre-toi sur les sections sur l'alimentation ; si c'est PANIC, TASK_WDT ou INT_WDT, sur les sections logicielles qui suivent.

Qu'est-ce qu'un Guru Meditation Error ? Lis le rapport de plantage ligne par ligne

Un Guru Meditation Error est le rapport de plantage qu'affiche le gestionnaire de panique quand le processeur de l'ESP32 rencontre une erreur dont il ne peut pas se remettre ; le nom vient de l'écran d'erreur des anciens ordinateurs Amiga. Le rapport fait peur au premier abord, mais seules quelques lignes comptent. Core 1 indique sur quel cœur l'erreur s'est produite : avec Arduino, setup() et loop() tournent sur le cœur 1, et la pile Wi-Fi sur le cœur 0. Le nom entre parenthèses est le type d'exception. À la fin du rapport, la carte écrit "Rebooting..." et redémarre ; tu verras rst:0xc sur la ligne de démarrage.

LoadProhibited, StoreProhibited et les autres types d'exception

La plus courante de ces erreurs est l'utilisation d'un pointeur nul. NULL correspond à l'adresse 0, et sur l'ESP32 il n'y a pas de mémoire lisible autour de l'adresse 0 : lire là où pointe un pointeur vide provoque donc LoadProhibited, y écrire provoque StoreProhibited. Dans ce cas, EXCVADDR est un indice parfait : 0x00000000 désigne le pointeur lui-même, et de petites valeurs comme 0x00000004 ou 0x00000010 un champ à l'intérieur d'un pointeur vide (NULL plus la position du champ). Dans les projets Arduino, la cause la plus fréquente est une fonction qui renvoie NULL pour dire "pas trouvé", valeur ensuite utilisée sans vérification. Dans l'exemple ci-dessous, strstr() renvoie NULL s'il ne trouve pas le texte ; sans vérification, la carte plante avec EXCVADDR 0x00000005.

1const char* response = "temp=23.5;hum=40";   // sunucudan gelen yanıt / reply from a server
2
3void setup() {
4  Serial.begin(115200);
5  delay(500);
6
7  // YANLIŞ: "pres=" yoksa strstr NULL döner ve kart çöker (EXCVADDR 0x00000005)
8  // WRONG: if "pres=" is missing strstr returns NULL and the board crashes (EXCVADDR 0x00000005)
9  // float pressure = atof(strstr(response, "pres=") + 5);
10
11  // DOĞRU: işaretçiyi kullanmadan önce NULL kontrolü yap / RIGHT: check for NULL before using the pointer
12  const char* found = strstr(response, "pres=");
13  if (found != nullptr) {
14    float pressure = atof(found + 5);
15    Serial.println(pressure);
16  } else {
17    Serial.println("pres alani bulunamadi / pres field not found");
18  }
19}
20
21void loop() {
22}

Débordement de pile : l'erreur "Stack canary watchpoint triggered"

Sur l'ESP32, chaque tâche (task) possède une pile (stack) de taille fixe, où sont stockés les variables locales, les appels de fonctions et les adresses de retour. Avec Arduino, la tâche loopTask qui exécute setup() et loop() a une pile de 8192 octets. Déclarer un tableau local de 10 000 octets dans loop(), une fonction qui s'appelle elle-même (récursive) ou une fonction de bibliothèque avec beaucoup de variables locales dépasse cette limite. À la fin de la pile se trouve une zone de garde (canary) ; quand la pile l'atteint, la carte écrit Guru Meditation Error: Core 1 panic'ed (Unhandled debug exception) et juste en dessous Debug exception reason: Stack canary watchpoint triggered (loopTask). Le nom entre parenthèses est celui de la tâche dont la pile a débordé. Le même problème apparaît parfois sous la forme ***ERROR*** A stack overflow in task loopTask has been detected. Voici comment le régler :

• Sors les grands tableaux de la pile : déclare le tableau en global ou ajoute static devant ; il est alors placé dans la RAM permanente et non sur la pile.
• Agrandis la pile de loopTask : écris SET_LOOP_TASK_STACK_SIZE(16 * 1024); tout en haut du croquis pour porter la pile de loop() à 16 Ko.
• Donne assez de place à tes tâches : sur l'ESP32, la taille de pile passée à xTaskCreate et xTaskCreatePinnedToCore s'exprime en octets, et non en mots (words) comme avec FreeRTOS sur d'autres plateformes. 1024 octets ne suffisent même pas pour une tâche qui utilise Serial.printf ; commence avec 4096.
• Mesure : uxTaskGetStackHighWaterMark(NULL) renvoie, en octets, la plus petite quantité de pile que la tâche n'a encore jamais utilisée ; si elle descend sous quelques centaines d'octets, agrandis la pile.
• Évite la récursivité : transforme les fonctions qui s'appellent elles-mêmes en boucles ou limite leur profondeur.

Watchdog des tâches : l'erreur "task_wdt: Task watchdog got triggered"

Un watchdog (chien de garde) est une minuterie qui détecte un programme bloqué et sauve la carte. Le watchdog des tâches (Task WDT) de l'ESP32 attend que les tâches qui lui sont inscrites donnent signe de vie à intervalles réguliers. Dans le core Arduino, il surveille par défaut la tâche inactive (IDLE) du cœur 0, avec un délai de 5 secondes. Si une tâche du cœur 0 ne libère pas le processeur pendant 5 secondes, la tâche IDLE ne peut pas s'exécuter et le moniteur série affiche un message qui commence par E (10257) task_wdt: Task watchdog got triggered. Viennent ensuite la liste des tâches qui n'ont pas réarmé le watchdog à temps (le plus souvent - IDLE (CPU 0)) puis, sous Tasks currently running:, les tâches en cours d'exécution à cet instant. Dans le core Arduino, cela déclenche une panique avec la ligne task_wdt: Aborting. et la carte redémarre.

Les causes les plus fréquentes sont : une boucle placée sur le cœur 0 avec xTaskCreatePinnedToCore sans le moindre vTaskDelay(), une boucle while qui attend la réponse d'un capteur sans délai maximal, ou des delay() et des opérations longues dans les fonctions de rappel (callbacks) de bibliothèques comme AsyncWebServer. Dans ce dernier cas, tu verras la tâche async_tcp dans la liste à la place d'IDLE. La solution consiste à découper les longs traitements en petits morceaux et à ajouter de courtes attentes comme vTaskDelay(1) dans les boucles. La fonction loop() elle-même n'est pas surveillée par défaut ; si tu veux, appelle enableLoopWDT() dans setup() pour que la carte redémarre aussi quand loop() reste bloquée plus de 5 secondes. Couper le watchdog avec disableCore0WDT() masque l'erreur mais ne corrige pas le code bloqué. Pour en savoir plus sur les tâches et les cœurs, consulte FreeRTOS et double cœur sur l'ESP32. Le code ci-dessous montre une structure de tâche correcte et les précautions contre le débordement de pile :

1SET_LOOP_TASK_STACK_SIZE(16 * 1024);   // loop() yığını 8 KB yerine 16 KB / loop() stack 16 KB instead of 8 KB
2
3volatile uint32_t sampleCount = 0;
4
5// 0. çekirdekte çalışan görev / task running on core 0
6void sensorTask(void* parameter) {
7  for (;;) {
8    sampleCount = sampleCount + 1;       // sensörünü burada oku / read your sensor here
9    vTaskDelay(pdMS_TO_TICKS(10));       // IDLE görevine sıra ver, task_wdt tetiklenmez / let IDLE run, no task_wdt
10  }
11}
12
13void setup() {
14  Serial.begin(115200);
15  // Yığın boyutu bayt cinsindendir: 4096 bayt / stack size is in bytes: 4096 bytes
16  xTaskCreatePinnedToCore(sensorTask, "sensorTask", 4096, NULL, 1, NULL, 0);
17}
18
19void loop() {
20  static uint8_t buffer[10000];          // static: yığında değil kalıcı RAM'de / static: in RAM, not on the stack
21  memset(buffer, 0, sizeof(buffer));
22
23  Serial.printf("Ornek / samples: %u, loopTask bos yigin / free stack: %u B\n",
24                (unsigned)sampleCount, (unsigned)uxTaskGetStackHighWaterMark(NULL));
25  delay(1000);
26}

Interrupt wdt timeout et IRAM_ATTR : plantages dans les interruptions

Le watchdog des interruptions (Interrupt WDT) est bien plus impatient : si une routine d'interruption (ISR) ou un morceau de code avec les interruptions désactivées dépasse 300 ms, la carte plante avec Guru Meditation Error: Core 1 panic'ed (Interrupt wdt timeout on CPU1). Utiliser Serial.print, delay(), l'I2C ou le Wi-Fi dans une ISR est la cause la plus fréquente. La mémoire flash est un autre piège : pendant que Preferences, EEPROM ou LittleFS écrivent dans la flash, le cache de la flash est coupé un instant. Si une interruption arrive à ce moment et que sa fonction se trouve en flash, la carte affiche Cache disabled but cached memory region accessed. La solution consiste à marquer les ISR avec IRAM_ATTR pour les placer en RAM et à n'y lever qu'un drapeau ; le vrai travail est fait dans loop(). Les variables partagées entre une ISR et loop() doivent être volatile.

1const int BUTTON_PIN = 27;              // buton GPIO 27 ile GND arasında / button between GPIO 27 and GND
2volatile bool buttonPressed = false;    // ISR ile loop arasında paylaşılan bayrak / flag shared by the ISR and loop
3uint32_t pressCount = 0;
4
5void IRAM_ATTR onButton() {             // IRAM_ATTR: fonksiyon flaşta değil RAM'de durur / the function lives in RAM, not flash
6  buttonPressed = true;                 // yalnızca bayrak kaldır, Serial yok / only set a flag, no Serial
7}
8
9void setup() {
10  Serial.begin(115200);
11  pinMode(BUTTON_PIN, INPUT_PULLUP);
12  attachInterrupt(digitalPinToInterrupt(BUTTON_PIN), onButton, FALLING);
13}
14
15void loop() {
16  if (buttonPressed) {
17    buttonPressed = false;
18    pressCount++;
19    Serial.printf("Butona basildi / button pressed: %u\n", (unsigned)pressCount);   // yavaş iş burada / slow work here
20  }
21}

Traduire le Backtrace en ligne de code avec ESP Exception Decoder

Les adresses de la ligne Backtrace ne disent rien à elles seules ; l'outil qui les traduit en fichier, fonction et numéro de ligne de ton code source s'appelle ESP Exception Decoder. Dans l'ancien IDE Arduino 1.8, c'était un module ajouté au menu Outils. Dans l'IDE Arduino 2, on utilise une extension de la communauté qui porte le même nom :

1. Télécharge le fichier avec l'extension .vsix dans la section Releases du projet dankeboy36/esp-exception-decoder sur GitHub. Pour l'IDE Arduino 2, choisis une version 1.x ; les nouvelles versions 2.x sont prévues pour VS Code.
2. Ferme l'IDE Arduino et copie le fichier dans %UserProfile%\.arduinoIDE\plugins sous Windows ou dans ~/.arduinoIDE/plugins sous macOS et Linux ; crée le dossier s'il n'existe pas.
3. Ouvre l'IDE et le croquis qui plante, compile-le avec Vérifier et téléverse-le sur la carte.
4. Ouvre le moniteur série et attends que le plantage se reproduise.
5. Ouvre la palette de commandes avec Ctrl+Maj+P (Cmd+Shift+P sous macOS) et lance ESP Exception Decoder: Show Decoder Terminal.
6. Copie dans le moniteur série le bloc Guru Meditation avec la ligne Backtrace et colle-le dans le terminal qui s'ouvre ; l'outil affiche chaque adresse avec le nom du fichier, la fonction et le numéro de ligne.

Si tu ne peux pas installer l'extension, tu peux faire la même chose à la main. Le menu Sketch > Export Compiled Binary dépose un fichier avec l'extension .elf dans le dossier build, à l'intérieur du dossier du croquis. La commande xtensa-esp32-elf-addr2line -pfiaC -e sketch.ino.elf 0x400d1a29 0x400d0f6e de la chaîne d'outils de l'ESP32 traduit ces adresses en noms de fonctions et numéros de ligne. Si tu utilises PlatformIO, il suffit d'ajouter la ligne monitor_filters = esp32_exception_decoder dans le fichier platformio.ini ; le rapport de plantage est alors décodé automatiquement dans le moniteur série.

Broches de strapping : comment GPIO0, GPIO2, GPIO12 et GPIO15 perturbent le démarrage

Au démarrage, l'ESP32 regarde le niveau de certaines broches pour décider comment démarrer. Ce sont les broches de strapping, et seul leur niveau au moment de la réinitialisation compte ; une fois le démarrage terminé, elles s'utilisent comme des GPIO normales. Le problème survient quand un capteur, un bouton ou un module branché dessus tire la broche au mauvais niveau au démarrage. La carte ne lance alors pas son programme, passe en mode programmation ou ne peut pas lire la flash ; vu de l'extérieur, cela ressemble aussi à "l'ESP32 ne démarre pas" ou à "il redémarre sans arrêt". Tu peux voir le brochage complet de ta carte dans l'outil Pinout.

Les cartes plus récentes ont d'autres broches de strapping : sur l'ESP32-S3, ce sont GPIO0, GPIO3, GPIO45 et GPIO46 qui influencent le démarrage, et sur l'ESP32-C3, GPIO2, GPIO8 et GPIO9. L'ESP32-S3 utilise les mêmes noms d'exception Xtensa que l'ESP32 classique. Sur l'ESP32-C3 à cœur RISC-V, en revanche, tu verras Load access fault au lieu de LoadProhibited et Store access fault au lieu de StoreProhibited, et le registre MTVAL joue le rôle d'EXCVADDR. Le message de brownout est le même sur tous les modèles.

ESP32 et Raspberry Pi Pico avec MicroPython

Si tu programmes l'ESP32 en MicroPython, le brownout se produit exactement de la même façon, car le problème est matériel et non logiciel. Les erreurs du code Python, elles, apparaissent sous forme de Traceback lisible au lieu d'un Guru Meditation, et la carte plante rarement. Tu peux lire la cause du redémarrage avec machine.reset_cause(), mais attention : la version de MicroPython pour ESP32 ne renvoie pas de valeur propre au brownout, elle le signale comme PWRON_RESET, au même titre qu'une mise sous tension. Si la carte redémarre sans cesse avec PWRON_RESET alors que tu n'y touches pas, soupçonne à nouveau l'alimentation. Le code ci-dessous est destiné à l'ESP32 ; sur le Raspberry Pi Pico, le module machine connaît moins de types de redémarrage. Sur le Pico, le régulateur buck-boost de l'entrée VSYS fonctionne avec toute tension entre 1,8 et 5,5 V, si bien que les problèmes de brownout y sont beaucoup plus rares ; pour découvrir la carte, lis Qu'est-ce que le Raspberry Pi Pico ?

1import machine, gc, time
2
3# Reset nedenleri (ESP32 için) / reset causes (for ESP32)
4causes = {
5    machine.PWRON_RESET: "PWRON: guc acilisi ya da brownout / power-on or brownout",
6    machine.HARD_RESET: "HARD: cokme ya da machine.reset() / crash or machine.reset()",
7    machine.WDT_RESET: "WDT: watchdog",
8    machine.DEEPSLEEP_RESET: "DEEPSLEEP: derin uykudan uyanma / deep sleep wake-up",
9    machine.SOFT_RESET: "SOFT: Ctrl+D ile yazilim reseti / soft reset with Ctrl+D",
10}
11print("Reset nedeni / reset cause:", causes.get(machine.reset_cause(), "bilinmiyor / unknown"))
12
13while True:
14    gc.collect()                                     # çöp toplayıcıyı çalıştır / run the garbage collector
15    print("Bos RAM / free RAM:", gc.mem_free(), "bayt / bytes")
16    time.sleep(5)

Erreurs fréquentes et solutions

Ta carte est stable : et maintenant ?

• Appareil économe sur batterie : avec le deep sleep de l'ESP32, endors la carte entre deux mesures et descends à quelques microampères.
• Mises à jour sans fil : téléverse ton code sans câble USB grâce à l'OTA sur ESP32.
• Tableau de bord en temps réel : suis les données des capteurs en direct dans le navigateur avec WebSocket sur ESP32.
• Envoyer des notifications : avec un bot Telegram sur ESP32, reçois sur ton téléphone la cause du redémarrage à chaque fois que la carte redémarre.
• Spectacle lumineux : pilote en toute sécurité un ruban WS2812B NeoPixel avec une alimentation séparée.

La plupart des problèmes de redémarrage de l'ESP32 sont soit un souci d'alimentation, soit quelques lignes de code fautives ; quand tu lis correctement le message, les deux se règlent vite. Pour revoir les bases de la carte, jette un œil à Qu'est-ce que l'ESP32 ? Dans l'application BlueGrays, tu trouveras des projets ESP32 avec des LED, des servos, des rubans NeoPixel, la connexion Wi-Fi, un serveur web, les mises à jour OTA et le deep sleep, chacun avec son schéma de câblage et son code pas à pas, pour essayer dans de vrais projets les techniques d'alimentation et de diagnostic apprises ici.