MemoryError: memory allocation failed, allocating 175 bytes

[Marco den Hartog]

Hi all,

I have seen already a lot of forum topic regarding this issue. I think I forgot something or probably missing something.

I am trying to get a couple of sensors working in the LoPy but when adding the bme280 i have got the above message Looking around the forum I found out that I had to cross compile my code.

So I setup an Ubuntu 16.04LTS virtual machine, cloned all the code and compiled it and also the mpy-cross. After that I cross compiled the bme280.py and put the bme280.mpy in the /flash/lib directory. And of course deleted the original bme280.py.

But now I get the error ImportError: no module named 'bme280'. What can be the issue that my cross-compiled module is not picked up ?

[robert-hh]

@Marco-den-Hartog The reason is an omission in the last build. They forgot to enable the capability of running cross-compiled code from the file system. Try an older build, like 1.6.9b1.
by the way: Which code version are you using? The could does not look so large. It should load, at least on the newer builds.
If you can build you own image, be sure that the line:
#define MICROPY_PERSISTENT_CODE_LOAD (1)
is in mpconfigport.h. The most recent source on github is here, which is 1.6.9b1:
https://github.com/pycom/pycom-micropython-sigfox
Unfortunately, Pycom is very tardy on updating the repositories. They promised to get better, but......

[Marco den Hartog]

@robert-hh said in MemoryError: memory allocation failed, allocating 175 bytes:

forgot to enable the capability of running cross-compiled code from the file system. Try an older build, like 1.6.9b1.

Hi Robert,

I saw that one already. Forgot to mention it I am running on
(sysname='LoPy', nodename='LoPy', release='1.6.7.b1', version='v1.8.6-493-g99ac80fe on 2017-03-03', machine='LoPy with ESP32', lorawan='1.0.0')

[robert-hh]

@Marco-den-Hartog Persisten code load was officially enabled in 1.6.9.
If you build your own image, you can also put python code into the directory esp32/frozen. Then it will be compiled as part of the build process and placed into flash. That way, they consume much less RAM space.
You might run into trouble trying to flash from a virtual machine.

[Marco den Hartog]

@robert-hh Thx .... didn't see that it is was enabled in 1.6.9.

[robert-hh]

@Marco-den-Hartog Yes, and it disappeared in 1.6.12 again. If you want to go to 1.6.9 and not compile yourself, you can use the downgrade procedure., as discussed here-:
https://forum.pycom.io/topic/930/new-firmware-release-1-6-9-b1-frozen-code-support-and-framebuf
The 1.6.9.b1 image is here:
https://software.pycom.io/downloads/LoPy_868-1.6.9.b1.tar.gz or
https://software.pycom.io/downloads/LoPy_915-1.6.9.b1.tar.gz

[Marco den Hartog]

@robert-hh Thx I am going to try 1.6.9.b1 first and see if it is working. After that I want to try to build my own image. I managed to compile everything on the ubuntu server pycom-esp-idf, pycom-micropython/unix and xtensa-esp32-elf.

Don't know yet how to make an image from it. But learning a lot from all those nice posts about it.

[robert-hh]

@Marco-den-Hartog You just go into the esp32 subdirectory of microypython-pycom, and follow the instrutions in the README.md file there.

[Marco den Hartog]

@robert-hh Great I am going to try that.

[Marco den Hartog]

@robert-hh Hi I have tried image 1.6.9.b1 but when I put an .mpy cross compiled file in the lib directory or another directory it is complaining that it can't find the module ImportError: no module named 'bme280'. When I put the normal .py file there is no problem. Is image 1.6.9.b1 really supporting cross compiled files out of the box. Do you have another suggestion for me otherwise I need to compile everything and make my own image.

[robert-hh]

@Marco-den-Hartog Maybe it's not. I'm building the images myself since they were first published, and always added that config line myself. So I had pre-compiled and frozen code support before Pycom enabled it. It was in the code from the beginning on.
On a Linux machine, it's no problem to build the image. Only flashing it could be a problem, since USB support from a virtual machine was always fragile.
If that fails, you could use the manual procedure as written here: https://software.pycom.io/downloads/LoPy_868-1.6.0.b1.tar.gz
That would require to build your own gz-package, or you use the -f option. I never did that, but that's the way I would try.

[Marco den Hartog]

@robert-hh It isn't supported in that version. I am already busy building my own image with the specified config line. Only then I know for sure that it will work :)

[robert-hh]

@Marco-den-Hartog Once you get used to it, you don't want to miss it. That way, you can also put you own code into flash, and useful other scripts. It#s only a shame that PyCom updates the repository so tardy,

[Marco den Hartog]

@robert-hh You have a lot experience in manual compiling the source code. I am getting the following error on the end. I am using the following code
https://github.com/pycom/pycom-micropython-sigfox/blob/master/esp32/README.md
LINK build/LOPY/release/application.elf
text data bss dec hex filename
961873 170156 73056 1205085 12635d build/LOPY/release/application.elf
Building partitions from lib/partitions.csv...
Traceback (most recent call last):
File "/home/serveradmin/pycom-esp-idf/components/partition_table/gen_esp32part.py", line 356, in <module>
main()
File "/home/serveradmin/pycom-esp-idf/components/partition_table/gen_esp32part.py", line 345, in main
table.verify()
File "/home/serveradmin/pycom-esp-idf/components/partition_table/gen_esp32part.py", line 83, in verify
for p in sorted(self):
TypeError: unorderable types: PartitionDefinition() < PartitionDefinition()
application.mk:397: recipe for target 'build/LOPY/release/lib/partitions.bin' failed
make: *** [build/LOPY/release/lib/partitions.bin] Error 1

Do you know what I am missing here ?

I agree that it is a pitty that the code isnt't often updated in the github. That would be great if the guys of Pycom will do that more often.

Thx.

[robert-hh]

@Marco-den-Hartog I see now, that the second line in README looks wrong. so the make command should be:

make BOARD=LOPY -j5 TARGET=boot
make BOARD=LOPY -j5 TARGET=app

I personally use a GNUmakefile, in which I add the extra settings. It looks like:

BOARD = LOPY
$(info BOARD = $(BOARD))
FROZEN_MPY_DIR = modules
$(info FROZEN_MPY_DIR = $(FROZEN_MPY_DIR))
include Makefile

And then I either type (very rarely):
make TARGET=boot
or just:
make
and them
make flash
I tried to reproduce your error, but do not get it.

[robert-hh]

@Marco-den-Hartog Found it. It#s a python version problem.

try in the second make step:
make BOARD=LOPY -j5 TARGET=app PYTHON=python2
You need python2 installed for that.

[Marco den Hartog]

@robert-hh Thx a lot robert. Yes I am using python3 because in their readme file they say " MicroPython implements the entire Python 3.4 syntax (including exceptions, "with", "yield from", etc., and additionally "async" keyword from Python 3.5). I will switch over to python2 to see if that is working.

[Marco den Hartog]

@robert-hh Robert thx for pointing me in the right direction. I am able to compile the image. Play time.

[robert-hh]

@Marco-den-Hartog Micropython itself implements Version 3.4, but the scripts used in the build procedures on PC are a mix of Python2/Python3 code. For some branches you need Python2, for others Python3. for instance esptool.py was only recently Ported to Python3.