Closed Tarik2142 closed 22 hours ago
board_upload.flash_size = 16MB board_build.flash_size = 16MB board_build.partitions = default_16MB.csv
exception does not happen during the coredump error. Your trace clearly says it happened in your assert. Remove the assert and if happens again, we can discuss further. The error can be dismissed as it does not prevent the firmware to work, it just says that coredump data will not be valid if extracted.
exception does not happen during the coredump error. Your trace clearly says it happened in your assert. Remove the assert and if happens again, we can discuss further. The error can be dismissed as it does not prevent the firmware to work, it just says that coredump data will not be valid if extracted.
This is the problem, if a crash occurs I can't use coredump to find out the cause because it is corrupted.
It is generally not enabled on our end for that. It's instead used by RainMaker and ESP-Insights. That is the only reason we have that partition there.
Are you sure? I see that it was turned on specifically for crash decoding https://github.com/espressif/arduino-esp32/issues/9808
I need to doublecheck, but maybe it does not work with assert?
Docs: https://docs.espressif.com/projects/esp-idf/en/v5.1.5/esp32/api-guides/core_dump.html
It mentions cases where coredump might be corrupted.
I didn't get this problem on core 2.x
As far as I remember coredump was off in 2.x
if a crash occurs I can't use coredump to find out the cause because it is corrupted.
can you show such crash? Because with assert you are given where it happened and also a backtrace along with it
if a crash occurs I can't use coredump to find out the cause because it is corrupted.
can you show such crash? Because with assert you are given where it happened and also a backtrace along with it
Here is an example of a dump crashbump-webui-fail.zip
In v2.0.6 I could get all the information but in 3.0.7 he dumps no longer open due to a checksum error
In that case I will suggest you ask in the ESP-IDF repo if they know about an issue with coredump in IDF 5.1. You could also try to use Arduino 3.1.0-RC3 which is based on IDF 5.3 and see if there is any change. On our end we only enable the feature, but have no control over what it does and how it works. Make sure you have the sdkconfig ready (it's located in the libs package that gets installed with the core)
The example dump you posted is triggered by task WDT. I do not know if that matters.
A Image checksum='ffffffff'
probably there is nothing stored at all.
yes, but it's clearly enabled to do so in sdkconfig
In that case I will suggest you ask in the ESP-IDF repo if they know about an issue with coredump in IDF 5.1. You could also try to use Arduino 3.1.0-RC3 which is based on IDF 5.3 and see if there is any change. On our end we only enable the feature, but have no control over what it does and how it works. Make sure you have the sdkconfig ready (it's located in the libs package that gets installed with the core)
The example dump you posted is triggered by task WDT. I do not know if that matters.
Ok, will try to ask in IDF. I tried 3.1.0-RC3, same problem. Close it for now.
Board
esp32dev
Device Description
-
Hardware Configuration
-
Version
latest master (checkout manually)
IDE Name
pio
Operating System
Windows 10
Flash frequency
-
PSRAM enabled
no
Upload speed
115200
Description
I completely wiped the chip and flashed it from scratch. I didn't get this problem on core 2.x
I get:
E (169) esp_core_dump_flash: ����e dump data check failed: Calculated checksum='a1ca788b' Image checksum='ffffffff'
after the firstassert(0)
and coredump doesn't work anymore. Also, the device does not always reboot after a crash, it can remain in halt mode forever.Sketch
Debug Message
Other Steps to Reproduce
just crash esp32 :)
I have checked existing issues, online documentation and the Troubleshooting Guide