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.
>   
I convert the intel hex into actual raw word data, then the encryptor 
performs simple actions, such as
adding "spurious" words, swapping many words, then shifting words. THEN, 
the data stack is transferred.

On the PIC end,  I perform  the inverse functions as I store the data 
into the EEPROM. To make sure there
is no problem, a CRC16 is performed. If anything is suspect, the whole 
data set is tossed.

--Bob A
> 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
>
>
>   

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