-
Notifications
You must be signed in to change notification settings - Fork 911
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Over The Air" updates for Pico-w #4341
Comments
Notes to self (just gathering potentially helpful stuff) https://forums.raspberrypi.com/viewtopic.php?t=322858 This is starting to look very non-trivial Wondering about using a mem-copy, or possibly DMA to (re)place the running image (unpacked from a UF2/elf file).. A watchdog timer could be set, prior to the copy to reboot the device when it (inevitably) crashes (but hopefully by the the copy would have completed) https://www.raspberrypi.com/documentation/pico-sdk/hardware.html#flash_example |
ESPhome has a support for both OTA updates and RP2040 - you could take a look how they are doing it:
IMO for a reliable solution, this would require some sort of bootloader and A/B partitions switchover 🤔 |
Thanks… will check it.
There are a few C solutions out there, some look very robust.. I was
looking at something much simpler with a smaller footprint, thinking there
might be a way to live very dangerously and overwrite the program that is
executing in a single memcopy, rebooting with a watchdog timer.
Perhaps it’s better to forget such a terrible idea and put the effort into
something more robust and resilient, it would be nice if it was all GO
though.
…On Wed, 17 Jul 2024 at 14:03, Piotr Bocheński ***@***.***> wrote:
ESPhome has a support for both OTA updates and RP2040 - you could take a
look how they are doing it:
1. https://esphome.io/components/ota
2. https://esphome.io/components/safe_mode
3. https://esphome.io/components/rp2040
IMO for a reliable solution, this would require some sort of bootloader
and A/B partitions switchover 🤔
—
Reply to this email directly, view it on GitHub
<#4341 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALR2VA342PTV4RTAWSMBX4DZMZTSTAVCNFSM6AAAAABK677XBKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZTGI3TEOBZG4>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Hi Chaps
With some direction from Patricio, I have implemented the UDP stack in seqs.. I can now pull binary files with a naïve, "reliable" protocol on top. (Yes, I know I could have done that with TCP !).
I made it for camera images, but the next challenge is to be able to update the running program - I'm not sure I need anything as complex as a bootloader - if I can get a new .ELF (or UF2) file onto the Pico, and invoke machine.CPUReset() ... ??
I also just discovered machine.BlockDevice
I'm sure this is not as straightforward as I am hoping, but I'd welcome any pointers.
Is self-updating for TinyGo apps already elsewhere on the radar ?
My needs are simple, it doesn't need to be totally robust or secure, bricking a Pico would just mean a short drive - but I could perhaps explore a Proof of Concept that might develop into something more universally useful.
The text was updated successfully, but these errors were encountered: