Adding Frozen Modules causes a region to overflow

All ESP8266 boards running MicroPython.
Official boards are the Adafruit Huzzah and Feather boards.
Target audience: MicroPython users with an ESP8266 board.
Post Reply
cefn
Posts: 230
Joined: Tue Aug 09, 2016 10:58 am

Adding Frozen Modules causes a region to overflow

Post by cefn » Sat Apr 15, 2017 1:40 am

I'm having a difficulty putting Frozen Modules into program memory. I'm trying to do this to minimise the RAM used by my project, which is heavily skewed towards text data.

```
LINK build/firmware.elf
xtensa-lx106-elf-ld: build/firmware.elf section `.irom0.text' will not fit in region `irom0_0_seg'
xtensa-lx106-elf-ld: region `irom0_0_seg' overflowed by 13028 bytes
Makefile:193: recipe for target 'build/firmware.elf' failed
make: *** [build/firmware.elf] Error 1
```

I can create an unmodified firmware-combined.bin and successfully flash it. However, if I add my few extra python files into modules before creating the firmware, (using --- make clean; make axtls; make --- from within the esp8266 folder) I end up with the error above.

Is it possible to adjust the allocation of memory made to that specific region? Alternatively is there something else I'm doing wrong which is causing the overflow? There's a lot of text strings in my source.

I understand that I have quite a bit of space available in principle within the Program Memory on the NodeMCU, if I can keep data structures out of RAM, but I wonder whether the way the firmware routine normally runs tries to keep everything within 512b, suitable for an ESP-01. If so, what parameter can I change to let the environment know that there is actually more space available.

The code I am trying to add to the firmware image are the top level .py files in https://github.com/cefn/avatap/tree/master/python, which define the logic engine for the text adventure, and at least one of the stories .py files which represent the content of a single adventure, such as https://github.com/cefn/avatap/blob/mas ... rbridge.py

BACKGROUND

I am trying to use a NodeMCUv2 to run simple text adventures. Players will have an RFID card to identify themselves, and the text will appear on a ST7920-driven 128x64 pixel screen. For this purpose I have developed and tested a ST7920 driver ( see https://github.com/ShrimpingIt/micropython-st7920 ) and ported many pixel fonts too ( see https://github.com/ShrimpingIt/bitfont ) which will hopefully be useful resources for the community. I am taking advantage of the work by pfalcon on utemplate to be able to author simple iteraction and conditional logic within text templates.

I've put together and debugged the project first in 'emulation', in python3 via PyCharm. However, throughout the process I was testing stable snapshots in parallel in the unix port of micropython, keeping a close eye on the memory and peak memory reported by micropython.mem_info() but even when the unix port was reporting < 60000 bytes peak RAM usage, it turned out I was getting memory errors when I try to run the same on the NodeMCU with Micropython 1.8.7.

For this reason I first created bytecode using mpy-cross. This was an attempt to mitigate the problem by avoiding the memory overhead of compiling, but only helped me get the first few libraries loaded, I still had a memory shortfall for loading and running everything assuming things were loaded into RAM from the filesystem.

I then worked on creating my own firmware image, populating the micropython/esp8266/modules folder with my modules, and expecting them to be added to the firmware-combined.bin. However, this was the point at which I have an issue that the frozen modules I'm adding are causing some memory allocation region to overflow.

I am actively rewriting chunks of the code to be more memory and CPU-efficient in any case, but solving this issue would be a great help.

cefn
Posts: 230
Joined: Tue Aug 09, 2016 10:58 am

Re: Adding Frozen Modules causes a region to overflow

Post by cefn » Mon Apr 17, 2017 1:12 am

I figured it out!

No idea why I couldn't find these resources the first time I searched. I think I was including too much of the error message.

In the end, just searching for .irom0.text got me to finding out more about the issue, then I discovered there were .ld files, and finally that there was an esp8266.ld file at micropython/esp8266/esp8266.ld (the eagle ones within the esp-open-sdk repo I was originally looking at were a red herring).

This was the key thread for me to start to solve the problem... viewtopic.php?t=2801

Finally https://github.com/micropython/micropyt ... -287737238 provided changes to the micropython esp8266 build configuration which actually resolved the problem. It's slightly black magic for me right now, as I don't know how the numbers were arrived at, or whether there could be a collision as warned at https://github.com/micropython/micropyt ... -267944635 but it's a huge start!

Post Reply