Need the ability to reprogram the PIC24 processor remotely

[marknicolai192]

Hi all,

Hypothetical question. I've got a PIC24 in a system running great, and doing just what I need it to. It's connected via a modem to a web server that we've also created and all is hunky dory.

If I wanted to add to the system the ability to reprogram the processor remotely, what options do I have?

I do have a spare EEPROM space on the board - where potentially I could fit a 1Mbit I2C eeprom - if that is an option, although there is always the phobia of it not copying across the code right and failing.

Don't mind changing the board, don't mind adding a 2nd processor to do it.

Needs to be pretty bullet proof though.

Ideas on a postcard please.

Thanks alot

[Ttelmah]

This doesn't need a second processor, but does need careful code design:

Use a bootloader in the PIC, that reads a 'flag' byte at the end of the
EEPROM, and if it is set to a specific value, programs the PIC, and then clears
this flag.

Your 'main' code in the processor as one of it's functions, loads the EEPROM
with the required code. However it checksums everything being loaded, and
only sets the flag to the 'program' value, when it has received the entire
code without errors. At this point it sets the flag, and restarts the processor.

[asmallri]

The challenge with the approach of using the application to download the code is that if there is a bug in the application you bootload then you can't then bootload an updated image.

I generally prefer to put the intelligence into the bootloader as the bootloader always gets control on reset and would enable another application image to be downloaded.

The method Ttelmah suggested could be further enhanced if you stored two images into the external EEPROM. One image would be the identical image you ship the product with initially and the other image the one you want to download. You then need to implement some mechanism between the bootloader and the application such that the application sets a flag after some know event successfully completed. It has to be an event that proves both the EEPROM is readable and writable by the application and that it can reach the web server to download something successfully.

The bootloader, after x resets since download sees that the flag has never been set bootloads the original image.

Regards, Andrew
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

[Ttelmah]

Agree.

If enough storage is available, a 'backup' emergency recovery code copy
is a very sensible option. I did consider suggesting it, but decided to
KIS.
The key thing is making sure that the 'reprogram' flag cannot get set
unless the code is correct. Checksums on all blocks sent, but also on
the whole image.

[temtronic]

Yes, the feature of a 'protected original copy' of known working code in EEPROM is essential. You need a 'robust' bootloader that can ALWAYS be able to reload this 'protected original copy' should the download fail for any reason. One example would be a local power failure during an upgrade, another the ISP crashes. You also need some form of 'timer function' that if the download isn't done in say xx seconds, the download is aborted and the protected original copy is reloaded.
I'm sure there are lots of reasons a download can fail, so having an internal backup is 'mission critical.
With hardware being cheap these days , a bigger PIC AND huge EEPROM would be a wise investment. Cost is pennies compared to R&D time and unhappy clients 1/2 way around the World.

[Ttelmah]

The 'backup copy', is not quite as necessary in the system being suggested
here.

The key point is that the bootloader is independant of the code to store
the 'new' data.
So the running program contains the code to store the data. This checks
the data, and writes it to an external EEPROM (not to the chip). The code
writing this does a good quality checksum (so not just a simple
addition but a proper CRC). Only if the CRC of the data stored into the
EEPROM matches what the sending program says it should be, does it
set the 'flag' to say to the bootloader 'write this'.
Since the flag cannot get set unless the code is completely/correctly
stored in the EEPROM, programming cannot be triggered until the data
is valid.
The bootloader only turns the flag 'off', when it has successfully writen
this to the chip. So until this happens it'll repeatedly be called if the
load is interrupted.