Searching \ for '[PIC] Re: Boot loader?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Re: Boot loader?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Re: Boot loader?'
2008\04\10@123630 by Harold Hallikainen

face
flavicon
face

{Quote hidden}

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!

2008\04\10@130621 by Bob Axtell

face picon face
Harold Hallikainen wrote:
{Quote hidden}

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

2008\04\10@131807 by Bob Axtell

face picon face
Harold Hallikainen wrote:
{Quote hidden}

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
{Quote hidden}

More... (looser matching)
- Last day of these posts
- In 2008 , 2009 only
- Today
- New search...