Searching \ for '[PIC] field programming of flash-based 18Fs' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/devprogs.htm?key=programming
Search entire site for: 'field programming of flash-based 18Fs'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] field programming of flash-based 18Fs'
2006\04\05@170010 by Steve Lauziere

flavicon
face
I am curious if anyone has a unique or novel method for updating a
flash-based pic in the field.

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.

Also, I am looking for automatic update from a host device, 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 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?

I think ICSP is the way to go, but I want to explore all the options.

Thanks for the help,

-steve

2006\04\05@191010 by Bob Axtell

face picon face
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
spam_OUTattachTakeThisOuTspamengineer.cotse.net .
1-520-850-1673 USA/Canada
http://beam.to/azengineer

2006\04\06@122552 by Steve Lauziere

flavicon
face

Bob Axtell wrote:
> 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.
>  
This update is intended to be automatic. The PIC will be one part of a
large system. The system will be updated over ethernet, with a SBC
handling the updates to itself as well as other JTAG-compatible devices
(CPLDs, FPGAs). This SBC will need to update the PICs as well. It sounds
like UART transfer is the way to go since the PICs will be chained
together with RS485 or some other serial bus. I was just hesitant on
using a bootloader if there was a better way. Having some sort of "ICSP
bus" and implementing ICSP on my SBC sounds messy, and neither fun nor
elegant, anyway. I'm taking a look at AN851 right now to look for any
gotchas.

And I am using 18F, probably something like a 2525 or similar 28-pin device.


{Quote hidden}

Are you talking about the UART/serial upgrade path? with bootloader
located in a boot block? I don't think I would want to field upgrade the
bootloader.
{Quote hidden}

I may indeed use some eeprom for failsafe, but I would rather rely on my
SBC to handle CRCs and whatnot. My point in a previous paragraph about
some sort of watchdog signal was that I wanted to know how I can make
the system aware of a programming failure. Remember, this is intended to
be an automatic upgrade...I guess actually sort of autonomous as well.

Thank you very much for the input,

-steve

2006\04\06@133159 by Bob Axtell

face picon face
Steve Lauziere wrote:

{Quote hidden}

Sounds like one of my casino networks. Aah, those were the days...

I hope you are not running $Windoze on the SBC, its a quick way to
commit business
suicide. I've seen several people go under this way. ..

{Quote hidden}

No, During the time that you are upgrading the firmware, the product
itself can't do
anything else except upgrading, because except for the bootloader code
itself, you
have almost no good code available- it is in a state of flux. Bootloader
code NEVER
changes, ideally.

{Quote hidden}

You will have problems if you upgrade only a few packets at a time,
because your
product will contain a mix of old and new firmware. You need some I2C or
SPI EEROM
to perform this kind of task. Otherwise, how will you KNOW that you had
a programming
failure? You can depend on a CRC during transfers, but a CRC on the
overall data
handles the case where power failed while transferring an unpacked
packet into the
memory storage unit, and it was therefore defective. If you use a 32Kx8
I2C EEPROM,
you only use a mini8 package, smaller than a SOIC8.

Let's go over this again. You have been sent all the new firmware data.
Your server has also
sent an expected CRC16 of the entire new firmware file. When you test
it- and it matches-
you are now CERTAIN that you have good firmware to install. You will
then erase a small
chunk of code memory (the F88 erases 16 words at a time) and then
install a small chunk.
Before you go on, you can read the new chunk to make sure it has been
installed correctly.
This process is repeated for every 16 words, until it is done. The VERY
LAST 16-word chunk
is installed at the lowest part of code space, i.e. where the  program
starts.

>Thank you very much for the input,
>
>  
>
Glad to help. This is a bit tricky; I didn't learn all this overnight.
One has to think out EVERY step.

>-steve
>
>  
>


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

2006\04\06@163141 by Steve Lauziere

flavicon
face
Bob Axtell wrote:
> Sounds like one of my casino networks. Aah, those were the days...
>
> I hope you are not running $Windoze on the SBC, its a quick way to
> commit business
> suicide. I've seen several people go under this way. ..
>
>  
Nope, no windows here.  SBC will likely use either VxWorks or Green Hill
RTOS.


> No, During the time that you are upgrading the firmware, the product
> itself can't do
> anything else except upgrading, because except for the bootloader code
> itself, you
> have almost no good code available- it is in a state of flux. Bootloader
> code NEVER
> changes, ideally.
>
>  
Gotcha.  The process is starting to click for me.

{Quote hidden}

Ok, let me see if I can spell out my exact thinking on this based on
what you have told me:

Prereqs:
   -Bootloader is loaded on device
   -Device is currently in user mode, and I want to update the
user-space firmware

Execution:
   -User-space firmware receives UPDATE command from host (SBC)
       -User-space firmware writes 0xFF to last memory location
       -User-space resets device (most likely with RESET)
   -Bootloader executes
      -Bootloader receives an initial message from host (SBC) and ACKs
for start of firmware update
      -Host sends 8 byte packet of firmware
      -Bootloader compares CHKSUM, writes 8 bytes to flash, and ACKs
          -Else bootloader NACKs, and host resends packet.
      -Repeat until all data sent...
      -Once Host is done, sends FINISH message to bootloader
      -OPTIONAL: (bootloader calculates CRC of firmware in flash??)
      -Bootloader writes 0x00 to last mem location
      -Bootloader resets

With this method, a power reset during transfer will cause the PIC to
power back up in "bootloader" mode.  And the SBC will ping the
bootloader for commencement of a new transfer.

I could possibly keep state of the firmware update progress on the SBC,
so I know where I left off in writing to flash.  This gets kinda hairy
though.

A few questions:
1:  I think my method gets around having another EEPROM with minimal
trade-offs.  Thoughts?
2:  Using the last memory location for bootloader/user-space
state...This seems a little risky.   How else could you initiate an
update?

I guess if I had to I could tie MCLR and RB0 back to my FPGA I/O, and
control the boot that way (that is how Microchip's boot loader for 8722
works)


-steve

2006\04\06@170519 by M. Adam Davis

face picon face
A similar method to try without the eeprom is:

There are three code spaces in flash.  The first is the bootloader,
the next two are the user program areas.

On powerup the device goes into the boot loader, which does the
following on bootup:
* Checks a status byte/word that indicates which user program areas
are "working", and which one to boot by default.
* Does a complete CRC check on the user program that is set to boot by default
* As long as it passes, it runs the code in that user area
* if it doesn't pass, it checks the status byte to see if the second
area is listed as working
* if it is, then it checks the second user area CRC
* If that one passes it starts executing code from there.
* if the CRC fails or it's listed as not working, then it goes into a
bootloader command mode so it can be reprogrammed.
Note that it will also not start a program listed as "not working"
even if it's the default boot.
Also the default boot can be the bootloader.  Also there may be a bare
metal bootloader that is triggered if the primary bootloader itself
fails a CRC, or to update the bootloader.  This one is more dangerous
since it doesn't come with some interlocks mentioned below.

The user programs, upon receiving a "update" command go to the
bootloader command mode.

The bootloader command mode is a section in the bootloader that allows
some other entity to check the current status of the two user
programs, change the status, and read/write in either area.
The key here is that this procedure will not allow you to write to any
memory that has a status of "working" without changing the status to
"not working."  Further, it won't let you change the status of one or
the other user program unless the other program has a status of
working (ie, one must be working at all times).  It won't change the
status from not working to working until after a CRC check.  The CRC
can be stored with the programs, or in a seperate area.

This pretty much takes care of any circumstances you might find the
chip in.  Reboots during the updates, etc are all handled
appropiately.  The external program that talks to the chip must be
aware of the current state and any interruptions, so careful attention
must be paid to the protocols used in each case since a sudden reboot
may take the chip out of programming and into normal operation.
Further, the microcontroller is not left in an ambiguous bootloader
mode if the user gives up on updating the firmware after the 34th try.

The bootloader, as usual, should include the attempt write of block,
attempt read of block, verify, goto next block cycle.  This will
enable the program loading the update into the chip to speed the
process up if an interruption occurs, since it knows where it left off
and can verify all previously written data upon entering the
bootloading state again - unless the program updating the chip also
experiences a reboot.  There are other methods to fix that problem if
it is expected, but worst case it does a full update.

There are other things one can do to make this more robust and/or
speedy, but this is a fairly reasonable method.  I may have missed
something so go over all the cases and make sure it meets your needs.

-Adam

On 4/6/06, Steve Lauziere <slauzierespamKILLspamniitek.com> wrote:
{Quote hidden}

> -

2006\04\06@171612 by Bob Axtell

face picon face
Steve Lauziere wrote:

>Bob Axtell wrote:
>  
>
>>Sounds like one of my casino networks. Aah, those were the days...
>>
>>I hope you are not running $Windoze on the SBC, its a quick way to
>>commit business
>>suicide. I've seen several people go under this way. ..
>>
>>  
>>    
>>
>Nope, no windows here.  SBC will likely use either VxWorks or Green Hill
>RTOS.
>
>  
>
VERY good! Both of these seem to work very well. I'd hate to lose
another friend due
to B Gates' parlor tricks.

{Quote hidden}

maybe, a flag into your local EEROM space?

{Quote hidden}

OK, I see what you are thinking. The problem is, if radio  modem
conditions go awry
in the middle of this, you are stuck... but maybe that is OK. It will
take a long time to
update and program in real time, but that might be perfectly acceptable.

Personally, I like the idea of getting all the data into storage BEFORE
starting the
upgrade, but maybe it isn't needed, since you seem to have a LOT of
bandwidth.
I was limited to no more than 144 bytes transmitted per radio modem
session, to
keep battery useage minimized. This meant that firmware updates had to
be sent
'catch as catch can'.

>With this method, a power reset during transfer will cause the PIC to
>power back up in "bootloader" mode.  And the SBC will ping the
>bootloader for commencement of a new transfer.
>
>I could possibly keep state of the firmware update progress on the SBC,
>so I know where I left off in writing to flash.  This gets kinda hairy
>though.
>  
>
No, simply have the unit keep track of its own progress by writing to
its own EEROM
the address of LAST GOOD data. Then all you have to do is to start after
that point.
Make the SBC ask for the last position. HINT: the fewest number of hands
should
make the pudding.

>A few questions:
>1:  I think my method gets around having another EEPROM with minimal
>trade-offs.  Thoughts?
>  
>
Your method looks like you have it working without extra EEPROM space.

>2:  Using the last memory location for bootloader/user-space
>state...This seems a little risky.   How else could you initiate an
>update?
>
Why not write a flag into your own EEPROM space? When your program starts
off, the flags are read and the jump to bootloader is either made or not
made.

>
>
>I guess if I had to I could tie MCLR and RB0 back to my FPGA I/O, and
>control the boot that way (that is how Microchip's boot loader for 8722
>works)
>
>  
>
Naw, that's an ungainly way of doing it. Besides, you will need MCLR
free for the one
time you WILL need to write code using HV mode.... when you are writing
the configuration
and bootloader firmware for the one and only time.

>-steve
>  
>


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

2006\04\06@171946 by Bob Axtell

face picon face
Mr Davis makes an excellent point.  I hadn't thought of this,
but I had thought about unused code space used to store
the new firmware data temporarily.

GOOD CATCH!

--Bob

M. Adam Davis wrote:

{Quote hidden}

>>-

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