[sdiy] a provoking question about time
jschwich53 at comcast.net
Sun Jun 26 22:41:58 CEST 2022
On the ICD3 cost I'd probably say that they were hobbyists or amateurs
just being cheap and not doing real commercial work. I find it pretty
funny reading about people buying 2-3 cheap programmers that don't work
spending more money than the proper one.
Brian's other info is pretty good.
Couple of other things.
A number of projects I've worked on include enough Flash for dual
images. Usually you program the new image into the unused memory space,
validate it and then switch the boot pointer to it. Normally you
wouldn't do this to the bootloader, hopefully you coded it good enough
but have also used the previous technique for them too.
If you are doing a critical system or secure system you will have to go
above and beyond to deal with those issues.
Question to ask also is the technology to update the firmware going to
exist in 20 years and I'm including USB in that statement?
On 6/26/2022 12:54 PM, brianw wrote:
Brian W said some valid points about proper programmer and robust eMMC.
Why would you assume that I'm not using ICD3 (and ICD2 before that)?
Last time I brought up the topic of ICD3 in a random online forum, some people were violently opposed to spending $300 on a programmer. I must have been hanging out in the wrong online fora. I just thought it was important to stress the use of proper programming tools in case folks were only familiar with the cheap debugger/programmers. Nothing personal !
> 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.
> Synth-diy mailing list
> Synth-diy at synth-diy.org
> Selling or trading? Use marketplace at synth-diy.org
More information about the Synth-diy