ESP8266 "Error: unknown opcode or format name" when compiling with -include "umm_malloc/umm_malloc_cfg.h"

1

When I compile with:

    build_flags =
      -DDEBUG_BUILD
      -DWEBSOCKET_DISABLED
      -DDEBUG_ESP_OOM
      -include "umm_malloc/umm_malloc_cfg.h"

I have followed the instructions at https://docs.platformio.org/en/latest/platforms/espressif8266.html#debug-level to set the debug level.

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'
Compiling .pio\build\esp8266\FrameworkArduino\core_esp8266_app_entry_noextra4k.cpp.o
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'
Compiling .pio\build\esp8266\FrameworkArduino\core_esp8266_eboot_command.cpp.o
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

Linking .pio\build\esp8266\firmware.elf
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.

2

Does this also occur with a very simple firmware?

The way I see it, umm_malloc.h is included which already includes the config.

3

Brilliant, thanks for that. With a minimal blink project, it looks like when it’s passed as an include to gcc it gets this error but otherwise it compiles fine.

Looks like I will need to find what’s taking up all the space and trim it out.

So why does https://docs.platformio.org/en/latest/platforms/espressif8266.html#debug-level say that it’s required as a build_flag?

4

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.

At the time the documentation was written it may have been required. Some later commits (Update core with upstream umm_malloc (#6438) · esp8266/Arduino@7a43092 · GitHub) definitely changed something regarding the typedef errors you are receiving.

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…

5

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

6

@majs_man Did you ever figure out how to get this working? I’m having the same issue…

7

What do you want to achieve, high-level?

8

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.

9

And without this flag it will compile but show no info?

10

That’s right, without the include “umm_malloc/umm_malloc_cgf.h” it compiles fine but just doesn’t appear to show any OOM debug info…

11

But this definitely works without the -include and just the right build flags. Given the platformio.ini

[env:nodemcuv2]
platform = espressif8266
board = nodemcuv2
framework = arduino
monitor_speed = 74880
build_flags =
   -DDEBUG_ESP_PORT=Serial
   -DDEBUG_ESP_OOM

and code

#include <Arduino.h>

void setup() {
  delay(1000);
  Serial.begin(74880);
  Serial.println("Testing out-of-memory...");
}

void loop() {
   Serial.println("Mallocing 5K.."); Serial.flush();
   void* ptr = malloc(5 * 1024);
   Serial.print("Alloced ptr "); Serial.println((unsigned int) ptr, HEX);
   Serial.print("Now free: " );
   Serial.println(ESP.getFreeHeap());
   if(ptr == nullptr) {
        Serial.println("malloc() returned NULL!! Ran out of memory");
        delay(10000); //"halt"
   }
}

which provokes a memory leak / out-of-memory, the final lines of the output are…

Now free: 712
Mallocing 5K..
:oom(5120)@main.cpp:11
Alloced ptr 0

and then :oom(5120)@main.cpp:11 perfectly encodes the amount of wanted memory (5KBytes) and the line in which the out-of-memory occured.

And this doesn’t have any special #include <umm_malloc/umm_malloc_cfg.h> in the code to hook the malloc functions.

Can you verify the above minimal example works for you too?

12

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…

13

This documentation issue is now tracked in Espressif8266 OOM docs wrong · Issue #225 · platformio/platformio-docs · GitHub.

I have not yet had a play with the poison check.

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

#include <Arduino.h>
void setup() { Serial.begin(115200); }
String globString = "";
void loop() { 
   globString += "aaaaaaaaaaaaaaaaaaa"; 
   Serial.print("Len is now: "); 
   Serial.println(globString.length());
}

should do the trick.

14

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.