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?

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 ...

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:8...

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?

Here's the boot log: I (28) boot: ESP-IDF v3.1.3-58-gcea310d5c 2nd stage bootloader I (29) boot: compile time 06:48:15 I (32) boot: Enabling RNG early entropy source... I (33) boot: SPI Speed : 40MHz I (37) boot: SPI Mode : DIO I (41) boot: SPI Flash Size : 4MB I (45) boot: Partition Table: I (49) b...

Yes, I did. I also loaded hello_world and that ran fine, so I don't know what to think. I guess I could try building against V3.2 and see if that works. What do you think?

Still no joy. I've done the following:

- deleted my build directory
- deleted my idf
- downloaded new idf from github
- checkout branch release/v3.1
- git submodule update --recursive
- run make flash

Still getting that abort on startup.

Hi Angus - deleting and running make didn't change behavior. I'll try a make clean now and report back.

Hi all - I'd been using the master version of the IDF for several weeks. Because I'm running into a few problems that I just can't explain, I decided to revert to the released version (V3.1.3 I think it is). I needed to change a couple include paths, and make menuconfig ran again, but building was f...

Another data point: what I said about being low on memory evidently was wrong: I put in a call to heap_caps_get_free_size(), and it tells me there are ~118K bytes free.