I need to use the core dump functionality of the ESP32 to debug a random and infrequent crash happening on a device. To do that I set up the configuration to save the core dump into the internal flash (default partition).
I created a very simple example to properly understand the procedure, but it appears the information saved by the dump are practically non-existent.
I have a single source file, main.c:
Code: Select all
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "esp_log.h"
#include "driver/gpio.h"
#define TAG "Main"
void app_main(void)
{
gpio_set_direction(GPIO_NUM_15, GPIO_MODE_OUTPUT);
int level = 0;
while (true)
{
gpio_set_level(GPIO_NUM_15, level);
level = !level;
vTaskDelay(1000 / portTICK_PERIOD_MS);
ESP_LOGI(TAG, "Alive");
void (*fun)() = NULL;
fun();
}
}
Code: Select all
--- idf_monitor on /dev/ttyUSB0 115200 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
_i�I (12) boot: ESP-IDF v3.2-dirty 2nd stage bootloader
I (12) boot: compile time 13:19:11
I (12) boot: Enabling RNG early entropy source...
I (15) boot: SPI Speed : 40MHz
I (20) boot: SPI Mode : DIO
I (24) boot: SPI Flash Size : 16MB
I (28) boot: Partition Table:
I (31) boot: ## Label Usage Type ST Offset Length
I (39) boot: 0 nvs WiFi data 01 02 00009000 00006000
I (46) boot: 1 phy_init RF data 01 01 0000f000 00001000
I (54) boot: 2 factory factory app 00 00 00010000 00100000
I (61) boot: 3 coredump Unknown data 01 03 00110000 00010000
I (69) boot: End of partition table
I (73) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x05ad0 ( 23248) map
I (90) esp_image: segment 1: paddr=0x00015af8 vaddr=0x3ffb0000 size=0x01ba0 ( 7072) load
I (93) esp_image: segment 2: paddr=0x000176a0 vaddr=0x40080000 size=0x00400 ( 1024) load
0x40080000: _WindowOverflow4 at /home/maldus/Source/esp-idf/components/freertos/xtensa_vectors.S:1779
I (100) esp_image: segment 3: paddr=0x00017aa8 vaddr=0x40080400 size=0x08568 ( 34152) load
I (122) esp_image: segment 4: paddr=0x00020018 vaddr=0x400d0018 size=0x121f8 ( 74232) map
0x400d0018: _flash_cache_start at ??:?
I (149) esp_image: segment 5: paddr=0x00032218 vaddr=0x40088968 size=0x00908 ( 2312) load
0x40088968: xthal_set_ccompare at /Users/igrokhotkov/e/esp32/hal/hal/clock.S:96
I (155) boot: Loaded app from partition at offset 0x10000
I (156) boot: Disabling RNG early entropy source...
I (158) cpu_start: Pro cpu up.
I (162) cpu_start: Single core mode
I (166) heap_init: Initializing. RAM available for dynamic allocation:
I (173) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (179) heap_init: At 3FFB2B40 len 0002D4C0 (181 KiB): DRAM
I (185) heap_init: At 3FFE0440 len 0001FBC0 (126 KiB): D/IRAM
I (192) heap_init: At 40078000 len 00008000 (32 KiB): IRAM
I (198) heap_init: At 40089270 len 00016D90 (91 KiB): IRAM
I (204) cpu_start: Pro cpu start user code
I (222) esp_core_dump: Init core dump to flash
I (222) esp_core_dump: Found partition 'coredump' @ 110000 65536 bytes
I (224) cpu_start: Starting scheduler on PRO CPU.
I (2229) Main: Alive
Guru Meditation Error: Core 0 panic'ed (InstrFetchProhibited). Exception was unhandled.
Core 0 register dump:
PC : 0x00000000 PS : 0x00060030 A0 : 0x800d08a3 A1 : 0x3ffb3ec0
A2 : 0x00000001 A3 : 0x00000000 A4 : 0x00000000 A5 : 0x3ffb50e0
A6 : 0x3ffb0828 A7 : 0x00060023 A8 : 0x800d1ea4 A9 : 0x3ffb3e70
A10 : 0x400db874 A11 : 0x3ffb274c A12 : 0x3f40367c A13 : 0x00000008
0x400db874: vprintf at /Users/ivan/e/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdio/../../../.././newlib/libc/stdio/vprintf.c:35
A14 : 0x00000002 A15 : 0x00000005 SAR : 0x00000004 EXCCAUSE: 0x00000014
EXCVADDR: 0x00000000 LBEG : 0x400014fd LEND : 0x4000150d LCOUNT : 0xfffffffe
Backtrace: 0x00000000:0x3ffb3ec0 0x400d08a0:0x3ffb3ee0 0x4008451d:0x3ffb3f00
0x400d08a0: main_task at /home/maldus/Source/esp-idf/components/esp32/cpu_start.c:494
0x4008451d: vPortTaskWrapper at /home/maldus/Source/esp-idf/components/freertos/port.c:403
I (1285) esp_core_dump: Save core dump to flash...
I (1340) esp_core_dump: Core dump has been saved to flash.
CPU halted.
Code: Select all
$ python2 $IDF_PATH/components/espcoredump/espcoredump.py -p /dev/ttyUSB0 info_corefile build/app-template.elf --print-mem
espcoredump.py v0.2-dev
esptool.py v2.6
Serial port /dev/ttyUSB0
Connecting.....
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
MAC: cc:50:e3:82:df:58
Uploading stub...
Running stub...
Stub running...
16 (100 %)
16 (100 %)
Read 16 bytes at 0x110000 in 0.0 seconds (4.0 kbit/s)...
Hard resetting via RTS pin...
esptool.py v2.6
Serial port /dev/ttyUSB0
Connecting....
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
MAC: cc:50:e3:82:df:58
Uploading stub...
Running stub...
Stub running...
3948 (100 %)
3948 (100 %)
Read 3948 bytes at 0x110000 in 0.4 seconds (82.8 kbit/s)...
Hard resetting via RTS pin...
===============================================================
==================== ESP32 CORE DUMP START ====================
================== CURRENT THREAD REGISTERS ===================
Reading symbols from build/app-template.elf...done.
[New <main task>]
[New process 1]
[New process 2]
[New process 3]
[New process 4]
[Current thread is 1 (<main task>)]
GDB exited (None / None)!
Problem occured! GDB exited, restart it.
==================== CURRENT THREAD STACK =====================
Reading symbols from build/app-template.elf...done.
[New <main task>]
[New process 1]
[New process 2]
[New process 3]
[New process 4]
[Current thread is 1 (<main task>)]
GDB exited (None / None)!
I feel like I'm misunderstanding something, can someone help me clarify?Core dump contains snapshots of all tasks in the system at the moment of failure. Snapshots include tasks control blocks (TCB) and stacks. So it is possible to find out what task, at what instruction (line of code) and what callstack of that task lead to the crash.