Locating Problems Using Backtrace & Coredump
Backtrace Overview
By default, when a Panic occurs, unless CONFIG_ESP_SYSTEM_PANIC_SILENT_REBOOT is enabled, the panic handler will print CPU registers and backtrace to the console for developers to further debug and analyze. This is further described in the ESP-IDF Programming Guide in the section on Register Dump and Backtrace.
Backtrace information varies for different CPU architectures. Currently, ESP primarily uses the Xtensa architecture, exemplified by ESP32-S3, and the RISC-V architecture, exemplified by ESP32-C3:
For Xtensa, the focus is on PC and EXCVADDR, as well as the Backtrace address.
For RISC-V, the focus is on MEPC and MTVAL, as well as stack information (Backtrace address is not printed by default).
Register information and Backtrace addresses can be printed and manually parsed using third-party serial tools and addr2line or automatically through idf.py monitor. We will elaborate on how to use Backtrace & Coredump to locate issues for these two CPU architectures.
xTensa Backtrace
ESP currently uses the xTensa architecture for chips such as ESP8266, ESP32, ESP32-S2, and ESP32-S3.
Here is an example of error logs corresponding to xTensa:
Guru Meditation Error: Core 0 panic'ed (LoadProhibited). Exception was unhandled.
Core 0 register dump:
PC : 0x42016d2f PS : 0x00060c30 A0 : 0x820088ac A1 : 0x3fc98d00
A2 : 0x00000000 A3 : 0x3fc98f34 A4 : 0x0000000a A5 : 0x3fc98d20
A6 : 0x3fc98d00 A7 : 0x0000000c A8 : 0x8200ca00 A9 : 0x3fc989b0
A10 : 0x00000002 A11 : 0xffffffff A12 : 0x00000002 A13 : 0x3fc98bc0
A14 : 0x3fc989c0 A15 : 0x00000001 SAR : 0x00000019 EXCCAUSE: 0x0000001c
EXCVADDR: 0x00000008 LBEG : 0x400556d5 LEND : 0x400556e5 LCOUNT : 0xfffffff9
Backtrace: 0x42016d2c:0x3fc98d00 0x420088a9:0x3fc98d20 0x420180ff:0x3fc98d40 0x4037a2dd:0x3fc98d70
You can further use the addr2line command to parse the Backtrace into readable function names based on the .elf file. An example command is as follows:
xtensa-esp32s3-elf-addr2line -pfiaC -e path.elf 0x42016d2c:0x3fc98d00
The corresponding result is:
❯ xtensa-esp32s3-elf-addr2line -pfiaC -e ./build/idf_debug_method.elf 0x42016d2c:0x3fc98d00 0x420088a9:0x3fc98d20 0x420180ff:0x3fc98d40 0x4037a2dd:0x3fc98d70
0x42016d2c: new_monkey_born at /home/libo/test_github/idf_debug_method/main/idf_debug_method.c:18
0x420088a9: app_main at /home/libo/test_github/idf_debug_method/main/idf_debug_method.c:70
0x420180ff: main_task at /home/libo/esp/github_master/components/freertos/app_startup.c:208 (discriminator 13)
0x4037a2dd: vPortTaskWrapper at /home/libo/esp/github_master/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:162
If you use IDF monitor to print logs, it will automatically call the above addr2line and print the parsed results, as shown below:
Guru Meditation Error: Core 0 panic'ed (LoadProhibited). Exception was unhandled.
Core 0 register dump:
PC : 0x42016d2f PS : 0x00060c30 A0 : 0x820088ac A1 : 0x3fc98d00
0x42016d2f: new_monkey_born at /home/libo/test_github/idf_debug_method/main/idf_debug_method.c:19
A2 : 0x00000000 A3 : 0x3fc98f34 A4 : 0x0000000a A5 : 0x3fc98d20
A6 : 0x3fc98d00 A7 : 0x0000000c A8 : 0x8200ca00 A9 : 0x3fc989b0
A10 : 0x00000002 A11 : 0xffffffff A12 : 0x00000002 A13 : 0x3fc98bc0
A14 : 0x3fc989c0 A15 : 0x00000001 SAR : 0x00000019 EXCCAUSE: 0x0000001c
EXCVADDR: 0x00000008 LBEG : 0x400556d5 LEND : 0x400556e5 LCOUNT : 0xfffffff9
0x400556d5: strlen in ROM
0x400556e5: strlen in ROM
Backtrace: 0x42016d2c:0x3fc98d00 0x420088a9:0x3fc98d20 0x420180ff:0x3fc98d40 0x4037a2dd:0x3fc98d70
0x42016d2c: new_monkey_born at /home/libo/test_github/idf_debug_method/main/idf_debug_method.c:18
0x420088a9: app_main at /home/libo/test_github/idf_debug_method/main/idf_debug_method.c:70
0x420180ff: main_task at /home/libo/esp/github_master/components/freertos/app_startup.c:208 (discriminator 13)
0x4037a2dd: vPortTaskWrapper at /home/libo/esp/github_master/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:162
Now, based on the detailed backtrace log, Guru Meditation Error, and the pointers:
PC: Program Counter
EXCVADDR: Exception Vector Address
you can further debug and analyze the common causes of Guru Meditation errors, as explained in the section on Locating Problems Using Guru Meditation Error Printing in the documentation.
RISC-V Backtrace
Currently, ESP uses RISC-V architecture for chips such as ESP32-C3, ESP32-C2, ESP32-C6, and ESP32-H2.
Here is an example of error logs corresponding to RISC-V:
Guru Meditation Error: Core 0 panic'ed (Load access fault). Exception was unhandled.
Core 0 register dump:
MEPC : 0x42007988 RA : 0x42007a4e SP : 0x3fc8fed0 GP : 0x3fc8b200
TP : 0x3fc870f8 T0 : 0x4005890e T1 : 0x3fc8fb2c T2 : 0x00000000
S0/FP : 0x0000000a S1 : 0x3fc90948 A0 : 0x00000000 A1 : 0x3fc8fb08
A2 : 0x00000000 A3 : 0x00000001 A4 : 0x00000000 A5 : 0x00000009
A6 : 0x60023000 A7 : 0x0000000a S2 : 0x00000000 S3 : 0x00000000
S4 : 0x00000000 S5 : 0x00000000 S6 : 0x00000000 S7 : 0x00000000
S8 : 0x00000000 S9 : 0x00000000 S10 : 0x00000000 S11 : 0x00000000
T3 : 0x00000000 T4 : 0x00000000 T5 : 0x00000000 T6 : 0x00000000
MSTATUS : 0x00001881 MTVEC : 0x40380001 MCAUSE : 0x00000005 MTVAL : 0x00000008
MHARTID : 0x00000000
Stack memory:
3fc8fed0: 0x3c021bd0 0x00000000 0x3c022000 0x42015de4 0x00000000 0x00001388 0x00000001 0x00000000
3fc8fef0: 0x00000000 0x00000000 0x00000000 0x40384538 0x00000000 0x00000000 0x00000000 0x00000000
You can further use the addr2line command to parse the Backtrace into readable function names based on the .elf file. An example command is as follows:
riscv32-esp-elf-addr2line -pfiaC -e path.elf 0x42007988 0x42007a4e
The corresponding result is:
❯ riscv32-esp-elf-addr2line -pfiaC -e ./build/idf_debug_method.elf 0x42007988 0x42007a4e
0x42007988: new_monkey_born at /home/libo/test_github/idf_debug_method/main/idf_debug_method.c:19
0x42007a4e: app_main at /home/libo/test_github/idf_debug_method/main/idf_debug_method.c:71
If you use IDF monitor to print logs, it will automatically call the above addr2line and print the parsed results, as shown below:
Guru Meditation Error: Core 0 panic'ed (Load access fault). Exception was unhandled.
Stack dump detected
Core 0 register dump:
MEPC : 0x42007988 RA : 0x42007a4e SP : 0x3fc8fed0 GP : 0x3fc8b200
0x42007988: new_monkey_born at /home/libo/test_github/idf_debug_method/main/idf_debug_method.c:19
0x42007a4e: app_main at /home/libo/test_github/idf_debug_method/main/idf_debug_method.c:71
TP : 0x3fc870f8 T0 : 0x4005890e T1 : 0x3fc8fb2c T2 : 0x00000000
0x4005890e: memset in ROM
S0/FP : 0x0000000a S1 : 0x3fc90948 A0 : 0x00000000 A1 : 0x3fc8fb08
A2 : 0x00000000 A3 : 0x00000001 A4 : 0x00000000 A5 : 0x00000009
A6 : 0x60023000 A7 : 0x0000000a S2 : 0x00000000 S3 : 0x00000000
S4 : 0x00000000 S5 : 0x00000000 S6 : 0x00000000 S7 : 0x00000000
S8 : 0x00000000 S9 : 0x00000000 S10 : 0x00000000 S11 : 0x00000000
T3 : 0x00000000 T4 : 0x00000000 T5 : 0x00000000 T6 : 0x00000000
MSTATUS : 0x00001881 MTVEC : 0x40380001 MCAUSE : 0x00000005 MTVAL : 0x00000008
0x40380001: _vector_table at ??:?
MHARTID : 0x00000000
Backtrace:
new_monkey_born (zoo=zoo@entry=0x0) at /home/libo/test_github/idf_debug_method/main/idf_debug_method.c:19
19 zoo->monkey++;
#0 new_monkey_born (zoo=zoo@entry=0x0) at /home/libo/test_github/idf_debug_method/main/idf_debug_method.c:19
#1 0x42007a4e in app_main () at /home/libo/test_github/idf_debug_method/main/idf_debug_method.c:70
#2 0x42015de4 in main_task (args=<error reading variable: value has been optimized out>) at /home/libo/esp/github_master/components/freertos/app_startup.c:208
#3 0x40384538 in vPortTaskWrapper (pxCode=<optimized out>, pvParameters=<optimized out>) at /home/libo/esp/github_master/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:234
Now, you can further debug and analyze the common causes of Guru Meditation errors using the detailed backtrace log, Guru Meditation Error, and the pointers:
MEPC: Machine Exception Program Counter
MTVAL: Machine Trap Value
Further debugging and analysis can be conducted based on pointers, Guru Meditation errors, and common causes of Guru Meditation errors, as explained in the section on Locating Problems Using Guru Meditation Error Printing.
Common Backtrace Errors
Common Backtrace errors are summarized in the table below. Detailed information is also provided in the section on Locating Problems Using Guru Meditation Error Printing.
Xtensa |
RISC-V |
Why |
Where |
|---|---|---|---|
IllegalInstruction |
IllegalInstruction |
SPI Flash IO Broken / task return without vTaskDelete / non-void function return void |
Hardware or Software |
Instruction Address Misaligned |
not 2-byte aligned |
PC(0x4_), MEPC(0x3_-0x6_) |
|
InstrFetchProhibited |
Instruction Access Fault |
not in IRAM/RAM range |
PC(0x4_), MEPC(0x3_-0x6_) |
Memory Protection Fault |
write to IRAM or execute from DRAM |
MEPC(0x3_-0x6_) |
|
LoadProhibited |
Load Access Fault |
Read from NULL/invalid pointer |
EXCVADDR, MTVAL |
StoreProhibited |
Store Access Fault |
Save to NULL/invalid pointer |
EXCVADDR, MTVAL |
LoadStoreAlignment |
Load/Store Address Misaligned |
IRAM use as DRAM, but not 4-byte aligned |
EXCVADDR, MTVAL |
IntegerDivideByZero |
calculate n/0 |
PC(0x4_), MEPC(0x3_-0x6_) |
|
LoadStoreError |
write to read-only IROM DROM |
EXCVADDR, MTVAL |
|
Interrupt Watchdog Timeout on CPU0/CPU1 |
Interrupt Watchdog Timeout on CPU0/CPU1 |
Interrupt timeout/ disabled |
|
Cache disabled but cached memory region accessed |
Cache error |
set FLAG_IRAM but not all data/functions in IRAM/DRAM |
PC(0x4_), MEPC(0x3_-0x6_) |
Brownout |
Brownout |
Supply voltage lower than threshold |
Hardware |
rst:0x10 (RTCWDT_RTC_RESET) |
rst:0x10 (RTCWDT_RTC_RESET) |
no valid program in flash |
Hardware |
rst:0x7 (TG0WDT_SYS_RST) |
rst:0x7 (TG0WDT_SYS_RST) |
Watchdog timeout |
Flash or PSRAM Pin / software |
Corrupt Heap |
Corrupt Heap |
Heap corruption detected |
Need further analysis |
Stack protection fault |
Stack overflow |
Need further analysis |
|
Stack smashing protect failure |
Stack smashing protect failure |
Stack overflow |
Need further analysis |
Core 0 panic’ed Exception was unhandled |
Stack canary watchpoint triggered (task_name) |
Stack overflow |
Need further analysis |
UBSAN |
UBSAN |
Undefined behavior |
Need further analysis |
Core Dump Overview
This section can be referred to in the Core Dump documentation. A brief summary is provided below:
Core Dump is more comprehensive than backtrace, including stack dumps for each task.
Core Dump can be printed to the terminal or saved to flash (type: data, subtype: coredump).
After saving Core Dump to flash, it can be analyzed directly using the idf.py coredump-info command.
The Core Dump serial data is in BASE64 format as a binary string. Copy and save it as text, then use the idf.py coredump-info -c </path/to/saved/base64/text> command for analysis.
esp monitor can parse Core Dump information and display it in a readable format.
idf.py coredump-debug can “restore the scene,” and GDB debugging will be opened to view variable values.
Xtensa Core Dump typically looks like the following:
Initiating core dump!
I (423) esp_core_dump_uart: Press Enter to print core dump to UART...
I (431) esp_core_dump_uart: Print core dump to uart...
Core dump started (further output muted)
Received 13 kB...
Core dump finished!
===============================================================
==================== ESP32 CORE DUMP START ====================
The ROM ELF file won't load automatically since it was not found for the provided chip type.
Crashed task handle: 0x3fc9a790, name: 'main', GDB name: 'process 1070180240'
================== CURRENT THREAD REGISTERS ===================
exccause 0x1c (LoadProhibitedCause)
excvaddr 0x8
epc1 0x40378347
epc2 0x0
epc3 0x0
epc4 0x0
epc5 0x0
epc6 0x0
eps2 0x0
eps3 0x0
eps4 0x0
eps5 0x0
eps6 0x0
pc 0x42018677 0x42018677 <new_monkey_born+7>
lbeg 0x400556d5 1074091733
lend 0x400556e5 1074091749
lcount 0xfffffffc 4294967292
sar 0x1a 26
ps 0x60c20 396320
threadptr <unavailable>
br <unavailable>
scompare1 <unavailable>
acclo <unavailable>
acchi <unavailable>
m0 <unavailable>
m1 <unavailable>
m2 <unavailable>
m3 <unavailable>
expstate <unavailable>
f64r_lo <unavailable>
f64r_hi <unavailable>
f64s <unavailable>
fcr <unavailable>
fsr <unavailable>
a0 0x8200a136 -2113887946
a1 0x3fc9a5a0 1070179744
a2 0x0 0
a3 0x3fc9a7ec 1070180332
a4 0x3c023088 1006776456
a5 0x3fc9a5d0 1070179792
a6 0x3fc9a5b0 1070179760
a7 0xc 12
a8 0x8200e2b8 -2113871176
a9 0x3fc9a250 1070178896
a10 0x10 16
a11 0xffffffff -1
a12 0x10 16
a13 0x3fc9a460 1070179424
a14 0x3fc9a260 1070178912
a15 0x1 1
==================== CURRENT THREAD STACK =====================
#0 new_monkey_born (zoo=0x0) at /home/libo/test_github/idf_debug_method/main/idf_debug_method.c:21
#1 0x4200a136 in app_main () at /home/libo/test_github/idf_debug_method/main/idf_debug_method.c:57
#2 0x42019ade in main_task (args=<optimized out>) at /home/libo/esp/github_master/components/freertos/app_startup.c:208
#3 0x4037a2ec in vPortTaskWrapper (pxCode=0x42019a38 <main_task>, pvParameters=0x0) at /home/libo/esp/github_master/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:162
======================== THREADS INFO =========================
Id Target Id Frame
* 1 process 1070180240 new_monkey_born (zoo=0x0) at /home/libo/test_github/idf_debug_method/main/idf_debug_method.c:21
2 process 1070182124 vPortTaskWrapper (pxCode=0x0, pvParameters=0x0) at /home/libo/esp/github_master/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:161
3 process 1070184008 0x40378326 in esp_cpu_wait_for_intr () at /home/libo/esp/github_master/components/esp_hw_support/cpu.c:145
4 process 1070169660 0x400559e0 in ?? ()
5 process 1070175732 0x400559e0 in ?? ()
6 process 1070171288 0x400559e0 in ?? ()
==================== THREAD 1 (TCB: 0x3fc9a790, name: 'main') =====================
#0 new_monkey_born (zoo=0x0) at /home/libo/test_github/idf_debug_method/main/idf_debug_method.c:21
#1 0x4200a136 in app_main () at /home/libo/test_github/idf_debug_method/main/idf_debug_method.c:57
#2 0x42019ade in main_task (args=<optimized out>) at /home/libo/esp/github_master/components/freertos/app_startup.c:208
#3 0x4037a2ec in vPortTaskWrapper (pxCode=0x42019a38 <main_task>, pvParameters=0x0) at /home/libo/esp/github_master/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:162
==================== THREAD 2 (TCB: 0x3fc9aeec, name: 'IDLE0') =====================
#0 vPortTaskWrapper (pxCode=0x0, pvParameters=0x0) at /home/libo/esp/github_master/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:161
#1 0x40000000 in ?? ()
==================== THREAD 3 (TCB: 0x3fc9b648, name: 'IDLE1') =====================
#0 0x40378326 in esp_cpu_wait_for_intr () at /home/libo/esp/github_master/components/esp_hw_support/cpu.c:145
#1 0x42002be5 in esp_vApplicationIdleHook () at /home/libo/esp/github_master/components/esp_system/freertos_hooks.c:59
#2 0x4037b038 in prvIdleTask (pvParameters=0x0) at /home/libo/esp/github_master/components/freertos/FreeRTOS-Kernel/tasks.c:4170
#3 0x4037a2ec in vPortTaskWrapper (pxCode=0x4037b02c <prvIdleTask>, pvParameters=0x0) at /home/libo/esp/github_master/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:162
==================== THREAD 4 (TCB: 0x3fc97e3c, name: 'ipc0') =====================
#0 0x400559e0 in ?? ()
#1 0x4037a692 in vPortClearInterruptMaskFromISR (prev_level=<optimized out>) at /home/libo/esp/github_master/components/freertos/FreeRTOS-Kernel/portable/xtensa/include/freertos/portmacro.h:582
#2 vPortExitCritical (mux=<optimized out>) at /home/libo/esp/github_master/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:532
#3 0x4037c0c5 in xTaskGenericNotifyWait (uxIndexToWait=0, ulBitsToClearOnEntry=<optimized out>, ulBitsToClearOnExit=4294967295, pulNotificationValue=0x3fc97ca0, xTicksToWait=4294967295) at /home/libo/esp/github_master/components/freertos/FreeRTOS-Kernel/tasks.c:5644
#4 0x40378104 in ipc_task (arg=0x0) at /home/libo/esp/github_master/components/esp_system/esp_ipc.c:58
#5 0x4037a2ec in vPortTaskWrapper (pxCode=0x403780d4 <ipc_task>, pvParameters=0x0) at /home/libo/esp/github_master/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:162
==================== THREAD 5 (TCB: 0x3fc995f4, name: 'esp_timer') =====================
#0 0x400559e0 in ?? ()
#1 0x4037a692 in vPortClearInterruptMaskFromISR (prev_level=<optimized out>) at /home/libo/esp/github_master/components/freertos/FreeRTOS-Kernel/portable/xtensa/include/freertos/portmacro.h:582
#2 vPortExitCritical (mux=<optimized out>) at /home/libo/esp/github_master/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:532
#3 0x4037bf89 in ulTaskGenericNotifyTake (uxIndexToWait=0, xClearCountOnExit=1, xTicksToWait=<optimized out>) at /home/libo/esp/github_master/components/freertos/FreeRTOS-Kernel/tasks.c:5565
#4 0x42006143 in timer_task (arg=0x0) at /home/libo/esp/github_master/components/esp_timer/src/esp_timer.c:477
#5 0x4037a2ec in vPortTaskWrapper (pxCode=0x42006134 <timer_task>, pvParameters=0x0) at /home/libo/esp/github_master/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:162
==================== THREAD 6 (TCB: 0x3fc98498, name: 'ipc1') =====================
#0 0x400559e0 in ?? ()
#1 0x4037a692 in vPortClearInterruptMaskFromISR (prev_level=<optimized out>) at /home/libo/esp/github_master/components/freertos/FreeRTOS-Kernel/portable/xtensa/include/freertos/portmacro.h:582
#2 vPortExitCritical (mux=<optimized out>) at /home/libo/esp/github_master/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:532
#3 0x4037c0c5 in xTaskGenericNotifyWait (uxIndexToWait=0, ulBitsToClearOnEntry=<optimized out>, ulBitsToClearOnExit=4294967295, pulNotificationValue=0x3fc98300, xTicksToWait=4294967295) at /home/libo/esp/github_master/components/freertos/FreeRTOS-Kernel/tasks.c:5644
#4 0x40378104 in ipc_task (arg=0x1) at /home/libo/esp/github_master/components/esp_system/esp_ipc.c:58
#5 0x4037a2ec in vPortTaskWrapper (pxCode=0x403780d4 <ipc_task>, pvParameters=0x1) at /home/libo/esp/github_master/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:162
======================= ALL MEMORY REGIONS ========================
Name Address Size Attrs
.rtc.force_fast 0x600fe010 0x0 RW
.rtc_noinit 0x50000000 0x0 RW
.rtc.force_slow 0x50000000 0x0 RW
.iram0.vectors 0x40374000 0x403 R XA
.iram0.text 0x40374404 0xd56f R XA
.dram0.data 0x3fc91a00 0x3e84 RW A
.flash.text 0x42000020 0x1a41b R XA
.flash.appdesc 0x3c020020 0x100 R A
.flash.rodata 0x3c020120 0xae5c RW A
.flash.rodata_noload 0x3c02af7c 0x0 RW
.ext_ram.bss 0x3c030000 0x0 RW
.iram0.data 0x40381a00 0x0 RW
.iram0.bss 0x40381a00 0x0 RW
.dram0.heap_start 0x3fc96a28 0x0 RW
.coredump.tasks.data 0x3fc9a790 0x154 RW
.coredump.tasks.data 0x3fc9a4e0 0x2a0 RW
.coredump.tasks.data 0x3fc9aeec 0x154 RW
.coredump.tasks.data 0x3fc9ace0 0x200 RW
.coredump.tasks.data 0x3fc9b648 0x154 RW
.coredump.tasks.data 0x3fc9b3c0 0x280 RW
.coredump.tasks.data 0x3fc97e3c 0x154 RW
.coredump.tasks.data 0x3fc97b90 0x2a0 RW
.coredump.tasks.data 0x3fc995f4 0x154 RW
.coredump.tasks.data 0x3fc99350 0x290 RW
.coredump.tasks.data 0x3fc98498 0x154 RW
.coredump.tasks.data 0x3fc981f0 0x2a0 RW
===================== ESP32 CORE DUMP END =====================
===============================================================
Done!
Coredump checksum='7b5945fe'
I (1690) esp_core_dump_uart: Core dump has been written to uart.
Xtensa Core Dump typically looks like the following:
Initiating core dump!
I (696) esp_core_dump_uart: Press Enter to print core dump to UART...
I (703) esp_core_dump_uart: Print core dump to uart...
Core dump started (further output muted)
Received 3 kB...
Core dump finished!
===============================================================
==================== ESP32 CORE DUMP START ====================
Crashed task handle: 0x3fc91594, name: 'main', GDB name: 'process 1070142868'
================== CURRENT THREAD REGISTERS ===================
ra 0x42009404 0x42009404 <app_main+56>
sp 0x3fc91510 0x3fc91510
gp 0x3fc8b400 0x3fc8b400 <__c.29+52>
tp 0x3fc88368 0x3fc88368
t0 0x4005890e 1074104590
t1 0x3fc9116c 1070141804
t2 0x0 0
fp 0x3c022000 0x3c022000
s1 0x3fc91f98 1070145432
a0 0x0 0
a1 0x3fc91148 1070141768
a2 0x0 0
a3 0x1 1
a4 0x0 0
a5 0x0 0
a6 0x60023000 1610756096
a7 0xa 10
s2 0x0 0
s3 0x0 0
s4 0x0 0
s5 0x0 0
s6 0x0 0
s7 0x0 0
s8 0x0 0
s9 0x0 0
s10 0x0 0
s11 0x0 0
t3 0x0 0
t4 0x0 0
t5 0x0 0
t6 0x0 0
pc 0x4200939e 0x4200939e <new_monkey_born+4>
==================== CURRENT THREAD STACK =====================
#0 new_monkey_born (zoo=zoo@entry=0x0) at /home/libo/test_github/idf_debug_method/main/idf_debug_method.c:21
#1 0x42009404 in app_main () at /home/libo/test_github/idf_debug_method/main/idf_debug_method.c:55
#2 0x42017976 in main_task (args=<error reading variable: value has been optimized out>) at /home/libo/esp/github_master/components/freertos/app_startup.c:208
#3 0x403845bc in vPortTaskWrapper (pxCode=<optimized out>, pvParameters=<optimized out>) at /home/libo/esp/github_master/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:234
======================== THREADS INFO =========================
Id Target Id Frame
* 1 process 1070142868 new_monkey_born (zoo=zoo@entry=0x0) at /home/libo/test_github/idf_debug_method/main/idf_debug_method.c:21
2 process 1070144752 vPortTaskWrapper (pxCode=0x40384f20 <prvIdleTask>, pvParameters=0x0) at /home/libo/esp/github_master/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:230
3 process 1070138360 0x40384796 in vPortClearInterruptMaskFromISR (prev_int_level=1) at /home/libo/esp/github_master/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:417
==================== THREAD 1 (TCB: 0x3fc91594, name: 'main') =====================
#0 new_monkey_born (zoo=zoo@entry=0x0) at /home/libo/test_github/idf_debug_method/main/idf_debug_method.c:21
#1 0x42009404 in app_main () at /home/libo/test_github/idf_debug_method/main/idf_debug_method.c:55
#2 0x42017976 in main_task (args=<error reading variable: value has been optimized out>) at /home/libo/esp/github_master/components/freertos/app_startup.c:208
#3 0x403845bc in vPortTaskWrapper (pxCode=<optimized out>, pvParameters=<optimized out>) at /home/libo/esp/github_master/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:234
==================== THREAD 2 (TCB: 0x3fc91cf0, name: 'IDLE') =====================
#0 vPortTaskWrapper (pxCode=0x40384f20 <prvIdleTask>, pvParameters=0x0) at /home/libo/esp/github_master/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:230
#1 0x00000000 in ?? ()
Backtrace stopped: frame did not save the PC
==================== THREAD 3 (TCB: 0x3fc903f8, name: 'esp_timer') =====================
#0 0x40384796 in vPortClearInterruptMaskFromISR (prev_int_level=1) at /home/libo/esp/github_master/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:417
#1 0x403847f8 in vPortExitCritical () at /home/libo/esp/github_master/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:517
#2 0x40385cfa in ulTaskGenericNotifyTake (uxIndexToWait=uxIndexToWait@entry=0, xClearCountOnExit=xClearCountOnExit@entry=1, xTicksToWait=xTicksToWait@entry=4294967295) at /home/libo/esp/github_master/components/freertos/FreeRTOS-Kernel/tasks.c:5565
#3 0x420046b6 in timer_task (arg=<error reading variable: value has been optimized out>) at /home/libo/esp/github_master/components/esp_timer/src/esp_timer.c:477
#4 0x403845bc in vPortTaskWrapper (pxCode=<optimized out>, pvParameters=<optimized out>) at /home/libo/esp/github_master/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:234
======================= ALL MEMORY REGIONS ========================
Name Address Size Attrs
.rtc.force_fast 0x50000010 0x0 RW
.rtc_noinit 0x50000010 0x0 RW
.rtc.force_slow 0x50000010 0x0 RW
.iram0.text 0x40380000 0xab8a R XA
.dram0.data 0x3fc8ac00 0x21c0 RW A
.flash.text 0x42000020 0x18504 R XA
.flash.appdesc 0x3c020020 0x100 R A
.flash.rodata 0x3c020120 0x9218 RW A
.eh_frame 0x3c029338 0xe0 R A
.flash.rodata_noload 0x3c029418 0x0 RW
.iram0.data 0x4038ac00 0x0 RW
.iram0.bss 0x4038ac00 0x0 RW
.dram0.heap_start 0x3fc8e490 0x0 RW
.coredump.tasks.data 0x3fc91594 0x154 RW
.coredump.tasks.data 0x3fc91470 0x110 RW
.coredump.tasks.data 0x3fc91cf0 0x154 RW
.coredump.tasks.data 0x3fc91c40 0xa0 RW
.coredump.tasks.data 0x3fc903f8 0x154 RW
.coredump.tasks.data 0x3fc90310 0xe0 RW
===================== ESP32 CORE DUMP END =====================
===============================================================
Done!
Coredump checksum='704e2165'
I (1064) esp_core_dump_uart: Core dump has been written to uart.
Certainly, the Core Dump contains various detailed information, some of which is already included in the backtrace, such as the current Thread/Task registers and current Thread information. The additional need for Core Dump information often arises because it prints the state of all tasks running at the time of the current exception. This can be helpful in resolving issues like watchdog problems associated with tasks.