Flashing with custom micropython is not working

[Dainerx]

Using this command: uflash -r custom_runtime.hex my_script.py (1) I've tried to flash microbit using a custom runtime hex file you I created instead of the built in hex.

Microbit gets flashed but does not run my script. At first I thought there's something wrong with my custom runtime hex file, but then I tried with bbcmicrobit/micropython. I built the frimware hex following their documentation, tried to flash microbit uflash -r microbit-micropython.hex my_script.py (2), no results.

Finally my last attempt was to run the same command but this time using the already built in hex file. uflash -r built-in.hex my_script.py (3), works like a charm.

I'm wondering the reasons behind (3) working and not (1) & (2). Is uflash capable of only embedding scripts with the already built in run time hex?

[carlosperate]

Hi @Dainerx,

uFlash should be working with any hex file. The fact that it worked with the firmware.hex file points that perhaps there is something wrong with the other hex files. As it would be doing the same this independently of what is inside the hex.

If you flash the hex that failed to the micro:bit via copy and paste on the USB drive, can you access the MicroPython REPL?

Do you have any hex files we can use to replicate your issue?

[Dainerx]

Hi @carlosperate ,

The hex file if flashed, does indeed grant access to REPL but it is not possible to embed a script to it. I've come to conclude that only the built in hex works if you are trying to embed a script.

While I solved this, this is in my opinion where the problem comes from: slicing the last 5 lines instead of the last two?

    # The embedded list should be the original runtime with the Python based
    # hex embedded two lines from the end.
    embedded_list.extend(runtime_list[:-5])
    embedded_list.extend(py_list)
    embedded_list.extend(runtime_list[-5:])

I looked up online if there is a fixed insertion point for my hexlified script in every hex file. Indeed just like the comment says of the above piece of code

two lines from the end

I'm not very familiar with Python so I wrote my solution in JavaScript inspired by open source code I found online.

    const HEX_INSERTION_POINT = ":::::::::::::::::::::::::::::::::::::::::::\n";
    /**
     * Removes the old insertion line the input Intel Hex string contains it.
     * @param {string} intelHexStr String with the intel hex lines.
     * @return {string} The Intel Hex string without insertion line.
     */
    function cleanseOldHexFormat(intelHexStr) {
        return intelHexStr.replace(HEX_INSERTION_POINT, '');
    }

The five last lines of my custom hex file:

:10AF5000BD13000025A800006931010071610100E6
:10AF6000496301009963010009890100C1000000E3
:::::::::::::::::::::::::::::::::::::::::::
:0400000500018E9DCB
:00000001FF`;

This worked. We are using this feature on our microbit platform to support frozen custom python modules.

---

Hex file used upon opening this issue.

[carlosperate]

I see, how are you building the micro:bit port of MicroPython? Are you using the Makefile?

Any v1.0 builds should include a UICR section at the end of the hex file, which is why it was slicing the last 5 lines instead of 2.

https://github.com/ntoll/uflash/blob/867468d386da0aa20212b69a152ce8bfc0972366/firmware.hex#L14481-L14483

[Dainerx]

I built following the steps on the README file of bbcmicrobit micropython repository master branch.

Any v1.0 builds should include a UICR section at the end of the hex file, which is why it was slicing the last 5 lines instead of 2.

I see! Makes sense, thank you. I guess this should be closed.

[carlosperate]

We could update uFlash to check the bottom 5 lines and that way figure out where to inject the Python code. If it finds a :020000041000EA it should add it before that line, otherwise, before a line that starts with :04000005, and if that doesn't exists either before the end-of-file record :00000001FF.

If you like to submit a PR I'd be happy to review it.

[Dainerx]

Done, although I could not assign you as reviewer.