Core dump в ESP-IDF

Устройство перезагрузилось ночью, а лог с backtrace никто не видел. Core dump решает эту задачу: при панике ESP-IDF сохраняет стеки и регистры всех задач в раздел флеш, а утром их можно вытащить и открыть в GDB, как будто сбой случился только что.

Обновлено 4 ноября 2026 г.Редакция GAW

Содержание

Куда и что сохраняется
Во флеш
В UART
Разбор

Core dump (дамп при сбое) — набор данных о состоянии программы, который обработчик паники ESP-IDF автоматически сохраняет при фатальной ошибке: снимки всех задач с их блоками управления (TCB) и стеками, регистры упавшей задачи, причина паники. По дампу можно потом узнать, какая задача, на какой строке и с какой цепочкой вызовов привела к сбою — без подключённого терминала в момент аварии. Файл имеет формат ELF, тот же, что выдаёт компоновщик (см. «Файлы прошивки»), и его открывает GDB.

Куда и что сохраняется

Параметр	Значение по ESP-IDF	Опция
Назначение	флеш, UART или выключено	`CONFIG_ESP_COREDUMP_TO_FLASH_OR_UART`
Формат	ELF, расширяемый	—
Контроль целостности	SHA-256	—
Число задач	регистры и стек упавшей — всегда; остальные по приоритету до заданного числа	`CONFIG_ESP_COREDUMP_MAX_TASKS_NUM`
Секции данных	по желанию .bss, .data и куча; резервировать не меньше 128 КБ	`CONFIG_ESP_COREDUMP_CAPTURE_DRAM`
Стек для дампа	0 — стек ISR; иначе отдельный, рекомендуется больше 1300 байт (1300–1800 в Kconfig)	`CONFIG_ESP_COREDUMP_STACK_SIZE`

Данные во внешней PSRAM — переменные EXT_RAM_BSS_ATTR, EXT_RAM_NOINIT_ATTR, секция extram_bss — в дамп не попадают, а если стеки задач лежат в PSRAM, дамп во флеш недоступен. Конкретную переменную можно включить в дамп атрибутами COREDUMP_DRAM_ATTR, COREDUMP_RTC_ATTR или COREDUMP_RTC_FAST_ATTR (последние два — в RTC-памяти) и потом посмотреть в GDB командой p. Опции появляются в menuconfig только если компонент espcoredump включён в зависимости (REQUIRES или PRIV_REQUIRES).

Во флеш

Дамп пишется в раздел таблицы разделов типа data с подтипом coredump. В таблице по умолчанию он уже объявлен; в своей добавляют строку:

# Name,     Type, SubType,  Offset, Size
coredump,   data, coredump,       , 64K

Размер раздела — не меньше 20 байт плюс на каждую задачу 12 байт, её TCB и максимальный стек. При включённом шифровании флеш разделу ставят флаг encrypted; тогда прочитать его с хоста через idf.py coredump-info нельзя — дамп снимают с самого устройства, которое расшифрует раздел. Опция CONFIG_ESP_COREDUMP_FLASH_NO_OVERWRITE оставляет только первый дамп из серии, CONFIG_ESP_COREDUMP_CHECK_BOOT проверяет контрольную сумму дампа при каждой загрузке.

В UART

Дамп выводится в консоль в кодировке Base64 между строками CORE DUMP START и CORE DUMP END. Опция CONFIG_ESP_COREDUMP_DECODE выбирает: IDF Monitor декодирует его сам и показывает регистры, стек и список задач с переводом адресов в строки кода, либо оставляет закодированным. Во втором случае текст между маркерами (без самих маркеров) сохраняют в файл и разбирают на компьютере. CONFIG_ESP_COREDUMP_UART_DELAY добавляет задержку перед выводом.

Разбор

idf.py coredump-info — читает дамп из флеш и печатает регистры и стек упавшей задачи, список задач, области памяти и содержимое сохранённых TCB и стеков.
idf.py coredump-debug — сохраняет дамп как ELF и открывает сессию GDB: можно смотреть память, переменные и состояние задач; осмысленны только значения переменных на стеке, остальное в дамп не попало.
-c <файл> — разобрать дамп, сохранённый из UART, вместо чтения из флеш.

Обе команды — обёртки над инструментом esp-coredump (компонент на устройстве называется espcoredump); его можно вызывать и напрямую с собственными аргументами и ELF-файлом. Функции из ПЗУ в стеках вызовов GDB сам разобрать не может, поэтому IDF Monitor подгружает ROM ELF для нужного чипа и ревизии. Если к чипу подключён отладчик через OpenOCD, дамп не выполняется: обработчик паники передаёт управление отладчику.

Частые вопросы

Куда сохраняется core dump и сколько места нужно?

По выбору CONFIG_ESP_COREDUMP_TO_FLASH_OR_UART — в раздел флеш типа data с подтипом coredump или в UART в кодировке Base64. В таблице разделов ESP-IDF по умолчанию такой раздел уже есть; в своей его объявляют строкой вида «coredump, data, coredump,, 64K». Размер считают как 20 байт плюс на каждую задачу 12 байт, её TCB и максимальный стек; если включить захват DRAM (.bss, .data и куча), Kconfig советует резервировать не меньше 128 КБ.

Как прочитать core dump с ESP32?

Командой idf.py coredump-info — она читает дамп из флеш и печатает регистры и стек упавшей задачи, список задач, области памяти; idf.py coredump-debug сохраняет дамп как ELF и открывает сессию GDB, где можно смотреть переменные. Обе команды — обёртки над инструментом esp-coredump. Дамп из UART сначала сохраняют в файл без строк CORE DUMP START и END и передают через -c. Если раздел зашифрован, с хоста его не прочитать — дамп снимают с самого устройства.

Что попадает в core dump, а что нет?

Всегда — регистры и стек упавшей задачи, причина паники и снимки других задач (TCB и стек) в порядке приоритета, не больше CONFIG_ESP_COREDUMP_MAX_TASKS_NUM. По желанию — секции .bss и .data и куча (CONFIG_ESP_COREDUMP_CAPTURE_DRAM) и отдельные переменные с атрибутами COREDUMP_DRAM_ATTR, COREDUMP_RTC_ATTR, COREDUMP_RTC_FAST_ATTR. Не попадают данные во внешней PSRAM (EXT_RAM_BSS_ATTR, EXT_RAM_NOINIT_ATTR), а при стеках задач в PSRAM дамп во флеш вообще недоступен.

Источники

Espressif. ESP-IDF Programming Guide v6.1, ESP32: Core Dump — Overview: core dump — набор данных о состоянии ПО, который обработчик паники сохраняет при фатальной ошибке; снимки всех задач — TCB и стек; переменные с особыми атрибутами; Configurations: опции доступны, если компонент espcoredump включён в сборку (REQUIRES или PRIV_REQUIRES); CONFIG_ESP_COREDUMP_TO_FLASH_OR_UART — во флеш, в UART или выключено; Format & Size: формат ELF; CONFIG_ESP_COREDUMP_MAX_TASKS_NUM — число снимков задач, регистры и стек упавшей задачи сохраняются всегда, остальные по приоритету; Data Integrity Check: контрольная сумма SHA256; Reserved Stack Size: CONFIG_ESP_COREDUMP_STACK_SIZE, 0 — работа на стеке ISR, иначе отдельный стек, рекомендуется больше 1300 байт; Memory Regions: по умолчанию регистры, данные задач и причина паники, CONFIG_ESP_COREDUMP_CAPTURE_DRAM добавляет .bss, .data и кучу; данные во внешней RAM (EXT_RAM_BSS_ATTR, EXT_RAM_NOINIT_ATTR, extram_bss) в дамп не попадают; Core Dump to Flash: раздел типа data, подтип coredump, в таблице по умолчанию есть, в своей — объявить, пример coredump, data, coredump,, 64K; при шифровании флеш — флаг encrypted, тогда читать с хоста нельзя, только с устройства; накладные расходы 20 байт на файл и 12 байт на задачу плюс TCB и стек; idf.py coredump-info и idf.py coredump-debug — обёртки над esp-coredump; Core Dump to UART: Base64 между строками CORE DUMP START и CORE DUMP END, CONFIG_ESP_COREDUMP_DECODE — IDF Monitor декодирует сам или оставляет для ручного разбора, idf.py coredump-info -c файл; CONFIG_ESP_COREDUMP_UART_DELAY — задержка перед выводом; ROM Functions in Backtraces — ROM ELF подгружается монитором; Dumping Variables on Demand: COREDUMP_DRAM_ATTR, COREDUMP_RTC_ATTR, COREDUMP_RTC_FAST_ATTR, в GDB — p global_var
Espressif. ESP-IDF Programming Guide v6.1, ESP32: Fatal Errors; Configuration Options Reference — Fatal Errors: если включён Core Dump, обработчик паники сохраняет состояние системы (стеки и регистры задач) во флеш или UART; при подключённом JTAG-отладчике (CONFIG_ESP_DEBUG_OCDAWARE) core dump не выполняется; Kconfig: CONFIG_ESP_COREDUMP_CAPTURE_DRAM — зарезервировать не меньше 128 КБ; CONFIG_ESP_COREDUMP_STACK_SIZE — около 1300–1800 байт в зависимости от метода контрольной суммы, SHA256 требует больше, чем CRC32, расходует DRAM; CONFIG_ESP_COREDUMP_FLASH_NO_OVERWRITE — не затирать первый дамп; CONFIG_ESP_COREDUMP_CHECK_BOOT — проверять дамп во флеш при загрузке; CONFIG_ESP_COREDUMP_LOGS — строки логов занимают около 5 КБ DRAM; дамп во флеш недоступен, если стеки задач в PSRAM

Страница помогла?

Нашли ошибку? ·