Open sett-dozee opened 8 months ago
but the backtrace from the current thread stack in the decoded ELF text does not match the backtrace in the logs
This issue has been fixed in IDF v4.4.x and later (https://github.com/espressif/esp-idf/issues/6124), please try updating to a new version.
This is the first problem, the code is crashing when compiled with Compiler option = Optimize for size and I am not able to understand what the problem could be causing #0 _DoubleExceptionVector () at /home/dozee/esp/esp-idf/components/freertos/port/xtensa/xtensa_vectors.S:455
I recommend checking the stack size of your usbserial
task, it could be that you are overflowing the stack, which leads to heap corruption and the subsequent crash inside the scheduler.
Thanks for the quick response
The USB serial task has a stack size of 6 KB and when I build the code with Compiler options = Debug
, this issue is not seen
Answers checklist.
General issue report
I want to be able to store the backtrace in someway --> retrieve it during a reboot --> write to a file --> upload to the cloud
I am using ESP-IDF v4.3
In trying to do this, I have faced 2 issues.
I followed the steps in the CoreDump Documentation and created the partition as below
When I build the code after this I get the following error
I changed the setting in
idf.py menuconfig
Compiler options --> Optimization level
fromDebug (-0g)
toOptimize for size (-0s)
after which I am able to build the project. However when the firmware is flashed, the device seems to crash with the following message printedMy first issue is that I am not able to debug anything from the backtrace using the command
xtensa-esp32-elf-addr2line -pfiaC -e build/dozee_next.elf Backtrace:0x400803bd:0x3ffb44b0
. However if I enablePrint coredump to UART
, and decode the ELF content I get the following outputThis is the first problem, the code is crashing when compiled with
Compiler option = Optimize for size
and I am not able to understand what the problem could be causing#0 _DoubleExceptionVector () at /home/dozee/esp/esp-idf/components/freertos/port/xtensa/xtensa_vectors.S:455
The second problem I am facing is that, when I decode the Core Dump printed to UART and cross check with the Backtrace printed in serial logs before ESP32 reboots, they do not match I put an
assert(0)
in my code as mentioned in the example of the coredump documentation with coredump printed to UART. The serial logs obtained are as belowThe backtrace printed in the logs above is
Backtrace:0x40084242:0x3ffbc590 0x40084935:0x3ffbc5b0 0x40089a1e:0x3ffbc5d0 0x400d2915:0x3ffbc640 0x400e3136:0x3ffbc860
but the backtrace from the current thread stack in the decoded ELF text does not match the backtrace in the logs When I decode the coredump ELF text I get the following outputCan someone please help me with the above issues or tell another method to capture the backtrace?