Esp32 dfu micropython

Firmware
#1

Are there any examples or recommendations for how to manage dfu if using micropython framework on esp32 with notecard? We are just getting into micropython and are not fully versed in the whole platform yet, but understand there may be two items here to consider.

  1. need to udpate the micropython firmware binary which is fairly large, but this should hopefully not be required often or at all over the life of a product.
  2. need to update the application firmware .py files to add features and fix potential bugs over time. These files should be fairly small.

Any guidance you can provide is appreciated!
Ed

#2

Hey @ec123 great question! This is actually something I have considered myself with MicroPython/CircuitPython-based projects, but I’ve not had a chance to look into it, nor can I really provide any guidance at this point in terms of official documentation.

But I can say that I think this would absolutely be possible, but you’d need to do the following:

  1. For updating MicroPython itself: Create a bootloader in C++ to manage retrieving a MicroPython binary from the Notecard/Notehub and applying it to the appropriate partition. This would be similar to our ESP32 DFU example, but would likely require some additional investigation or extension of another ESP32-based MicroPython bootloader. You may also need to build MicroPython yourself if the process would requires a binary not a UF2. I am not versed in UF2 internals, so it may be in itself a sufficient binary to direct write to an ESP32 partition.
  2. For updating a .py file: Extend the C++ bootloader to retrieve the file from the Notecard and write the file to the correct location on the ESP32s internal filesystem. I think our DFU process would work with this, but I have not tested this myself, so I can’t promise that it will.

Either way, what you’re looking for should be possible, but might require a bit of heavy-lifting to get set-up on the ESP32 side of things.

I hope that helps, and if you do decide to give it a try, let me know how it goes, and if we can help in any way!

#3

Are you saying it is possible to send .py (text) files directly through DFU? If so, how could that work? Can you send multiple files, can you put the required meta-data directly into a .py comment? Do you have to .zip it and decompress once it arrives on the host? Any suggestions are appreciated.

1 Like
#4

Hey @ec123 It’s possible in the sense that Notehub will allow you to upload Python files as “firmware” and should be able to deliver a file or zip of files to the host through the Notecard. But again, I’ve not tested this myself and I can’t really describe the process for what you’d need to do on the host side. If you’re keen to try it out, I’d love to hear how it goes and if you run into any roadblocks.

#5

I was digging through some other forum posts and found this reference for notecard DFU size:

Memory Size of Host Firmware - If you are referring to the STM32 processor on the Notecard, that codespace is not developer-accessible, so we don’t disclose the size of the main firmware. If you’re referring to the size of a MCU Host binary that can be downloaded from Notehub to the Notecard, the limit is approx. 700KB.

For the ESP32, micropython binary esp32-idf3-20210202-v1.14 is pretty large, showing 1.3Mbytes when downloaded 1.37 MB (1,445,888 bytes). Is this a show stopper because its 2x larger than the notecard DFU memory, or is there some way to split it into chunks and re-assemble when it get to the host MCU? Also, is notehub’s host MCU firmware system setup to handle this automatically, or would it require some sort of custom solution?

#6

Ah yes, that’s right. The core MicroPy binary is too large. I suppose you could theoretically split the binary into two, but the process of splitting, storing and reassembling the binary would require a custom solution on your part. The Notehub only has a concept of a single host binary that is versioned, so you’d need to figure out how to deal with managing the split binary version numbers.

This is definitely pushing the boundaries of how Host DFU is currently designed, but you are doing something that I would be keen to see us support with both MicroPython and CircuitPython at some point in the future, so please keep the questions coming!