Дамп памяти (Core Dump)

Введение

Модуль Core Dump позволяет загружать и анализировать снимки памяти вашего устройства в момент критического сбоя (crash). Когда происходит сбой, ESP32 автоматически фиксирует состояние системной памяти. Этот снимок, называемый дампом памяти (core dump), неоценим для отладки прошивки, так как он содержит информацию о том, что делал процессор, какие функции выполнялись и какие значения хранились в памяти в момент аварии.

Загружая и анализируя дампы памяти, вы можете определить первопричину сбоев и исправить ошибки, которые трудно воспроизвести в среде разработки.

Управление

Интерфейс Core Dump предоставляет один элемент управления:

Загрузить дамп памяти (coredump.bin) — эта кнопка загружает последний файл дампа памяти, сохраненный на устройстве. Файл сохраняется на ваш локальный компьютер под именем coredump.bin. Если с момента последнего получения или очистки дампа сбоев не происходило, загруженный файл может быть пустым или содержать данные о старом сбое.

Подробности

Понимание дампов памяти

Дамп памяти — это бинарный файл, который фиксирует точное состояние памяти вашего устройства в момент сбоя. Сюда входят:

Значения регистров процессора.
Трассировка стека (stack trace), показывающая последовательность вызовов, приведшую к сбою.
Содержимое памяти на момент отказа.
Информация о запущенных задачах и их состояниях.

Сопоставление дампов памяти с прошивкой

Каждый дамп памяти привязан к конкретной сборке вашей прошивки. Если вы измените код и пересоберете прошивку, старый дамп памяти не сможет быть расшифрован должным образом.

Декодирование дампа памяти

Для декодирования дампа памяти используется инструмент esp-coredump, предоставляемый Espressif. Базовая структура команды выглядит так:

esp-coredump info_corefile --core [COREDUMP_FILE] --gdb ~/.platformio/packages/tool-xtensa-esp-elf-gdb/bin/xtensa-esp32-elf-gdb --elf [ELF_FILE]

Для удобства анализа в реализован скрипт , который автоматически находит соответствующий elf файл

Инструкция по использованию скрипта analyze_dump.py

Скрипт analyze_dump.py предназначен для автоматизации анализа дампов памяти (core dump) ESP32-S3. Он автоматически настраивает окружение ESP-IDF, ищет подходящий GDB-отладчик и сопоставляет ELF-файл прошивки с дампом по SHA256 хэшу.

1. Подготовка

Перед запуском убедитесь, что:

У вас установлен Python 3.
Установлен ESP-IDF (скрипт по умолчанию ищет профиль по пути C:\Espressif\tools\Microsoft.v5.5.2.PowerShell_profile.ps1).
- Инструкция по установке - https://docs.espressif.com/projects/idf-im-ui/en/latest/
- Рекомендуется использовать графически установщик EIM
```
# Install the GUI application (recommended for most users)
winget install Espressif.EIM
```
У вас есть файл дампа (например, coredump.bin), полученный с устройства.

2. Основные команды запуска

Автоматический режим

Если проект собран в текущей папке или в папке build, скрипт сам найдет нужный ELF-файл:

python analyze_dump.py coredump.bin

Указание ELF-файла вручную

Если автоматический поиск не нашел нужный файл или нашел не тот:

python analyze_dump.py coredump.bin

Указание пути к GDB

Если скрипт не может найти отладчик:

python analyze_dump.py --gdb "C:\Espressif\tools\xtensa-esp32s3-elf\...\xtensa-esp32s3-elf-gdb.exe" coredump.bin

Дополнительные параметры

--elf-dir: Добавить директории для поиска ELF-файлов.
--ps-profile: Указать путь к кастомному профилю PowerShell для инициализации ESP-IDF.
--skip-esp-setup: Пропустить инициализацию окружения (если переменные уже настроены в системе).

3. Анализ полученных данных

После запуска скрипт выведет в консоль отчет от GDB. Вот на что нужно обратить внимание в первую очередь:

А. Backtrace (Стек вызовов)

Это самый важный блок. Он показывает последовательность функций, которая привела к панике.

Ищите строки вида #0 0x40... in function_name at file_name.cpp:line_number.

#0 — это точка, где произошел сбой. Если это системная функция (например, vPortYield), смотрите #1 или #2, чтобы найти ваш код.

Б. Причина исключения (Exception Cause)

В начале вывода GDB обычно указывает причину остановки:

LoadStoreAlignmentCause: Попытка чтения/записи по невыровненному адресу.

InstrFetchProhibited / LoadProhibited: Обращение к нулевому указателю (NULL pointer) или поврежденному адресу памяти.

Guru Meditation Error: Core 0 panic'ed (Interrupt wdt timeout): Сработал сторожевой таймер (зацикливание кода или слишком долгая операция в прерывании).

В. Состояние регистров

Регистры (A0-A15) полезны, если стек поврежден:

PC (Program Counter): Адрес текущей инструкции.

EXCVADDR: Адрес памяти, к которому пыталась обратиться программа (если там 0x00000000 — это точно NULL pointer).

Г. Локальные переменные

Если ELF-файл был собран с отладочными символами (стандарт для build), GDB может показать значения переменных в момент падения:

Проверьте аргументы функций в стеке (Backtrace) на наличие аномальных значений.

4. Типовой алгоритм решения проблемы

Найдите в Backtrace последнюю функцию из вашего кода (обычно это верхний уровень, не считая системных библиотек).

Перейдите к указанному файлу и строке кода.

Проверьте все указатели в этой строке на nullptr.

Если ошибка — StoreProhibited, проверьте, не пытаетесь ли вы писать в массив за его пределы.

Если это Interrupt wdt timeout, убедитесь, что в циклах while есть vTaskDelay или другие способы передачи управления планировщику.