When the micropython program gets over 500 lines (students are coding a state machine to solve a sequence of challenges in a maze), several are now seeing the following error while using xrpcode.wpi.edu, typically for every run after the first run (sometimes on the first run):
XRPCode Development Environment
Waiting for connection…
MicroPython v1.25.0-preview.beta06 on 2025-02-17; SparkFun XRP Controller (Beta) with RP2040
Type “help()” for more information.
Traceback (most recent call last):
File “”, line 35, in
MemoryError: memory allocation failed, allocating 28416 bytes
The line referenced above is in main.py, not visible to students. My working theory is that the error occurs when the students’ micropython is being compiled.
Line 35 is: gc.collect().
When I run main.py or the students’ micropython from Thonny, I never see this problem. I think it’s due to the way main.py compile()s the micropython, then executing it – both using micropython, which consumes a bunch of memory.
Suggestions?
Thanks,
Kevin
Is it possible for you to send me one of the files to reproduce the problem?
The file eventually gets compiled as micropython only executes byte codes in the end. The reason we do that in our main file is that it gives better reporting of the location in your file when there is a stack trace.
My guess is that the main difference is that we have some code in there that is for the bluetooth connections that take up some space and buffers.
Thanks!
Code provided via IM. Let’s circle back when a proposal is ready.
If someone else wants to see the code that evokes the error, let me know.
OK. I sanitized a new version (for everyone). It runs correctly the first time, and gives the specified MemoryError on the second run. If I make it longer a bit longer, it throws the error even on the first attempt. The students have code that approaches a thousand lines.
Again, it works fine from Thonny (which makes sense, given @Fgrossman’s explanation above)..
Having looked at this. The problem is when the code itself is being read into memory be compiled. I see a change that we can make to improve the amount of memory at that time. We are doing that code after the compile right before the program runs. In the next release we can move that code.
For now since it sounded like you have an event tonight. Assuming these XRPs are being connected via a USB cable. You can after saving the file to the XRP, either “ctrl-s” or using the file menu, instead of hitting run in the terminal window you can press “ctrl-d”. This will cause the processor to reset and run the main.py that is set to run the last program that was run, still outputting any print statements. Since nothing else will be in memory at that time, all should run fine. Micropython does not disconnect the USB in this case, but with bluetooth it would be disconnected.
Another option that would help for most of the programs is that instead of from XRPLib.defaults import *, which imports all of the XRPLib into memory you can import just the libraries you need. This is what the blocks does, you can make a quick blocks program in use just setSpeed from the drivetrain and get_roll from the imu and then do a View Python and it will show you just the imports you need.
Thank you for sharing and hope this helps. Also we would love to hear more about the challenge you are running and how it goes.
Thanks a ton. With your suggestion, I was able to run the micropython. Question: How would I access the source code for the custom micropython build?
Since you asked: Our freshmen work in pairs to program, via micropython, the XRP robot to navigate a 3-room maze (built on 4’x8’ plywood), performing a series of tasks. They use the rangefinder, the IMU, and three sensors we added ourselves: infrared proximity on left and right sides, and a color sensor above the ultrasonic rangefinder. We require them to use a state-machine approach, with no blocking functions. Their state machine operates with a cycle-time of 20ms. In order to prove no blocking functions were used, they continuously output a message in morse code via the onboard LED. Navigation is performed the available sensors. After three attempts to get a good score we move to a single-elimination head-to-head races across the four mazes.
The media dept attended the XRP robot competition. If the University publishes a story, I’ll let you know.
Thanks again,
Kevin