I get error messages with the includes of umm_malloc_cfg.h. I get about 600 lines of errors but this is just a selection of them. They’re all essentially the same, but for different header files.
c:\users\user\.platformio\packages\toolchain-xtensa\lib\gcc\xtensa-lx106-elf\4.8.2\include\stddef.h: Assembler messages:
c:\users\user\.platformio\packages\toolchain-xtensa\lib\gcc\xtensa-lx106-elf\4.8.2\include\stddef.h:147: Error: unknown opcode or format name 'typedef'
C:\Users\user\.platformio\packages\framework-arduinoespressif8266\tools\sdk\libc\xtensa-lx106-elf\include/machine/_default_types.h:17: Error: unknown opcode or format name 'typedef'
C:\Users\user\.platformio\packages\framework-arduinoespressif8266\tools\sdk\libc\xtensa-lx106-elf\include/machine/_default_types.h:30: Error: unknown opcode or format name 'typedef'
C:\Users\user\.platformio\packages\framework-arduinoespressif8266\tools\sdk\libc\xtensa-lx106-elf\include/machine/_default_types.h:33: Error: unknown opcode or format name 'typedef'
When I remove the -include "umm_malloc/umm_malloc_cfg.h" line, I get the following error
c:/users/user/.platformio/packages/toolchain-xtensa/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld.exe: .pio\build\esp8266\firmware.elf section `.text1' will not fit in region `iram1_0_seg'
collect2.exe: error: ld returned 1 exit status
*** [.pio\build\esp8266\firmware.elf] Error 1
But I guess that “umm_malloc_cfg.h” is meant to be allocating the IRAM correctly and is therefore required.
I have tried tracing the includes to figure out if one of them has a bug in them but it’s a bit of a maze.
It’s possible to generate map files with extra linker options (Generate a .map file - #8 by Krishna_Chaitanya) and analyze it (e.g. amap). You may be able to force a non-passing build (due to out of IRAM) to pass by artificially modifying the underlying linker file (C:\Users\<user>\.platformio\packages\framework-arduinoespressif32\tools\sdk\ld\esp32_out.ld and related) with hacked len = .. directives). Though I think it’s clear why the build doesn’t pass: .text1 in IRAM contains function code which has the ICACHE_RAM_ATTR attribute. The umm_malloc library does that with its functions to provide a higher execution speed than when it’s executed from flash. If there is other stuff (SDK, wifi, libs,…) using IRAM instruction code space, there may be an overflow.
Also, are you sure you’re on the latest package version for the Arduino-ESP8266 framework? Because it seems to me that above commits were targeted to fix those compilation problems. Check with pio platform update or in the VSCode GUI.
I could of course also be wrong and without that flag it will compile but not actually use umm_malloc…
Thanks heaps for your help. I’ll have a dig through but I do use a lot of built in libraries so I’m not sure how I’m going to fit everything in. I only have a couple of one line interrupt functiosn in IRAM so I don’t think there’s much I’ll be able to take out. Will definitely check out the map though and see if it points to anything.
And yeah, I’m at the latest for everything - I tried updating before asking the question, didn’t want it to be something silly like that haha
Any level really, just trying to find a reason why something in my code is acting strange. I’m getting webserver responses that only send partial responses sometimes… I’m using DDEBUG_ESP_OOM -include “umm_malloc/umm_malloc_cfg.h” and the compile errors are quite numerous.
Well that does work in my sketch as is. So I guess there’s just not an oom event happening. Now I’m trying poisoning the heap with -DUMM_POISON_CHECK. I’m guessing that’s not included in the ESP_OOM check anyway…
I’ve also noticed that the compilation failure is only occuring for the .S assembly files in the cores, which shouldn’t be compiled with the -include "umm_malloc/umm_malloc_cfg.h" anyways. But I’m also not yet sure on whether it will make a difference to not include it for all files or for all but this file in regards to correctly working umm_malloc things like poising checks. The minimal OOM example seems to work without it nicely after all.
Maybe you can setup a minimal example regarding out-of-memory through String concatination in the Arduino IDE and PlatformIO and see how the OOM detector behaves there? A simple loop with like
IIRC I shouldn’t have been using the -include “umm_malloc/umm_malloc_cfg.h” flag and when I didn’t have it, I was getting an unrelated error due to my program having a too high IRAM space requirement so basically I left that approach and debugged it a different way without using -DDEBUG_ESP_OOM.