Steve Lauziere wrote:

>I am curious if anyone has a unique or novel method for updating a 
>flash-based pic in the field.
>  
>
It is not unique, but it is military-reliable.

>A basic requirement is that this update has to survive interruption, 
>such as power-off during programming.  So probably, I would have some 
>sort of logic level output for a watchdog signal.  I would then try 
>programming again if there was a failure.
>  
>
I may not understand what you mean. If you are using a medium-range or 18F
processor, you should be able to upgrade through the device's UART (serial)
port. This only works for devices that are able to program their own 
internal
program space; these include F876, F877, F88, many others now.

I performed some consulting, studying what is realistically possible in 
the field.
I found that the very best field upgrade schemes use a kind of 
"customer-based"
serial port upgrade, because that simply expands the use of an item that the
client is already familiar with. Making the customer use the standard 
ICSP scheme-
even with a polarized connector-  is a disaster, unless the customer is VERY
electronics-savvy. The 13V flops around, can be inserted wrong, or can touch
some PCB component... and it is all over.

A second method that was useable was a single-pin transfer scheme. This is
also a kind of manufacturing test method. But this is very slow, making 
a complete
firmware update in about 20 minutes. The main advantage of this is that 
it is
very simple and minimalized, allowing installation of diagnostic 
firmware that will always
result in a sucessful repair.  This requires a polarized two-pin 
connector, nothing
else. since NO 13V is involved, this is very safe.

>Also, I am looking for automatic update from a host device
>
There is a component called AutoUpgrader, which is used inside Delphi
and C-Builder (Borland) compilers. This automatically handles updates
of the client's application itself AND can be used to perform an 
installation
of new firmware. Google for it. This makes upgrading applications and 
firmware
a breeze.

>, and I am 
>currently focusing on a design that would implement 
>Single-supply/Low-voltage ICSP on the host.  I do need to research using 
>some sort of boot loader, as I am not sure how well the boot loader 
>would hold up against power interruption or other failure.
>  
>
The way this works is as follows: The FIRST packet of words installed is 
a pointer to
the firmware updater itself...so if the power is interrupted, the unit 
simply jumps back
to the updater routine. Every time a packet gets installed, a 
status/address is written
to the local EEPROM to state where things are at.

To make the whole scheme bulletproof, the new firmware is first written 
into a temporary
I2C EEPROM memory, so that CRC tests can be performed on it, and if 
anything fails
during the firmware update routine, the bad section can be re-installed. 
When everything
has been installed except the  FIRST packet, which always  points to 
the  firmware updater,
the FIRST is then installed, then the watchdog timer is FORCED to 
trigger (so the system
will startup with a clean slate running the new firmware).

>The host will be a custom platform (utilizing FPGAs, actually), and can 
>be thought of as a black box.  I have a little bit of freedom so I am 
>open to any suggestion you may have.
>
>Unless I am mistaken, JTAG support is also probably not easily 
>implemented, correct?
>  
>
Its not available for Microchip components.

>I think ICSP is the way to go, but I want to explore all the options.
>  
>
ICSP is the easiest way to install the bootloader, i.e. minimal firmware.

--Bob

>Thanks for the help,
>
>-steve
>
>  
>


-- 
Note: To protect our network,
attachments must be sent to
attach@engineer.cotse.net .
1-520-850-1673 USA/Canada
http://beam.to/azengineer

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