(resolved) reverted IDF version; now program won't run

[mzimmers]

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]

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.

[mzimmers]

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]

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"?

[mzimmers]

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)

[mzimmers]

I got pulled off this project for a few days. Does the output of my "make size" suggest that I need to reduce the use of static variables?

[mzimmers]

Bump...anyone?

I've looked through my code, and I don't have much use of heap that I can find. I assume that a global such as:

Code: Select all

constexpr int BATTERY_VOLTAGE_RECOVERY = 3500;

In a header file gets place into a code segment, right? So these shouldn't be causing my issue.

[fly135]

I think that const initialized data is stored in flash. So I believe that BATTERY_VOLTAGE_RECOVERY definition would not take up ram.

John A

[mzimmers]

I just built against the master instead of release v3.1...boots and runs fine.

Based on this, I doubt that it's a matter of insufficient heap memory; it's hard to imagine that the OS got smaller from 3.1 to 3.3.

EDIT: then again, maybe it is. I spoke too soon above: it does boot fine, but after running for a few minutes, I get a GME...looking at the trace, there's a call in multi_heap_poisoning.c, from the call to i2c_cmd_delete():

Code: Select all

    m_i2c_cmd = i2c_cmd_link_create();
    if (m_i2c_cmd != nullptr)
    {
      ...
        i2c_cmd_link_delete(m_i2c_cmd);

I'm really not sure what to do about this...