ESP8266 Community Forum

Hello all

I need to generate and execute assembly code at runtime on my ESP8266 wemos D1 mini devboard, for real time reasons (I need it to be asm as it is runtime generated).

I wrote an example code to understand basics of the assembly instruction set (and used the ISA doc), then dumped the obj file using xtensa-lx106-elf-objdump.exe -S. Next step was to write the binary code inside a byte array (this is array is bound to contain runtime generated data in a future step). I then create a function pointer that points to this binary data and execute the function.

But when I do this, I get an exception each time the function is called.

Here is the exception contents (with decoder data):


_sendData calls _sendSingleLED and not millis, so I guess the call stack is wrong. _sendSingleLED calls my binary code, in this array :



First I thought this was a problem of endianess, so I inverted the bytes of every instruction, and I also tried to keep only the ret.i instruction. I actually don't know if the instruction fetch unit takes the bytes one my one (and thus I shall not use little endian) or not.

Also, I wonder if the issue is due to the fact my code is in a static region of the code, and need to be placed elsewhere so it can be executed (the PC register points to an invalid location, as the exception message may suggest)

I'll try coping the binary code in a dynamically allocated region and execute it from here to see if that fixes my problem (runtime generated code will be in heap memory anyways), while waiting for some help.

Does someone have an idea of what is actually wrong? Do you know documentation or information I may use to make this work? Thanks in advance!

OK, so I did some more research.

First, I did dump the obj file in both hexadecimal and asm code.
if I take a small funciton, i.e. _sendData, here is the asm code:


and here is the hexadecimal


We have some interesting information.
First, the function ends with a ret.n instruction (narrow return), as for every function. The asm code is f00d. If we look at the hexadecial code of this section, the 2 last bytes are 0df0. I can then conclude that the binary code is written in little endian. If we take a 24 bit instruction, like

the binary equivalent is "12c110", which confirms the endianness. We could think that pack of 4 bytes are displayed backwards (in little endian, but encoded opposite, visual studio memory window does that ), but in that case we would see the 2 first bytes of the 24 bit instruction at the beginning of the previous 4-byte section.
So : binary code is in little endian (this explains why part of the instruction op code is generally in the last 8 bits...)

And then, we have a 2nd very interesting piece of information to extract from this.
_sendData calls sendSingleLED. Let's have a look at the code that does the actual call:


First instruction write the address to call into a0, second instruction calls the function pointed by a0 (FYI, I read the ISA document, and it states that the CPU has "register files", which removes the need to push / pop registers to/from the stack before/after a call to another function, thus no such instruction here). Address of the function to call is... 4 bytes before the function entry point. Which is the 4 byte data right before the function in the same section:

WTF, the function to call would be at address zero? That makes no sense at all! And that's because I forgot an essential step of the binary building process : the link program! The link program's goal is to take all object files like the one I disassembled, and put them all together in the binary file. Once that's done (and only at that time), the linker will fill all the 0 in the data with the actual position of the function in the final binary file. When building the object file, the compiler has indeed no way to know where the function will be exactly in the binary file.
I guess that this processor does not use virtual address space (using MMUs), as modern CPU do, so we don't need to take other considerations we would need if working on e.g. Windows PCs.

Now, let's have a look at the disassembled binary (firmware.elf). Here is the section that contains our _sendData function:


Look at the call instruction:


callx0 has been replaced with just call0, and the actual address of _sendSingleLED is visible in the instruction parameter. Actually, this is a 18-bit relative address to the current instruction, making the instruction fit into 24 bits (the instructions must be 4 bytes aligned (e.g. 402014b8 for _sendData), as the documentation says).

Anyways, that's how it actually works. So now, let's have a look at our custom made binary function. Is it called properly ?

(see the 3 dots at the end? This is padding added to the binary so next function starts at a 4 byte aligned address.)

Whoops... this time there is no call0 instruction, but still the callx0...


function starts at 402014a4, and so 402014a0 is 4 bytes before, exactly as how it was in the object file. Like if the linker did not understand I would need to fetch the address of the binary data. This is not declared as a function, so the linker does not... well... link.

If we look at what's inside address 402014a0, we fall right after the end of another function (which one does not matter), that contains garbage (unsued data, I guess)

the 4 bytes at address 402014a0 contains the following data : cc85fe3f. This is indeed not a valid address, and this is why our call fails dramatically. I think I'll have to find a way, either to make our binary data be in a text section and considered as code, or to do a proper callx call to a dedicated heap memory space. 2nd option is the best one as the code I want to be executed will eventually be run-time generated.

If you have any idea on how to do this, I'm interested

P.S. If you read the whole post, you're a hero!

Hello again I'm glad to announce that I finally made it working !

I read the documentation further, and found the proto-code for the instruction fetch mechanism of the processor. This code taught me several things :
- the instruction data is fetched 32 bits per 32 bits (up to 64 bits in the internal memory)
- the manual says that the fetch may fail if the is an "attribute" change in the physical address within the 64 bytes after the instruction.
- the "attributes" of that memory may have had something to do with IRAM & DRAM (the ES8266 has 64KB of instruction RAM, and 98KB of data RAM).

Thus I tried to find if I could allocate memory in the IRAM instead of in the DRAM. And I found!

According to this page, there are several configurations possible for the IRAM block. One of them is about sharing an allocate-able heap in the IRAM section: "16KB cache + 48KB IRAM and 2nd Heap (shared)". This decreases the cache size (which would eventually lead to slower code execution from the flash chip), but provides ability to allocate into the IRAM.
With platform.IO (Visual code), you can enable this feature using a build flag in the platform.ini file:


As for allocation, the Arduino interface features a pair of classes to help with this :
HeapSelectIram and HeapSelectDram. Instanciate one of these classes, and you can allocate on the targeted heap (IRAM or DRAM, by default) during the scope of the declared class.

Here is my working code:


The HeapSelectIram class is instantiated within brackets, to force its scope to the malloc call only. The + 4 is to access the entry point of my function (after the 4 bytes of data). Also, notice that I add 64 bytes to the allocated memory, in case (I did not test without).

And the Serial.printf confirms that the allocation is done inside instruction memory:


401XXXXX memory space is indeed inside the IRAM section (see here)
Alloc is done at the same location, which means I correctly free my memory. Also many prints = many calls = no exception in the CPU!!!

Took me a long time, but I got it!