OTA for micropython

[brianreinhold]

Being a complete novice on operations at this level I am not sure what I am flashing. In our case, we want to update (replace) the micropython firmware. Our application is built into the micropython firmware as we needed to do a lot of additional work to support client side Bluetooth pairing and service discovery persistence. We also convert BT device measurements to FHIR and upload them. The final Micropython firmware is about 1065 KB. Is this the right project to accomplish an OTA of this firmware?

[rhulme]

Hi,

I've never used MicroPython myself but I'm assuming when you talk about the MicroPython firmware in this context, you mean the code that implements MicroPython itself, rather than any Python application.

As you are building the firmware yourself, I see no reason why you couldn't incorporate the flashloader into your project.

First and foremost, you need to be able to make your code start from an address other than the start of flash (0x10000000) because that is where the flashloader will be.

At just over a megabyte, the firmware is quite large but as long as you have enough unused space on the flash chip to store a second copy, that isn't a problem itself.

I would also suggest you look at the 'urloader' branch if you haven't already as that gives you the possibility to perform a power-fail safe update of the flashloader code itself.

[brianreinhold]

Thanks for the info. The key here is that this OTA loader appears to be able to load firmware and not just an application running on existing firmware. I have a lot of learning to do and hopefully I will be able to use cellular instead of wireless. The PICO-W in this case sits on a six fab board with full cellular support.

[rhulme]

The flashloader (as presented here) doesn't care how the new firmware gets onto the chip. When it runs, it just expects to find the new firmware somewhere in flash so that it can then copy it over the existing firmware. So it's up to your existing application to download the new firmware by whatever means and store it.

What you certainly need to be on top of is what is placed where in flash. As I said, I've never used MicroPython but I've just had a quick look at the repository and the port for the RP2040. From what I can see, it reserves the last 1408KB of flash (unless defined otherwise) for (presumably) storing Python applications and anything else they need.

The linker script for the firmware defines the flash size as 2MB (i.e. it will allow the firmware itself to use up to 2MB).

If you're using a standard Pico-W board with 4MB of flash, that leaves you with about half a megabyte of guaranteed unused space, which is not enough for a second copy of the firmware.

So you can:

1. Reduce the space reserved for applications
2. Reduce the space reserved for the firmware (while still leaving enough space for the firmware to grow in future)
3. Make the flashloader able to download the new image and flash it bit by bit.

Option 3 is the only choice if there just not enough space to hold a second copy of the firmware but it adds risk as you don't already have the new firmware when you start the update (e.g. what happens if it has started to overwrite the existing application but can't get the full image for some reason?). It may well also increase the 'dead' time (i.e. the time taken to perform the update where the chip is not running the normal application). Depending on the use-case, that may or may not be an issue.

Option 3 also increases the complexity of the flashloader (probably not insignificantly) so then you will really want the option presented in the urloader branch of being able to update the flashloader too.

However you solve the problem, make sure that the various reserved areas are clearly defined and throw errors when building. It's much less stressful to deal with the firmware causing a build error because it's become larger than expected, than it is to deal with devices in the field getting bricked because (for example) the end of a downloaded firmware image has now overwritten the start of the area used for storing the Python application.

[brianreinhold]

It will take some work to get my thick head around it and get it to function, but it does indeed sound very promising!

I may have to ping you for some help but I will do my best to minimize that and try not to be too irritating.