Hello,
I’m trying to update my host MCU firmware (Swan running CircuitPython) over-the-air using the Notecard’s outboard DFU, but I keep running into issues where the host MCU never comes back up properly leading me to manually re-flash everything to so I can try again.
Here’s what works so far:
-
I can manually flash the Swan using dfu-util (TinyUF2 + CircuitPython).
-
CircuitPython runs fine, and I can mount CIRCUITPY, copy my code, and run it without issues.
-
I can also build and apply a scripts.cpy using circuitpython-fs-builder after getting virtual env setup I run cpy-fs src/ src/scripts.cpy and can verify my codes in there.
-
I have build and tried all 3 variations of a binpack file…
- 3-part-image:
notecard -binpack stm32 0x8000000:tinyuf2-swan_r5.bin 0x8010000:adafruit-circuitpython-swan_r5-en_US-10.0.3.bin 0x8100000:scripts.cpy
- 2-part-image:
notecard -binpack stm32 0x8010000:adafruit-circuitpython-swan_r5-en_US-10.0.3.bin 0x8100000:scripts.cpy (note the official guide mentions a suffix of -nobootloader.bin for circuitpython, but I cant find that bin file anywhere online?)
- 1-part-image “scripts only”:
notecard -binpack stm32 0x8100000:scripts.cpy
-
I can get my Notecard to enter DFU mode and successfully download from Notehub and start the process.
Where things go wrong:
- The 3 part and 2 part image result in this error message
outboard DFU of stm32 firmware: can't initiate chip erase: send command 44 timeout in the _health.qo text after the download
- The 1 part, script only image, downloads super fast, unmounts the MCU and it never comes back up. However, if I re-flash tinyuf2 and circuitpython (by dragging a uf2 file over), it all comes back up and my new firmware is there! Meaning writing to this address
0x8100000 worked!
My setup:
- Blues Swan on a Notecarrier-F
- Notecard 8.x LTS firmware
- OTA .binpack built as either 1-part (scripts), 2-part (CircuitPython + scripts) or 3-part (TinyUF2 + CP + scripts)
Has anyone managed to get a reliable OTA update process working for CircuitPython on Swan using Notecard DFU?
Any examples, tips, or best practices, I feel like I must be missing something in the docs? Thank you.
Hi @chasez0r
Thanks for your patience, I’m looking into this for you. In the meantime, something you can try to iterate on the OTA is to use the -sideload feature of Notecard CLI to place your circuitpython image onto the Notecard for use with ODFU. This is effectively the same mechanism that takes place when the Notecard receives your OTA image but without costing you data and events to send the image over Notehub.
Thanks,
Alex
Thanks for the response. I will look into doing this locally with the sideload flag, maybe that will shed more light onto the issue. Let me know if anything else comes to mind. Thanks!
I keep getting this error when trying to -sideload dfu.put: dfu: cannot sideload on top of notehub-loaded firmware
I have even run notecard -format and then got the same results after. There arent any docs I can find on the use of -sideload so any advice would be appreciated.
Full output after running -sideload
placing notecard into DFU mode so that we can send file to its external flash storage
waiting for notecard to power-up the external storage
sending DFU binary to notecard
restoring notecard so that it is no longer in DFU mode
dfu.put: dfu: cannot sideload on top of notehub-loaded firmware
Hi @chasez0r
I’m still looking into this for you, the circuitpython-fs-builder seems to be missing some documentation, so I’m trying to make sure that you’re building the firmware correctly.
On the issue of -sideload , for development purposes, I think the best option is to first remove the OTA firmware from Notehub and then use card.restore command to reset Notecard’s filesystem and force a re-sync with Notehub. This should hopefully drop the old firmware image from the Notecard’s flash. This is specifically what the dfu.put: dfu: cannot sideload on top of notehub-loaded firmware error is referring to.
{
"req": "card.restore"
}
Thanks,
Alex
Thanks, im still stuck any insights are appreciated!
Hi @chasez0r
Apologies for the delay, it seems like something has changed upstream with how the CircuitPython image is being generated as it’s advanced a few years on from when this process was originally designed. The issue appears to be rooted in the CircuitPython image and how it is being built. Thanks for your patience!
Do you know which CircuitPython last worked with the current build process? I am happy to revert to an older version to try.