[Hunter Adams] has written a secondary bootloader for the RP2040 that uses an IR link and can be extended to behave like a polite worm virus. This allows the easy updating of a large cluster of co-located RP2040-based controllers. This could be handy in applications like swarm robotics or virtual cattle fencing. The project he demonstrates in the two videos ( below the break ) uses a pair of IR transmitters/receivers. But he purposely wrote the boot loader to be independent of the serial link, which could be infrared, radio, audio, or just wires.
Not only did [Hunter] make a boot loader, but he documented the entire boot process of the RP2040 chip. Whether or not you need a secondary bootloader, this is an excellent resource for understanding how the RP2040 responds to power cycling and resets. The boot loader code is available at his GitHub repository.
You may recall that [Hunter] is the lecturer of Cornell University’s Designing with Microcontroller classes, whom we’ve mentioned before. We’ve also covered some of his students’ projects as well, like these air drums and this CoreXY pen plotter.
“This could be handy in applications like swarm robotics or virtual cattle fencing.”
Virtual Fencing is cool, especially when used for herds of humans.
Here is a nifty online virtual cattle fencing cost calculator:
https://reuter.shinyapps.io/vfcostr/
“THX1138 has escaped!”
It would be interesting to see that used with some sort of swarm like mapping or associated learning algorithm. So each individual learns it’s surroundings and then uploads it to what would effectively be a shared map of which they all have their own copy. Effectively parallelizing the task of learning.
infrared is all well and good, but it’s not very good over long distances or bright light.
Thing kind of thing has been done for years with bluetooth on chipsets like the PIC, NRF, which offers a way to do the firmware flashing at higher speeds, farther distance and offers security benefits like built-in support of signed code (only permitting signed code to be passed to the bootloader), and “OTA” or A/B firmwares to fall back on.
examples —
PIC:
https://blog.flyingpic24.com/2015/08/04/blueboot/
Nordic:
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fug_nrfconnect_ble%2FUG%2FnRF_Connect_BLE%2FnRF_Connect_DFU.html
STM:
(STM32 OTA via an Arduino):
https://github.com/csnol/STM32-OTA
(STM32 OTA via Dev Kit)
https://embetronicx.com/tutorials/microcontrollers/stm32/bootloader/stm32-firmware-update-over-the-air-fota-wireless-firmware-update/
^ also contains a sample to STM32 OTA via Android apk.
TI
One that actually connects over wifi and grabs the latest firmware from a web address (quite complex) :
https://www.ti.com/lit/an/swra510b/swra510b.pdf?ts=1710679541863
SiLabs (OTA DFU):
https://docs.silabs.com/bluetooth/5.0/general/firmware-upgrade/secure-ota-dfu
Did RP2040 really not exist without this feature ? How is this new ?
Nah, it’s not that at all.
It’s a couple of things:
1) Most people casually exposed to microcontrollers these days and who perhaps take up hobby programming consider devices like the Pico, ESP32 devkits, and Arduinos to be “microcontrollers” despite being assemblies. This is all they know, and so things like this may show up in their feeds;
2) RP2040 is to Hackaday today as what “drones” or “quadcopters” were a few years back.
Unless it’s changed recently, there is no secure flash / boot process in the RP2040, by design. Adding encryption to a secondary bootloader for the RP2040 would be somewhat pointless, although there could be edge cases I’m not thinking of.
Outstanding documentation from Hunter Adams. It’s not only the project here; but also the high quality research done around the RP2040. All my kudos to Hunter’s research!
A self-propagating bootloader seems like one of those neat SHTF bootstrapping technologies that the permacomputing people would be all over. What am I failing to grasp?