> I write bootloaders, too. So far, they all are embedded (part of the
> operation of the product itself, i.e.
> it uses the UART and certain commands activate the bootloader). The
> objection I have to doing the
> Intel Hex bit is that it is easy for the data to be trapped and the
> firmware stolen by a competitor.
>
> To reduce corruption, I install a bridge in the first 16 words that is
> "permanent" until the new data is
> installed correctly, then the bridge is replaced with the correct bit.
> During the update, normal operation
> of the product is suspended, and only the firmware installer runs.
>
> My new firmware is installed into a serial EEPROM temporarily, and the
> transferred data is encrypted
> for the transfer step, and decrypted while being installed. Once CRC
> checks are done on the serial EEPROM,
> then the update process begins.
>
> --Bob A


Interesting! I wonder if there's some simple encrypter the Intel hex file
could be run through, then decrypted within the PIC bootloader. The
decrypter would just be stuck between the bootloader and the uart GetChar
routine. Otherwise everything else would be the same.

Your buffering the encrypted data on the serial eeprom is interesting. It
does allow an error check to be done prior to starting to flash the PIC
with bad code. It does take another part (unless you already need the
serial eeprom for something else). Can't the bootload host application
verify the integrity of the new firmware before starting the bootload? If
so, it seems that if we manage to corrupt the data on the way to PIC
flash, we do end up with corrupt code in the PIC, but we'd know about it
and could try again. It does not seem that we'd turn the product into a
brick.

Thanks for the comments!

Harold


-- 
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist