Chapter 4. API Guides
Maximum number of tasks snapshots in core dump (Components -> Core dump -> Maximum number of
tasks)
Delay before core dump is printed to UART (Components -> Core dump -> Delay before print to UART)
The value is in ms.
Handling of UART core dumps in IDF Monitor (Components -> Core dump -> Delay before print to UART)
The value is base64 encoded.
• Decode and show summary (info_corefile)
• Don’t decode
4.9.3 Save core dump to flash
When this option is selected core dumps are saved to special partition on flash. When using default partition table
files which are provided with ESP-IDF it automatically allocates necessary space on flash, But if user wants to use its
own layout file together with core dump feature it should define separate partition for core dump as it is shown below:
# Name, Type, SubType, Offset, Size
# Note: if you have increased the bootloader size, make sure to update the offsets␣
,→to avoid overlap
nvs, data, nvs, 0x9000, 0x6000
phy_init, data, phy, 0xf000, 0x1000
factory, app, factory, 0x10000, 1M
coredump, data, coredump,, 64K
There are no special requirements for partition name. It can be chosen according to the user application needs, but
partition type should be ‘data’and sub-type should be ‘coredump’. Also when choosing partition size note that
core dump data structure introduces constant overhead of 20 bytes and per-task overhead of 12 bytes. This overhead
does not include size of TCB and stack for every task. So partition size should be at least 20 + max tasks number x
(12 + TCB size + max task stack size) bytes.
The example of generic command to analyze core dump from flash is: espcoredump.py -p </path/to/
serial/port> info_corefile </path/to/program/elf/file> or espcoredump.py -p </
path/to/serial/port> dbg_corefile </path/to/program/elf/file>
4.9.4 Print core dump to UART
When this option is selected base64-encoded core dumps are printed on UART upon system panic. In this case user
should save core dump text body to some file manually and then run the following command: espcoredump.py
--chip <target_chip_type> info_corefile -t b64 -c </path/to/saved/base64/
text> </path/to/program/elf/file> or espcoredump.py --chip <target_chip_type>
dbg_corefile -t b64 -c </path/to/saved/base64/text> </path/to/program/elf/
file>
Base64-encoded body of core dump will be between the following header and footer:
================= CORE DUMP START =================
<body of base64-encoded core dump, save it to file on disk>
================= CORE DUMP END ===================
The CORE DUMP START and CORE DUMP END lines must not be included in core dump text file.
4.9.5 ROM Functions in Backtraces
It is possible situation that at the moment of crash some tasks or/and crashed task itself have one or more ROM
functions in their callstacks. Since ROM is not part of the program ELF it will be impossible for GDB to parse such
callstacks, because it tries to analyse functions’prologues to accomplish that. In that case callstack printing will be
Espressif Systems 1328
Submit Document Feedback
Release v4.4
To Next Page
Loading...
Need help?
General