ESP32: Brownout detector was triggered и Guru Meditation — как исправить

Сообщение ESP32 brownout detector was triggered означает, что напряжение питания платы на мгновение упало ниже безопасного предела и микросхема перезапустилась, чтобы не работать со сбоями. Проблема почти никогда не в коде, а в питании: слабый USB-порт, тонкий и длинный кабель, слабый стабилизатор или сервоприводы и светодиодные ленты, которые питаются от той же линии, что и ESP32. Вторая крупная причина, по которой ESP32 постоянно перезагружается, — программный сбой; в этом случае в мониторе порта появляются строки вроде Guru Meditation Error, task_wdt или Stack canary.

Хорошая новость: ESP32 сама сообщает, почему перезапустилась, нужно только уметь читать её сообщения. В этом руководстве сначала разберём коды rst в строках загрузки и сообщения об ошибках, потом навсегда избавимся от просадок питания с помощью правильного источника питания, кабеля и конденсатора. Затем перейдём к ошибкам Guru Meditation вроде LoadProhibited и StoreProhibited, переполнению стека, нулевым указателям и таймаутам сторожевого таймера, а с помощью ESP Exception Decoder отследим сбой до конкретной строки кода. В конце посмотрим на пины конфигурации при старте (strapping: GPIO0, 2, 12 и 15), которые могут сорвать загрузку.

Почему ESP32 постоянно перезагружается? Сначала прочитай сообщение

Прежде чем искать неисправность, открой монитор порта на скорости 115200 бод и нажми кнопку EN на плате. При каждой загрузке встроенный в ПЗУ загрузчик ESP32 сначала печатает строку с датой вроде «ets Jun 8 2016 00:22:57», а затем строку вида rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT). Часть rst говорит, почему плата перезапустилась, а часть boot — в каком режиме она стартовала. Если плата застряла в цикле перезагрузок, прямо над этими строками будет сообщение об ошибке, последние слова предыдущего запуска. В таблице ниже собраны сообщения, которые встречаются чаще всего, и то, с чего начинать:

Что такое «Brownout detector was triggered» и почему это происходит?

Brownout — это кратковременная просадка напряжения без полного пропадания питания. В ESP32 есть детектор просадки питания (brownout detector), который постоянно следит за линией питания, и в ядре Arduino его порог выставлен на самый низкий уровень, около 2,43 V. Как только напряжение падает ниже этого значения, микросхема защищает радиомодуль и флеш-память, печатает в монитор порта «Brownout detector was triggered» и перезапускается. Причина простая: при низком напряжении флеш-память может читаться с ошибками, сохранённые данные могут испортиться, а процессор может выполнять случайные инструкции. Детектор заставляет плату чисто перезагрузиться, вместо того чтобы вести себя непредсказуемо. Модуль ESP32-WROOM-32 рассчитан на работу от 3,0 до 3,6 V, так что когда напряжение на линии доходит до 2,43 V, оно уже давно за пределами безопасной зоны.

После сообщения о просадке в строке загрузки, в зависимости от версии ядра Arduino, будет rst:0xc (SW_CPU_RESET) или rst:0x3 (SW_RESET), потому что прерывание детектора печатает сообщение, а затем перезапускает микросхему программно. Пусть это не сбивает с толку: тот же код записывает в память микросхемы, что причиной была просадка питания, и esp_reset_reason() возвращает ESP_RST_BROWNOUT. Если же срабатывает собственный аппаратный сброс по просадке, в строке будет rst:0xf (RTCWDT_BROWN_OUT_RESET). В ядрах 3.x на основе ESP-IDF 5 эта строка стала информационным сообщением журнала (I BOD: Brownout detector was triggered). Поскольку предварительно скомпилированные библиотеки Arduino выводят только сообщения уровня ошибки, это сообщение обычно вообще не появляется, и плата перезапускается молча; если при старте виден необъяснимый rst:0x3 или rst:0xc, посмотри причину сброса через диагностический скетч ниже. Чтобы понять, почему проседает напряжение, посмотри, какой ток потребляет ESP32:

Разрыв в этой таблице и есть суть проблемы: пока код не включил Wi-Fi, плата спокойно работает примерно на 50 mA, но на строке WiFi.begin() ток за несколько микросекунд вырастает в пять-шесть раз. Если источник питания, кабель и стабилизатор не успевают за таким резким скачком, напряжение проваливается. Поэтому Espressif рекомендует для ESP32 источник питания, способный отдавать не меньше 500 mA. Симптом очень знакомый: плата загружается, печатает в монитор порта несколько строк, сбрасывается в момент запуска Wi-Fi или Bluetooth, и всё превращается в бесконечный цикл. То же самое может случиться, когда двигается сервопривод, щёлкает реле или светодиодная лента загорается белым.

Самые частые причины просадки питания

• Тонкий или длинный USB-кабель: тонкие силовые жилы в дешёвых кабелях могут давать в сумме до 0,5 Ω туда и обратно. По закону Ома пик в 400 mA теряет на таком кабеле 0,2 V.
• Слабый USB-порт или хаб: порты на клавиатурах и мониторах, хабы без внешнего питания и передние порты некоторых ноутбуков дают напряжению просесть при пиковом токе.
• Падение напряжения на стабилизаторе (dropout): AMS1117, который стоит на большинстве плат, требует разницы 1,0–1,3 V между входом и выходом. Если напряжение на пине 5V падает примерно ниже 4,3 V, выход уже не может удержать 3,3 V.
• Батарея напрямую: если подключить Li-ion аккумулятор на 3,7 V к пину 5V, из-за падения напряжения на стабилизаторе выход опустится ниже 3 V; две батарейки AA под нагрузкой быстро проседают ниже минимума ESP32.
• Пин 3.3V на Arduino Uno: с этого пина рекомендуется брать всего около 50 mA; для ESP32 с включённым Wi-Fi этого совсем не достаточно.
• Нагрузки на той же линии: если сервоприводы, реле, зуммеры, DC-моторы или лента WS2812B питаются от тех же 5 V, что и ESP32, каждое их движение тянет напряжение вниз.
• Макетные платы и перемычки: разболтанные контакты и тонкие перемычки добавляют немного сопротивления в каждом соединении; если вести питание через макетную плату, становится только хуже.
• ESP32-CAM: когда одновременно работают камера, Wi-Fi и вспышка, ток становится очень большим; этой плате нужны 5 V и не меньше 2 A. Подробности — в руководстве по ESP32-CAM.

Решение 1: улучши питание и кабель

Первый и самый действенный шаг — более мощное питание. Подключи плату коротким толстым кабелем с передачей данных, в котором нет сомнений, напрямую к USB-порту на задней панели компьютера или к адаптеру 5 V, рассчитанному минимум на 1 A. Порты USB 2.0 рассчитаны на 500 mA, а USB 3.0 — на 900 mA; рекомендованные Espressif 500 mA — это ровно предел порта USB 2.0, поэтому, как только добавляются потери в кабеле, начинаются проблемы. Если одна только замена кабеля убирает ошибку, виновато, скорее всего, было его сопротивление. Сколько напряжения теряет кабель, можно посчитать по формуле V = I × R в калькуляторе закона Ома.

Проекты на батарейках требуют особого внимания. Li-ion аккумулятор вроде 18650 полностью заряженным даёт 4,2 V, а разряженным — около 3,0 V. Такой диапазон не подходит ни для прямого подключения к пину 3V3 (4,2 V больше предела 3,6 V), ни для пина 5V с его AMS1117. Правильное решение — либо подавать питание от аккумулятора через повышающий модуль на 5 V на пин 5V, либо питать линию 3V3 напрямую через LDO-стабилизатор с малым падением напряжения, рассчитанный минимум на 500 mA (например, ME6211 или HT7833), плюс конденсатор. Сколько проект проработает от батареи, можно оценить в калькуляторе времени работы от батареи, а про схему зарядки рассказано в руководстве по модулю зарядки TP4056.

Решение 2: добавь конденсатор между 3V3 и GND

Конденсатор работает как маленький резервуар: во время пика тока он сам отдаёт энергию, пока стабилизатор и кабель не догонят. Поставь электролитический конденсатор на 100–470 µF между пинами 3V3 и GND платы, как можно ближе к ней, а рядом — керамический конденсатор на 100 nF. Электролитический справляется с провалами длительностью в миллисекунды, керамический — с очень короткими высокочастотными пульсациями. Эффект можно грубо оценить по формуле ΔV = I × Δt / C: даже если конденсатор на 470 µF в одиночку отдаёт дополнительные 200 mA в течение 200 µs, напряжение падает всего на 0,085 V. Маркировка 104 на керамическом конденсаторе означает 100 nF; другие коды можно расшифровать в утилите кодов конденсаторов.

Решение 3: питай сервоприводы, моторы и светодиодные ленты отдельно

Даже если сама ESP32 питается правильно, нагрузки на той же линии могут тянуть напряжение вниз. Даже маленький сервопривод вроде SG90 в момент начала движения потребляет несколько сотен mA; светодиод WS2812B на полном белом берёт около 60 mA, так что лента на 30 светодиодов может дойти до 1,8 A. Питай такие нагрузки не от пина 5V или 3V3 ESP32, а от отдельного источника 5 V; например, адаптер на 12 V можно понизить до 5 V понижающим модулем LM2596. Самое важное правило — соединить GND обоих источников; без общей земли у сигнальной линии нет опорного уровня, и сервопривод или лента ведут себя случайным образом. Подробно об этом — в статьях Arduino постоянно перезагружается? и GND и общая земля.

Отключить детектор просадки — это решение?

Самое популярное «решение» в интернете — отключить детектор одной строкой. Код ниже отключает детектор, обнуляя регистр brownout в ESP32, и сообщение об ошибке пропадает. Но провалы напряжения никуда не деваются; просто никто больше о них не предупреждает. Используй этот код только для диагностики: если с отключённым детектором плата работает без проблем, это подтверждает, что дело точно в питании. После этого удали строку и исправь питание.

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}

Коды причины rst: ESP32 сообщает, почему перезапустилась

Значение rst:, которое ПЗУ печатает при каждой загрузке, показывает, чем закончился предыдущий запуск. При нормальной загрузке значение boot равно 0x13 (SPI_FAST_FLASH_BOOT): плата запускает программу из флеш-памяти. В таблице ниже — коды, которые встречаются чаще всего. Одних кодов ПЗУ не всегда достаточно: и ESP.restart(), и перезапуск после Guru Meditation выглядят как 0xc, а просадка питания в зависимости от версии ядра появляется как 0xc или 0x3. Чтобы их различить, используй скетч с esp_reset_reason() из следующего раздела.

Диагностический скетч: вывести причину сброса, память и стек

Загрузи код ниже отдельным скетчем или добавь его строки в setup() и loop() проблемного проекта. При каждом запуске плата выводит в монитор порта причину сброса понятным текстом, номер загрузки по счёту и состояние памяти. Счётчик, помеченный RTC_DATA_ATTR, хранится в памяти RTC, поэтому переживает программные сбросы и глубокий сон и обнуляется только при полном отключении питания. Если счётчик растёт каждые несколько секунд, сразу ясно: плата в цикле перезагрузок.

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}

Значения, которые печатаются в цикле, выдают и скрытые проблемы. Если свободная куча (free heap) немного уменьшается при каждом проходе, в программе утечка памяти, и плата рано или поздно упадёт. Если самый большой блок намного меньше свободной кучи, память фрагментирована; обычно виноваты объекты String, которые постоянно растут и уменьшаются внутри цикла. Если свободный стек loopTask опускается ниже нескольких сотен байт, переполнение стека совсем близко. Если причина сброса — BROWNOUT, сосредоточься на разделах про питание; если PANIC, TASK_WDT или INT_WDT — на программных разделах ниже.

Что такое Guru Meditation Error? Читаем отчёт о сбое строка за строкой

Guru Meditation Error — это отчёт о сбое, который печатает обработчик паники, когда процессор ESP32 сталкивается с ошибкой, после которой не может продолжить работу; название пришло с экрана ошибок старых компьютеров Amiga. Сначала отчёт выглядит пугающе, но важны в нём всего несколько строк. Core 1 показывает, на каком ядре произошла ошибка: в Arduino setup() и loop() работают на ядре 1, а стек Wi-Fi — на ядре 0. Имя в скобках — тип исключения. Когда отчёт заканчивается, плата печатает «Rebooting...» и перезапускается; в строке загрузки будет rst:0xc.

LoadProhibited, StoreProhibited и другие типы исключений

Самая частая из этих ошибок — использование нулевого указателя (null pointer). NULL — это адрес 0, а в ESP32 вокруг адреса 0 нет читаемой памяти, поэтому чтение оттуда, куда указывает пустой указатель, даёт LoadProhibited, а запись туда — StoreProhibited. EXCVADDR в этом случае — отличная подсказка: 0x00000000 означает обращение прямо по нулевому указателю, а маленькие значения вроде 0x00000004 или 0x00000010 — к полю внутри объекта по пустому указателю (NULL плюс смещение поля). В проектах Arduino чаще всего функция возвращает NULL в значении «не найдено», а это значение используется без проверки. В примере ниже strstr() возвращает NULL, если не находит текст; без проверки плата падает с 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}

Переполнение стека: ошибка «Stack canary watchpoint triggered»

В ESP32 у каждой задачи (task) есть стек фиксированного размера, где хранятся локальные переменные, вызовы функций и адреса возврата. В Arduino у задачи loopTask, которая выполняет setup() и loop(), стек размером 8192 байта. Локальный массив на 10 000 байт внутри loop(), функция, которая вызывает сама себя (рекурсия), или библиотечная функция с большим числом локальных переменных выйдут за этот предел. В конце стека есть защитная область (canary); когда стек до неё доходит, плата печатает Guru Meditation Error: Core 1 panic'ed (Unhandled debug exception) и сразу под этим Debug exception reason: Stack canary watchpoint triggered (loopTask). Имя в скобках — задача, у которой переполнился стек. Иногда та же проблема выглядит как сообщение ***ERROR*** A stack overflow in task loopTask has been detected (обнаружено переполнение стека в задаче loopTask). Вот как это исправить:

• Убери большие массивы из стека: объяви массив глобально или добавь перед ним static; тогда он будет жить в постоянной RAM, а не в стеке.
• Увеличь стек loopTask: добавь в самый верх скетча SET_LOOP_TASK_STACK_SIZE(16 * 1024);, чтобы увеличить стек loop() до 16 КБ.
• Дай своим задачам достаточно места: в ESP32 размер стека, который передаётся в xTaskCreate и xTaskCreatePinnedToCore, указывается в байтах, а не в словах, как во FreeRTOS на других платформах. 1024 байта мало даже для задачи, которая использует Serial.printf; начни с 4096.
• Измеряй: uxTaskGetStackHighWaterMark(NULL) возвращает в байтах наименьший объём стека, который задача до сих пор ни разу не использовала; если он опускается ниже нескольких сотен байт, увеличь стек.
• Избегай рекурсии: преврати функции, которые вызывают сами себя, в циклы или ограничь глубину вызовов.

Сторожевой таймер задач: ошибка «task_wdt: Task watchdog got triggered»

Сторожевой таймер (watchdog) — это таймер, который замечает зависшую программу и спасает плату. Сторожевой таймер задач (Task WDT) в ESP32 ожидает, что зарегистрированные в нём задачи будут через равные промежутки подавать сигнал «я жив». В ядре Arduino по умолчанию он следит за задачей простоя (IDLE) ядра 0, а его таймаут — 5 секунд. Если задача, работающая на ядре 0, 5 секунд не отдаёт процессор, задача IDLE не может выполниться, и в мониторе порта появляется сообщение, начинающееся с E (10257) task_wdt: Task watchdog got triggered. За ним идут список задач, которые не сбросили сторожевой таймер вовремя (обычно - IDLE (CPU 0)), и под заголовком Tasks currently running: задачи, которые выполнялись в этот момент. В ядре Arduino это вызывает панику со строкой task_wdt: Aborting., и плата перезапускается.

Самые частые причины: цикл, закреплённый за ядром 0 через xTaskCreatePinnedToCore, в котором ни разу не вызывается vTaskDelay(); цикл while, который ждёт ответа датчика без таймаута; или delay() и долгие операции внутри обратных вызовов таких библиотек, как AsyncWebServer. В последнем случае в списке вместо IDLE будет задача async_tcp. Решение — разбивать долгие операции на маленькие части и добавлять в циклы короткие паузы вроде vTaskDelay(1). Сама функция loop() по умолчанию не отслеживается; при желании вызови в setup() enableLoopWDT(), и плата будет перезапускаться также, если loop() зависнет дольше чем на 5 секунд. Отключение сторожевого таймера через disableCore0WDT() прячет ошибку, но не исправляет зависший код. Подробнее о задачах и ядрах — в статье FreeRTOS и два ядра ESP32. Код ниже показывает и правильную структуру задачи, и меры против переполнения стека:

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 и IRAM_ATTR: сбои в прерываниях

Сторожевой таймер прерываний (Interrupt WDT) куда менее терпелив: если обработчик прерывания (ISR) или участок кода с отключёнными прерываниями выполняется дольше 300 мс, плата падает с Guru Meditation Error: Core 1 panic'ed (Interrupt wdt timeout on CPU1). Чаще всего причина в Serial.print, delay(), I2C или Wi-Fi внутри ISR. Ещё одна ловушка — флеш-память: пока Preferences, EEPROM или LittleFS пишут во флеш, кэш флеш-памяти на мгновение отключается. Если в этот момент приходит прерывание, а его обработчик лежит во флеш-памяти, плата сообщает Cache disabled but cached memory region accessed. Решение — пометить ISR атрибутом IRAM_ATTR, чтобы они жили в RAM, и внутри только поднимать флаг; настоящую работу выполняет loop(). Переменные, общие для ISR и loop(), должны быть 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}

Превращаем Backtrace в строку кода с ESP Exception Decoder

Адреса в строке Backtrace сами по себе ничего не говорят; инструмент, который превращает их в файл, функцию и номер строки исходного кода, называется ESP Exception Decoder. В старой Arduino IDE 1.8 это был плагин в меню «Инструменты». В Arduino IDE 2 используется одноимённое расширение, созданное сообществом:

1. Скачай файл .vsix из раздела Releases проекта dankeboy36/esp-exception-decoder на GitHub. Для Arduino IDE 2 выбирай релиз 1.x; новые релизы 2.x сделаны для VS Code.
2. Закрой Arduino IDE и скопируй файл в папку %UserProfile%\.arduinoIDE\plugins на Windows или ~/.arduinoIDE/plugins на macOS и Linux; если папки нет, создай её.
3. Запусти IDE, открой скетч, который падает, скомпилируй его кнопкой Проверить (Verify) и загрузи в плату.
4. Открой монитор порта и дождись, пока сбой повторится.
5. Открой палитру команд сочетанием Ctrl+Shift+P (Cmd+Shift+P на macOS) и выполни ESP Exception Decoder: Show Decoder Terminal.
6. Скопируй из монитора порта блок Guru Meditation вместе со строкой Backtrace и вставь его в открывшийся терминал; инструмент покажет для каждого адреса имя файла, функцию и номер строки.

Если расширение установить не получается, то же самое можно сделать вручную. Меню Sketch › Export Compiled Binary («Скетч › Экспорт скомпилированного бинарного файла») кладёт файл с расширением .elf в папку build внутри папки скетча. Команда xtensa-esp32-elf-addr2line -pfiaC -e sketch.ino.elf 0x400d1a29 0x400d0f6e из набора инструментов ESP32 превращает эти адреса в имена функций и номера строк. Если ты работаешь в PlatformIO, достаточно добавить строку monitor_filters = esp32_exception_decoder в platformio.ini; тогда вывод сбоя расшифровывается в мониторе порта автоматически.

Пины конфигурации при старте: как GPIO0, GPIO2, GPIO12 и GPIO15 могут сорвать загрузку

При запуске ESP32 смотрит на уровень некоторых пинов, чтобы решить, как загружаться. Это пины конфигурации при старте (strapping pins), и важен только их уровень в момент сброса; после загрузки их можно использовать как обычные GPIO. Проблема возникает, когда подключённый к одному из них датчик, кнопка или модуль тянет пин к неправильному уровню во время старта. Тогда плата вообще не запускает программу, входит в режим программирования или не может прочитать флеш-память; со стороны это тоже выглядит как «ESP32 не загружается» или «постоянно перезагружается». Полную карту пинов своей платы можно посмотреть в утилите распиновки.

У новых плат пины конфигурации при старте другие: у ESP32-S3 это GPIO0, GPIO3, GPIO45 и GPIO46, а у ESP32-C3 на загрузку влияют GPIO2, GPIO8 и GPIO9. ESP32-S3 использует те же имена исключений Xtensa, что и классическая ESP32. А вот на ESP32-C3 на базе RISC-V вместо LoadProhibited будет Load access fault, вместо StoreProhibited — Store access fault, а роль EXCVADDR берёт на себя регистр MTVAL. Сообщение о просадке питания одинаково на всех моделях.

ESP32 и Raspberry Pi Pico в MicroPython

Если ESP32 программируется на MicroPython, просадки питания происходят точно так же, потому что проблема в железе, а не в программе. А вот ошибки в коде Python выглядят не как Guru Meditation, а как понятный Traceback, и плата падает редко. Причину сброса можно прочитать через machine.reset_cause(), но учти: порт MicroPython для ESP32 не возвращает просадку питания отдельным значением, а сообщает о ней как о PWRON_RESET, так же как о включении питания. Если плата, которую никто не трогает, постоянно стартует с PWRON_RESET, снова подозревай питание. Код ниже — для ESP32; на Raspberry Pi Pico модуль machine знает меньше типов сброса. У Pico понижающе-повышающий стабилизатор на входе VSYS работает с любым напряжением от 1,8 до 5,5 V, поэтому проблемы с просадкой там встречаются гораздо реже; чтобы познакомиться с платой, загляни в статью Что такое 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)

Частые ошибки и их решения

Плата работает стабильно: что дальше?

• Устройство, бережное к батарее: с глубоким сном ESP32 плата спит между измерениями и потребляет ток на уровне микроампер.
• Обновления по воздуху: загружай код без USB-кабеля с помощью ESP32 OTA.
• Панель в реальном времени: смотри данные датчиков в браузере вживую через ESP32 WebSocket.
• Уведомления: с Telegram-ботом на ESP32 причина сброса будет приходить на телефон при каждом перезапуске платы.
• Световое шоу: безопасно управляй лентой WS2812B NeoPixel с отдельным питанием.

Большинство проблем с перезагрузкой ESP32 — это либо питание, либо несколько строк кода с ошибкой; если правильно прочитать сообщение, и то и другое исправляется быстро. Чтобы освежить основы, загляни в статью Что такое ESP32? В приложении BlueGrays есть проекты на ESP32 со светодиодами, сервоприводами, лентами NeoPixel, подключением к Wi-Fi, веб-сервером, OTA-обновлениями и глубоким сном, у каждого пошаговая схема и код, так что приёмы питания и диагностики из этой статьи можно сразу опробовать в настоящих проектах.