reverted IDF version; now program won't run

User avatar
mzimmers
Posts: 277
Joined: Wed Mar 07, 2018 11:54 pm
Location: USA

Re: reverted IDF version; now program won't run

Postby mzimmers » Fri Mar 15, 2019 1:46 am

I'm not sure what you mean by the full call stack. Do you mean you want me to go further with the addr2line commands?

ESP_Angus
Posts: 1464
Joined: Sun May 08, 2016 4:11 am

Re: reverted IDF version; now program won't run

Postby ESP_Angus » Fri Mar 15, 2019 2:55 am

mzimmers wrote:
Fri Mar 15, 2019 1:46 am
I'm not sure what you mean by the full call stack. Do you mean you want me to go further with the addr2line commands?
Yes please. I'd like to know at what point vfprintf() was being called.

User avatar
mzimmers
Posts: 277
Joined: Wed Mar 07, 2018 11:54 pm
Location: USA

Re: reverted IDF version; now program won't run

Postby mzimmers » Fri Mar 15, 2019 2:14 pm

OK, here it is...thanks.
$ addr2line -e build/WifiButton.elf -pfia
0x4008d6f4
0x4008d6f4: invoke_abort at C:/esp-idf/components/esp32/panic.c:676
0x4008d8f3
0x4008d8f3: abort at C:/esp-idf/components/esp32/panic.c:676
0x4008377f
0x4008377f: lock_init_generic at C:/esp-idf/components/newlib/locks.c:81
0x400837af
0x400837af: lock_acquire_generic at C:/esp-idf/components/newlib/locks.c:134
0x40083929
0x40083929: _lock_acquire_recursive at C:/esp-idf/components/newlib/locks.c:171
0x400fa68f
0x400fa68f: _vfiprintf_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:860 (discriminator 2)
0x400f5ee1
0x400f5ee1: fiprintf at /Users/ivan/e/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdio/../../../.././newlib/libc/stdio/fiprintf.c:50
0x400f5e70
0x400f5e70: __assert_func at /Users/ivan/e/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdlib/../../../.././newlib/libc/stdlib/assert.c:59 (discriminator 8)
0x400d6afa
0x400d6afa: esp_dport_access_int_init at C:/esp-idf/components/esp32/dport_access.c:187 (discriminator 1)
0x40081258
0x40081258: start_cpu1_default at C:/esp-idf/components/esp32/cpu_start.c:414
0x400812c5
0x400812c5: call_start_cpu1 at C:/esp-idf/components/esp32/cpu_start.c:253
0x40007c31
0x40007c31: ?? ??:0
0x4000073d
0x4000073d: ?? ??:0

ESP_Angus
Posts: 1464
Joined: Sun May 08, 2016 4:11 am

Re: reverted IDF version; now program won't run

Postby ESP_Angus » Mon Mar 18, 2019 6:20 am

Hi mzimmers,

Thanks for posting this. It looks like esp_dport_access_int_init() is failing to create the dport access task, probably due to running out of memory. Then, printing the actual abort() message is failing for the same reason (it tries to allocate a lock which fails - probably due to OOM again.)

It was recently reported that it's possible to build ESP-IDF apps which don't use too much static memory to link successfully, but do use too much static memory to boot successfully, because we can't access all of the heap memory during early boot. This seems the most likely explanation for this case, also.

We'll fix the bug (so linking would fail in this case) soon, but in the meantime if you can reduce the static usage of your app by a small amount (ie move some large buffer to be malloc()-ed on startup instead of defined statically) then it should boot successfully.

If you're unsure if this is the correct root cause, can you please post output of "make size"?

User avatar
mzimmers
Posts: 277
Joined: Wed Mar 07, 2018 11:54 pm
Location: USA

Re: reverted IDF version; now program won't run

Postby mzimmers » Mon Mar 18, 2019 3:04 pm

Hi Angus - I'll look at reducing my static memory. Here's the output of make size:
Total sizes:
DRAM .data size: 13700 bytes
DRAM .bss size: 77552 bytes
Used static DRAM: 91252 bytes ( 23948 available, 79.2% used)
Used static IRAM: 82472 bytes ( 48600 available, 62.9% used)
Flash code: 819898 bytes
Flash rodata: 241300 bytes
Total image size:~1157370 bytes (.bin may be padded larger)

Who is online

Users browsing this forum: Google [Bot] and 17 guests