ESP32 Forum

Posted: **Fri Apr 19, 2019 1:53 am**

hey everyone,

For some reason the coredump utility is providing me with nearly no info.

It either just says that a brownout procured or that it couldn't access some memory region or some other random info.

I had a look at kolbans book and in it he gets the exact line at which the error occured.

I cloned the esp-idf template and made the following changes to menuconfig:

component config ->ESP32-specific -> panic handler behaviour - > Print registers and halt
and component config->coredump -> Data destination: UART, Maximum number of tasks:64, delay before print to uart: 0:

After this I added this line to the code:
memcpy((void*)0x2000000, "VOPS", 4);

And it generates the following current thread stack:

==================== CURRENT THREAD STACK =====================
#0 esp_ipc_call_and_wait (cpu_id=33554432, func=0x1, arg=0x1, wait_for=IPC_WAIT_FOR_END) at /home/user/esp/esp-idf/components/esp32/ipc.c:107
#1 0x400d0e6d in _stext ()
#2 0x4008ded4 in rtc_clk_slow_freq_set (slow_freq=(unknown: 1074597384)) at /home/user/esp/esp-idf/components/soc/esp32/rtc_clk.c:251

The command I run to produce this is :

python ~/Desktop/esp32/esp-idf/components/espcoredump/espcoredump.py info_corefile -d 3 -t b64 -c ~/Desktop/dump.txt ~/Desktop/esp-idf-template/build/app-template.elf

I've tried a lot of variants of producing core dumps and each provides nearly no info in where the error exactly occurred.

Does anyone know what I might be doing incorrectly?

Any help will really be appreciated as debugging coredumps at this point has been very difficult

Posted: **Sun Apr 21, 2019 11:01 am**

Ian777 wrote: ↑
Fri Apr 19, 2019 1:53 am
hey everyone,

For some reason the coredump utility is providing me with nearly no info.

It either just says that a brownout procured or that it couldn't access some memory region or some other random info.

I had a look at kolbans book and in it he gets the exact line at which the error occured.

I cloned the esp-idf template and made the following changes to menuconfig:

component config ->ESP32-specific -> panic handler behaviour - > Print registers and halt
and component config->coredump -> Data destination: UART, Maximum number of tasks:64, delay before print to uart: 0:

After this I added this line to the code:
memcpy((void*)0x2000000, "VOPS", 4);

And it generates the following current thread stack:

==================== CURRENT THREAD STACK =====================
#0 esp_ipc_call_and_wait (cpu_id=33554432, func=0x1, arg=0x1, wait_for=IPC_WAIT_FOR_END) at /home/user/esp/esp-idf/components/esp32/ipc.c:107
#1 0x400d0e6d in _stext ()
#2 0x4008ded4 in rtc_clk_slow_freq_set (slow_freq=(unknown: 1074597384)) at /home/user/esp/esp-idf/components/soc/esp32/rtc_clk.c:251

The command I run to produce this is :

python ~/Desktop/esp32/esp-idf/components/espcoredump/espcoredump.py info_corefile -d 3 -t b64 -c ~/Desktop/dump.txt ~/Desktop/esp-idf-template/build/app-template.elf

I've tried a lot of variants of producing core dumps and each provides nearly no info in where the error exactly occurred.

Does anyone know what I might be doing incorrectly?

Any help will really be appreciated as debugging coredumps at this point has been very difficult

Hi,

Did you try with add2line utility which is part of toolchain binary?

We are using that utility and we are getting flow of crash dump with details.

Posted: **Mon Apr 22, 2019 5:56 pm**

Ritesh wrote: ↑
Sun Apr 21, 2019 11:01 am

Ian777 wrote: ↑
Fri Apr 19, 2019 1:53 am
hey everyone,

For some reason the coredump utility is providing me with nearly no info.

It either just says that a brownout procured or that it couldn't access some memory region or some other random info.

I had a look at kolbans book and in it he gets the exact line at which the error occured.

I cloned the esp-idf template and made the following changes to menuconfig:

component config ->ESP32-specific -> panic handler behaviour - > Print registers and halt
and component config->coredump -> Data destination: UART, Maximum number of tasks:64, delay before print to uart: 0:

After this I added this line to the code:
memcpy((void*)0x2000000, "VOPS", 4);

And it generates the following current thread stack:

==================== CURRENT THREAD STACK =====================
#0 esp_ipc_call_and_wait (cpu_id=33554432, func=0x1, arg=0x1, wait_for=IPC_WAIT_FOR_END) at /home/user/esp/esp-idf/components/esp32/ipc.c:107
#1 0x400d0e6d in _stext ()
#2 0x4008ded4 in rtc_clk_slow_freq_set (slow_freq=(unknown: 1074597384)) at /home/user/esp/esp-idf/components/soc/esp32/rtc_clk.c:251

The command I run to produce this is :

python ~/Desktop/esp32/esp-idf/components/espcoredump/espcoredump.py info_corefile -d 3 -t b64 -c ~/Desktop/dump.txt ~/Desktop/esp-idf-template/build/app-template.elf

I've tried a lot of variants of producing core dumps and each provides nearly no info in where the error exactly occurred.

Does anyone know what I might be doing incorrectly?

Any help will really be appreciated as debugging coredumps at this point has been very difficult
Hi,

Did you try with add2line utility which is part of toolchain binary?

We are using that utility and we are getting flow of crash dump with details.

Hi Ritesh Prajapati!
Thank you so much for the reply.

I see that make monitor runs this command and I have tried to manually run it on my build/file.elf, but sadly I think I don't quite understand how to go about this.

Would you mind providing me with some more info or an example?

Thanks in advance for any help!

I really appreciate it

EDIT: If I understand it correctly, the command would look like this:

xtensa-esp32-elf-addr2line -pfiaC -e ~/Desktop/esp-idf-template/build/app-template.elf 0x400014fd:0x3ffbb5f0 0x400d543d:0x3ffbb600 0x400d54d5:0x3ffbb640 0x4 00d40a8:0x3ffbb660 0x400d2e36:0x3ffbb760 0x400d0db2:0x3ffbb900 0x4008da85:0x3ffb

where I provide the project's build elf file followed by the backtrace produced from the panic?

Posted: **Tue Apr 23, 2019 9:28 am**

Ian777 wrote: ↑
Mon Apr 22, 2019 5:56 pm

Ritesh wrote: ↑
Sun Apr 21, 2019 11:01 am

Ian777 wrote: ↑
Fri Apr 19, 2019 1:53 am
hey everyone,

For some reason the coredump utility is providing me with nearly no info.

It either just says that a brownout procured or that it couldn't access some memory region or some other random info.

I had a look at kolbans book and in it he gets the exact line at which the error occured.

I cloned the esp-idf template and made the following changes to menuconfig:

component config ->ESP32-specific -> panic handler behaviour - > Print registers and halt
and component config->coredump -> Data destination: UART, Maximum number of tasks:64, delay before print to uart: 0:

After this I added this line to the code:
memcpy((void*)0x2000000, "VOPS", 4);

And it generates the following current thread stack:

==================== CURRENT THREAD STACK =====================
#0 esp_ipc_call_and_wait (cpu_id=33554432, func=0x1, arg=0x1, wait_for=IPC_WAIT_FOR_END) at /home/user/esp/esp-idf/components/esp32/ipc.c:107
#1 0x400d0e6d in _stext ()
#2 0x4008ded4 in rtc_clk_slow_freq_set (slow_freq=(unknown: 1074597384)) at /home/user/esp/esp-idf/components/soc/esp32/rtc_clk.c:251

The command I run to produce this is :

python ~/Desktop/esp32/esp-idf/components/espcoredump/espcoredump.py info_corefile -d 3 -t b64 -c ~/Desktop/dump.txt ~/Desktop/esp-idf-template/build/app-template.elf

I've tried a lot of variants of producing core dumps and each provides nearly no info in where the error exactly occurred.

Does anyone know what I might be doing incorrectly?

Any help will really be appreciated as debugging coredumps at this point has been very difficult
Hi,

Did you try with add2line utility which is part of toolchain binary?

We are using that utility and we are getting flow of crash dump with details.
Hi Ritesh Prajapati!
Thank you so much for the reply.

I see that make monitor runs this command and I have tried to manually run it on my build/file.elf, but sadly I think I don't quite understand how to go about this.

Would you mind providing me with some more info or an example?

Thanks in advance for any help!

I really appreciate it

EDIT: If I understand it correctly, the command would look like this:

xtensa-esp32-elf-addr2line -pfiaC -e ~/Desktop/esp-idf-template/build/app-template.elf 0x400014fd:0x3ffbb5f0 0x400d543d:0x3ffbb600 0x400d54d5:0x3ffbb640 0x4 00d40a8:0x3ffbb660 0x400d2e36:0x3ffbb760 0x400d0db2:0x3ffbb900 0x4008da85:0x3ffb

where I provide the project's build elf file followed by the backtrace produced from the panic?

Yes.

Command which you have used is correct.

So, Would you please send me oitput of that command which you have executes on your elf file to get crash analysis?

Posted: **Wed May 22, 2019 8:42 pm**

HI Ritesh Prajapati,

Sorry I completely forgot to reply and have still not gotten this working.

Here's the output of the core dump:

Code: Select all

python ~/esp/esp-idf/components/espcoredump/espcoredump.py info_corefile -d 3 -t b64 -c ~/Desktop/dump1.txt ~/Desktop/esp-idf-template/build/app-template.elf
espcoredump.py v0.3-dev
INFO:Read TCB 356 bytes @ 0x3ffbb5dc
INFO:Read stack 776 bytes @ 0x3ffbb2c0
INFO:Stack start_end: 0x3ffbb2c0 @ 0x3ffbb5c8
INFO:Read TCB 356 bytes @ 0x3ffbc4e4
INFO:Read stack 416 bytes @ 0x3ffbc330
INFO:Stack start_end: 0x3ffbc330 @ 0x3ffbc4d0
INFO:Read TCB 356 bytes @ 0x3ffbbd60
INFO:Read stack 428 bytes @ 0x3ffbbba0
INFO:Stack start_end: 0x3ffbbba0 @ 0x3ffbbd4c
INFO:Read TCB 356 bytes @ 0x3ffbf800
INFO:Read stack 524 bytes @ 0x3ffbf5e0
INFO:Stack start_end: 0x3ffbf5e0 @ 0x3ffbf7ec
INFO:Read TCB 356 bytes @ 0x3ffbcf68
INFO:Read stack 420 bytes @ 0x3ffbcdb0
INFO:Stack start_end: 0x3ffbcdb0 @ 0x3ffbcf54
INFO:Read TCB 356 bytes @ 0x3ffb9e20
INFO:Read stack 476 bytes @ 0x3ffb9c30
INFO:Stack start_end: 0x3ffb9c30 @ 0x3ffb9e0c
INFO:Read TCB 356 bytes @ 0x3ffc0f5c
INFO:Read stack 488 bytes @ 0x3ffc0d60
INFO:Stack start_end: 0x3ffc0d60 @ 0x3ffc0f48
INFO:Read TCB 356 bytes @ 0x3ffc2920
INFO:Read stack 492 bytes @ 0x3ffc2720
INFO:Stack start_end: 0x3ffc2720 @ 0x3ffc290c
INFO:Read TCB 356 bytes @ 0x3ffafb80
INFO:Read stack 428 bytes @ 0x3ffaf9c0
INFO:Stack start_end: 0x3ffaf9c0 @ 0x3ffafb6c
INFO:Read TCB 356 bytes @ 0x3ffb989c
INFO:Read stack 424 bytes @ 0x3ffb96e0
INFO:Stack start_end: 0x3ffb96e0 @ 0x3ffb9888
===============================================================
==================== ESP32 CORE DUMP START ====================

================== CURRENT THREAD REGISTERS ===================
pc             0x400d6a47       0x400d6a47 <_svfprintf_r+9743>
lbeg           0x400014fd       1073747197
lend           0x4000150d       1073747213
lcount         0xfffffffa       4294967290
sar            0x4      4
ps             0x60520  394528
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             0x400d2ba5       1074604965
a1             0x3ffbb380       1073460096
a2             0x3ffbe1a4       1073471908
a3             0x3ffbe200       1073472000
a4             0x3ffbd164       1073467748
a5             0x3ffbd194       1073467796
a6             0x2000000        33554432
a7             0x53504f56       1397772118
a8             0x800d6a41       -2146604479
a9             0x3ffbb190       1073459600
a10            0x0      0
a11            0x3ffb3f38       1073430328
a12            0x3ffb3f78       1073430392
a13            0x0      0
a14            0x3ffaffe4       1073414116
a15            0x60023  393251

==================== CURRENT THREAD STACK =====================
#0  0x400d6a47 in _svfprintf_r (data=<optimized out>, fp=<optimized out>, fmt0=<optimized out>, ap=...) at ../../../.././newlib/libc/stdio/vfprintf.c:1696
#1  0x400d2ba5 in heap_caps_init () at /home/con3/esp/esp-idf/components/heap/heap_caps_init.c:98
#2  0x4008a88c in tx_pwctrl_cal ()

======================== THREADS INFO =========================
  Id   Target Id         Frame 
  10   process 9         0x4008b409 in spi_new_trans (dev=0x3ffaff18, trans_buf=0x0) at /home/con3/esp/esp-idf/components/driver/spi_master.c:954
  9    process 8         0x4008b409 in spi_new_trans (dev=0x3ffaeab0, trans_buf=0x0) at /home/con3/esp/esp-idf/components/driver/spi_master.c:954
  8    process 7         0x4008b409 in spi_new_trans (dev=0x3ffc1410, trans_buf=0x3ffc2850) at /home/con3/esp/esp-idf/components/driver/spi_master.c:954
  7    process 6         0x4008b409 in spi_new_trans (dev=0x3ffbfa8c, trans_buf=0x3ffc0e60) at /home/con3/esp/esp-idf/components/driver/spi_master.c:954
  6    process 5         0x4000bff0 in ?? ()
  5    process 4         0x4008d17c in coex_bt_high_prio () at bt_bb.c:391
  4    process 3         0x4008b409 in spi_new_trans (dev=0x3ffbe890, trans_buf=0x3ffbf730) at /home/con3/esp/esp-idf/components/driver/spi_master.c:954
  3    process 2         0x40166b52 in ?? ()
  2    process 1         0x40166b52 in ?? ()
* 1    <main task>       0x400d6a47 in _svfprintf_r (data=<optimized out>, fp=<optimized out>, fmt0=<optimized out>, ap=...) at ../../../.././newlib/libc/stdio/vfprintf.c:1696

======================= ALL MEMORY REGIONS ========================
Name   Address   Size   Attrs
.rtc.text 0x400c0000 0x0 RW  
.rtc.dummy 0x3ff80000 0x0 RW  
.rtc.force_fast 0x3ff80000 0x0 RW  
.rtc_noinit 0x50000000 0x0 RW  
.rtc.force_slow 0x50000000 0x0 RW  
.iram0.vectors 0x40080000 0x400 R XA
.iram0.text 0x40080400 0x11700 RWXA
.dram0.data 0x3ffb0000 0x2e00 RW A
.noinit 0x3ffb2e00 0x0 RW  
.flash.rodata 0x3f400020 0x1dbd0 RW A
.flash.text 0x400d0018 0x727c8 R XA
.coredump.tasks.data 0x3ffbb5dc 0x164 RW 
.coredump.tasks.data 0x3ffbb2c0 0x308 RW 
.coredump.tasks.data 0x3ffbc4e4 0x164 RW 
.coredump.tasks.data 0x3ffbc330 0x1a0 RW 
.coredump.tasks.data 0x3ffbbd60 0x164 RW 
.coredump.tasks.data 0x3ffbbba0 0x1ac RW 
.coredump.tasks.data 0x3ffbf800 0x164 RW 
.coredump.tasks.data 0x3ffbf5e0 0x20c RW 
.coredump.tasks.data 0x3ffbcf68 0x164 RW 
.coredump.tasks.data 0x3ffbcdb0 0x1a4 RW 
.coredump.tasks.data 0x3ffb9e20 0x164 RW 
.coredump.tasks.data 0x3ffb9c30 0x1dc RW 
.coredump.tasks.data 0x3ffc0f5c 0x164 RW 
.coredump.tasks.data 0x3ffc0d60 0x1e8 RW 
.coredump.tasks.data 0x3ffc2920 0x164 RW 
.coredump.tasks.data 0x3ffc2720 0x1ec RW 
.coredump.tasks.data 0x3ffafb80 0x164 RW 
.coredump.tasks.data 0x3ffaf9c0 0x1ac RW 
.coredump.tasks.data 0x3ffb989c 0x164 RW 
.coredump.tasks.data 0x3ffb96e0 0x1a8 RW 

===================== ESP32 CORE DUMP END =====================
===============================================================

Here's the output of the backtrace:

Code: Select all

xtensa-esp32-elf-addr2line -pfiaC -e ~/Desktop/esp-idf-template/build/app-template.elf 0x400d6a47:0x3ffbb380 0x400d2ba2:0x3ffbb520 0x4008a889:0x3ffbb540
0x400d6a47: _svfprintf_r at /Users/ivan/e/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdio/../../../.././newlib/libc/stdio/vfprintf.c:1696
0x400d2ba2: heap_caps_init at /home/con3/esp/esp-idf/components/heap/heap_caps_init.c:98
0x4008a889: tx_pwctrl_cal at ??:?

ESP32 Forum

CoreDump not providing enough info

CoreDump not providing enough info

Re: CoreDump not providing enough info

Re: CoreDump not providing enough info

Re: CoreDump not providing enough info

Re: CoreDump not providing enough info