Harold Hallikainen wrote:
>> 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.
>   
We wrote a special application, which reads the data from a website and 
then sends it to the product.
> 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).
We used a tiny portion of it for something else. But the advantage is 
that you can acquire the new firmware
over time. For example, the radio modem can't accept more than 2048 
bytes at one time  (its time slot is
throttled back severely). So we do routine stuff, then send two firmware 
update packets. It might take a
day for the data to finally be pieced together. Another case might be 
the installation of tables for a huge
straingauge  function, such as  a crane.
>  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.
>   
I must tell you... it has happened, and yes, it turns it into a boat anchor.

--Bob A

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist