[sdiy] a provoking question about time
brianw at audiobanshee.com
Sun Jun 26 21:54:52 CEST 2022
Another issue to think about with regard to re-programming Flash in the field is that you really need a bootloader to make this safe.
A bootloader is typically stored in ROM inside the CPU, and is capable of reading at least two alternate boot images. If one firmware image is corrupted due to power loss during programming, the other image will still boot. Once booted, the user can re-attempt the firmware upgrade and hope that power won't be interrupted. Some bootloaders use dual devices so that the backup device is not being erased while the updated device is being upgraded.
I've seen products with three levels of boot. The first bootloader cannot be changed in the field without special hardware. The second bootloader can be upgraded by the first bootloader, in case bugs are found in the second bootloader. The third boot stage is the actual firmware for the product. This degree of bootloader may only be necessary for chips that do not have a first-stage bootloader in ROM. In the example I'm thinking of, there actually wasn't a CPU, but an FPGA with a virtual processor, so that probably complicated the bootloader immensely.
It's a little more difficult to do a full bootloader with a PIC, since everything is in the same on-board Flash device. There are examples, though, where a region of Flash is designated as read-only, but that doesn't help with the issue of bit rot. I've done a lot of design work with PIC bootloaders, but never in a way that actually addressed bit rot (or the 'fuse' area).
If longevity is crucial, then you probably have to select a CPU with a ROM bootloader. That way, the only part of the firmware that doesn't get updated is also not going to ever fail due to bit rot. This class of CPU chips usually boot from an external device, and then you probably have the option of High Reliability (eMMC) technologies that alleviate bit rot.
More information about the Synth-diy