.mpy files on LoPy 4

[iannucci]

I've tried using mpy-cross to create .mpy files for a LoPy 4. I am apparently doing several things wrong because I am getting "ValueError: invalid .mpy file" when I try to import one of these in MP. Please clarify:

(a) will v1.8.6-798-gebbcca48-dirty accept .mpy files? If not, how do I build firmware for LoPy 4 that will?
(b) which of the many mpy-cross versions available on various github repos actually generates proper code for LoPy 4? I develop on a Mac, so pre-built mpy-cross.exe's for Windows won't work for me.

Thanks.

Bob

[robert-hh]

@iannucci The OS you use to prebuild an .mpy file does not matter, because that is executed on the LOPY. You have to use the mpy-cross version from the respecitve repository. In this case https://github.com/pycom/pycom-micropython-sigfox/tree/master/mpy-cross. I did not check with the latest version whether .mpy files created with that build are compatible, but since creation of the mpy-cross executable uses the same modules as the final firmware, taht is very likele.
Do not use mpy-cross from other micropython repositories.

[iannucci]

@robert--, thanks for the fast response. I tried the repo you suggested and I was able to successfully create a simple test .mpy, upload it, and import it on a LoPy 4.

[as an aside, how would I have known to use a sigfox repo? Yes, the LoPy does sigfox, but it also does LoRa. So why bury this under sigfox?]

The next step in my quest is to import a larger .mpy -- I am able to create it and upload it, but when I import it, I get

MemoryError: memory allocation failed, allocating 56 bytes

(a) How can I track down the root cause of this error? (a common question, I might add)

(b) I am OK with building firmware. Can you suggest some parameters to change that might significantly increase the RAM available for Python?

[robert-hh]

@iannucci Yes, there were some comments already why the code resides under the sigfox tree.

If you are willing to build you own image, the you can save indeed a lot of RAM.
The first step would be to copy both the pycom micropython repository and the tailored pycom-esp-idf. Instructions are in the README of the python repository. It's quite a few steps, but doable.
Since you've built mpy-cross, you must have done a good part of that already.
Once you can build and upload a firmware image, you can embed your python code into the flash section of the firmware. That is done by just copying your source files (.py extentension) into the esp32/frozen directory and build the firmware then. mpy-cross is automatically called. The bytecode itself including static data will be placed into and executed form flash. RAM is only used for dynamic data.

P.S.: running out of RAM on LOPY4 is quite a surprise The code must be really big. If 2.5 Mbyte of heap space is not enough for the code (~ 25000 LOC), then you will also have trouble with frozen bytecode. Or you have lots of data.

[iannucci]

@robert-hh,

Thanks again for your help. I am still trying to narrow down the problem. I have ~900 LOC, nowhere near 25k LOC (see https://bitbucket.org/w6ei/miniircd ).

Here's what I get:

PYB: soft reboot
Loading...
Traceback (most recent call last):
File "main.py", line 37, in <module>
File "ircserver.py", line 27, in <module>
MemoryError: memory allocation failed, allocating 131 bytes
MicroPython v1.8.6-798-gebbcca48-dirty on 2017-10-31; LoPy4 with ESP32
Type "help()" for more information.

I need to debug this code before I go through the trouble of doing a custom build with frozen code.

Any ideas?

B

[robert-hh]

@iannucci said in .mpy files on LoPy 4:

File "ircserver.py", line 27, in <module>

I'm a little bit confused by this line and the link you gave: https://bitbucket.org/w6ei/miniircd

Line 31 is in this function:

def create_directory(path):
    if not os.path.isdir(path):
        os.makedirs(path)

Which uses methods of os which are not part of the pycom micropython lib. And that's where the error pops up. Did you embed your own extended os lib?

[iannucci]

@robert-hh

No, that's not the problem. Commenting this (and related code) out made no change.