Coredump to flash not working in SDK V5.2.1 (bin or elf same error) (IDFGH-12462)

[filzek]

partition as of
nvs, data, nvs, 0xA000, 24K,
otadata, data, ota, , 8K,
phy_init, data, phy, , 4K,
nvs_keys, data, nvs_keys, , 24K,
factory_nvs, data, nvs, , 24K,
ota_0, app, ota_0, 0x20000, 0x340000,encrypted
coredump, data, coredump, , 64K, encrypted

made proposital error doing
//crash proposital area for coredump
global_var = 25;
int *ptr = NULL;
*ptr = 42; // This will cause a crash due to null pointer dereference
int zero = 0;
int result = 10 / zero; // This will cause a crash due to division by zero
//end crash area for coredump

so this will bring the coredump to be executed,

after it, set the debug board to run in download mode and run

idf.py coredump-debug --port com3
Executing action: coredump-debug
Failed to load core dump: parttool script execution failed with error 1, failed command was: 'C:\Espressif\python_env\idf5.2_py3.11_env\Scripts\python.exe C:\Espressif\frameworks\esp-idf-v5.2\components\partition_table\parttool.py --port com3 --baud 460800 --partition-table-offset 0x9000
read_partition --partition-type data --partition-subtype coredump --output C:\Users\devop\AppData\Local\Temp\tmpz_btbjwn'

┌────── Additional information about the error:
│
│ esptool.py v4.7.0
│ Serial port com3
│ Connecting...
│ Failed to get PID of a device on com3, using standard reset sequence.
│ ...............................
│ Detecting chip type... Unsupported detection protocol, switching and trying again...
│ Connecting...
│ Failed to get PID of a device on com3, using standard reset sequence.

│ Detecting chip type... ESP32
│ Chip is ESP32-D0WD-V3 (revision v3.0)
│ Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
│ Crystal is 40MHz
│ MAC: 08:3a:f2:04:a3:c8
│ Uploading stub...
│ Running stub...
│ Stub running...
│ Changing baud rate to 460800
│ Changed.
│ 3072 (100 %)
│ 3072 (100 %)
│ Read 3072 bytes at 0x00009000 in 0.1 seconds (305.4 kbit/s)...
│ Hard resetting via RTS pin...
│ Running C:\Espressif\python_env\idf5.2_py3.11_env\Scripts\python.exe C:\Espressif\frameworks\esp-idf-v5.2\components\esptool_py\esptool\esptool.py --port com3 --baud 460800 read_flash 36864 3072 C:\Users\devop\AppData\Local\Temp\tmp4thh57q6...
│ Traceback (most recent call last):
│ File "C:\Espressif\frameworks\esp-idf-v5.2\components\partition_table\parttool.py", line 363, in
│ main()
│ File "C:\Espressif\frameworks\esp-idf-v5.2\components\partition_table\parttool.py", line 332, in main
│ target = ParttoolTarget(**target_args)
│ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
│ File "C:\Espressif\frameworks\esp-idf-v5.2\components\partition_table\parttool.py", line 105, in init
│ partition_table = gen.PartitionTable.from_binary(f.read())
│ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
│ File "C:\Espressif\frameworks\esp-idf-v5.2\components\partition_table\gen_esp32part.py", line 319, in from_binary
│ result.append(PartitionDefinition.from_binary(data))
│ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
│ File "C:\Espressif\frameworks\esp-idf-v5.2\components\partition_table\gen_esp32part.py", line 475, in from_binary
│ res.name = res.name.decode()
│ ^^^^^^^^^^^^^^^^^
│ UnicodeDecodeError: 'utf-8' codec can't decode byte 0xbd in position 2: invalid start byte

[filzek]

Espressif IoT Development Framework Configuration
Data destination (Flash) --->
Core dump data format (Binary format) --->
Core dump data integrity check (Use CRC32 for integrity verification) --->
[] Check core dump data integrity on boot
[] Enable coredump logs for debugging
(64) Maximum number of tasks
(0) Reserved stack size

or

Data destination (Flash) --->
Core dump data format (ELF format) --->
Core dump data integrity check (Use CRC32 for integrity verification) --->
[] Check core dump data integrity on boot
[] Enable coredump logs for debugging
(64) Maximum number of tasks
(0) Reserved stack size

have the same behavior on trying to read

[filzek]

Guru Meditation Error: Core 0 panic'ed (StoreProhibited). Exception was unhandled.

Core 0 register dump:
PC : 0x400f0e2f PS : 0x00060c30 A0 : 0x80138bd8 A1 : 0x3fff30b0
0x400f0e2f: websocket_event_handler at D:/Dropbox/Dev/Producao5/main/tasks/taskWebsocket.c:633

A2 : 0x00000000 A3 : 0x3f40ff7c A4 : 0x00000000 A5 : 0x3ffe3c78
A6 : 0x400f0974 A7 : 0x3ffbf0ad A8 : 0x00000000 A9 : 0x3ffc29d4
0x400f0974: websocket_event_handler at D:/Dropbox/Dev/Producao5/main/tasks/taskWebsocket.c:377

A10 : 0x00000019 A11 : 0x00060823 A12 : 0x00060820 A13 : 0xffffffff
A14 : 0x00000000 A15 : 0x3ffbb9cc SAR : 0x0000001f EXCCAUSE: 0x0000001d
EXCVADDR: 0x00000000 LBEG : 0x400957f9 LEND : 0x40095809 LCOUNT : 0xfffffffb
0x400957f9: strlen at /builds/idf/crosstool-NG/.build/HOST-x86_64-w64-mingw32/xtensa-esp-elf/src/newlib/newlib/libc/machine/xtensa/strlen.S:84
0x40095809: strlen at /builds/idf/crosstool-NG/.build/HOST-x86_64-w64-mingw32/xtensa-esp-elf/src/newlib/newlib/libc/machine/xtensa/strlen.S:96

Backtrace: 0x400f0e2c:0x3fff30b0 0x40138bd5:0x3fff3110 0x40111dd6:0x3fff3150 0x40111ea5:0x3fff31b0 0x4011208d:0x3fff3200 0x400992c2:0x3fff3240
0x400f0e2c: websocket_event_handler at D:/Dropbox/Dev/Producao5/main/tasks/taskWebsocket.c:633
0x40138bd5: handler_execute at C:/Espressif/frameworks/esp-idf-v5.2/components/esp_event/esp_event.c:139
(inlined by) esp_event_loop_run at C:/Espressif/frameworks/esp-idf-v5.2/components/esp_event/esp_event.c:593
0x40111dd6: esp_websocket_client_dispatch_event at D:/Dropbox/Dev/Producao5/managed_components/espressif__esp_websocket_client/esp_websocket_client.c:220
0x40111ea5: esp_websocket_client_error at D:/Dropbox/Dev/Producao5/managed_components/espressif__esp_websocket_client/esp_websocket_client.c:267
0x4011208d: esp_websocket_client_task at D:/Dropbox/Dev/Producao5/managed_components/espressif__esp_websocket_client/esp_websocket_client.c:942
0x400992c2: vPortTaskWrapper at C:/Espressif/frameworks/esp-idf-v5.2/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:134

ELF file SHA256: cfca5fe5e

Rebooting...

[peterdragun]

Hi @filzek,
the issue in your case seems to be reading the partition table. First, the partition table is used to find the offset of the coredump partition and then the coredump itself is read. I am not sure why the reading of partition is failing for you. I have tried to reproduce the issue based on the information you provided, but it was working as expected for me. It seems that you are using some custom partition table offset, can you please verify that it is using the correct offset - 0x9000 - for the partition table?
As a workaround, you can use esp-coredump directly and specify the offset of the coredump partition. In that case, the first step of reading the partition table would be skipped and it will read the coredump partition directly. You can do that with the following command:

esp-coredump --port /dev/cu.usbserial-10 dbg_corefile --off 3538944 <path-to-the-elf-file>

Please replace <path-to-the-elf-file> with your path, it should be something like build/main.elf
You may also consider lowering the baud rate to e.g. 115200, if you have issues while reading.

[peterdragun]

Sorry, I have just realized that I have missed one important thing from your report - it seems, from the partition table, that you have enabled the flash encryption. In that case, the error makes a lot of sense now. So when the esp-coredump is reading the partition table it is not able to decode bytes because they are encrypted. The issue is that the encryption key is typically not known to the host where the esp-coredump tool is being run. I am afraid that in this case it is expected behavior and there is not much that can be done.

If you are still developing the application I would suggest printing the coredump to UART, where the esp-idf-monitor would be able to decode it. In the case of an already deployed application, the easiest way would be to decode the coredump on a chip and send the core file somewhere where you can analyze it.

For a similar report see: https://www.esp32.com/viewtopic.php?t=34714&p=117051
You may also find some suggestions there.