Problems when appending scripts to recent runtime

[bmustill-rose]

uFlash 1.0.8 appears to be incorrectly appending scripts to a runtime that I'm supplying which is based on the latest commit (f682113) of MicroPython.

• I have compiled an unmodified runtime of MicroPython using the above referenced commit.
• Flashing my runtime to the device without a script and carrying out some brief tests suggests that it's working properly - E.G. display, buttons, speech and radio all work.
• Using uFlash to flash any script and supplying my runtime results in the device seemingly doing nothing. The script is not executed, nothing is printed to serial & I am unable to access the REPL.
• Using uFlash to flash a script without specifying a runtime works.
• Using uFlash to flash a script using an older runtime such as https://github.com/ntoll/microrepl/blob/master/firmware.hex works.
• If I flash my runtime, rename my script to main.py and \"put\" it on the device using microfs it works - E.G. the script executes on boot, behaves as I would expect it to & I'm able to access the REPL.

mp.zip

Please see attached for my runtime. For what it's worth it was compiled under Windows 10 X64 which I realize might not be a typical build environment. Apologies if the issue in fact turns out to be related to my runtime as opposed to uFlash.

[carlosperate]

That's a bit weird, you've attached the Hex file compiled with only MicroPython. Could you also attach the Python code you are using and the output Hex created with when combined (you can give it a normal directory as the "micro:bit path" and will copy the file there).

[bmustill-rose]

Please see the attached. Thanks for your help. files.zip

[carlosperate]

That is a bit odd, uFlash is correctly encoding and attaching the script:

:020000040003F7
:10E000004D500E007072696E74282268656C6C6FDA
:10E0100022290000000000000000000000000000B5

That's the right address and magic characters to indicate the start of the Python script and byte count. The text on its own is:

70 72 69 6E 74 28 22 68 65 6C 6C 6F 22 29 = print("hello")

But when flashing the combined file it does indeed not give you the repl.

As a quick note the print() function prints to the serial port, so it'd be a better test to see if this would scroll any text on the micro:bit display:

from microbit import *
display.scroll("hello")

But using that script instead doesn't work either. Something funny is happening with your runtime, not sure what though.

One thing I've noticed is that flashing your hex files takes a bit longer than normal, I wonder if DAPLink is failing to flash at some point through the transfer in a way that only breaks completely when there is a python script.

[carlosperate]

Nope, I've extracted the flash contents and the runtime and script are all correctly flashed (although there was the weirdest bit flip at address 0x0003_FC00, but it's too far down the memory space to do anything).

I can only guess is something to do with the runtime, because the filesystem with main.py file works, perhaps a code-path only exercised when a script is found at address 0x0003_E000? What did you change in the runtime?

[bmustill-rose]

Knowingly, nothing. I'll do some more testing & report back if I find anything. Thanks.

[ntoll]

Folks, given this may be a problem with the runtime, it may be better to give this more visibility by posting a ticket to the microbit-micropython repository (the one for the runtime).

[bmustill-rose]

Raised https://github.com/bbcmicrobit/micropython/issues/440

[markshannon]

See bbcmicrobit/micropython#440 for diagnosis.

A possible fix for µflash is to store the script in the filesystem under the name "__main__.py".