Dear all,
I've just finish to work on some lpc2106 new design.

Now I like to discuss or know some working solution (of course we
like to know the better way to do it then learn the concepts) to do
a in field microcontroller firmware upgrade.

For one of this design we need to connect remotely trough a
industrial modem connection and we need to perform the
microcontroller firmware update trough this way.

As a first approach I can think to use a external EEPROM with stored
the actual firmware (as backup) and then before performing the
update process receive the data and store it into a another part of
the EEPROM.
When the receiving data process take end (all the new firmware was
received and stored into the support section of the EEPROM) I can
start the upgrade process.
Now I've some question:
- upgrade from the same microcontroller by using IAP commands
- use a external microcontroller and implement in this one the
update task, like we do with the Philips LPC Flash utility trough
the serial port number 0 of the LPC2106.
At the end of the task the external microcontroller can read and
check if the data was correctly stored inside the main
microcontroller and then reset it to perform the system reboot.
If somethings goes wrong we can try to restore the original
data from the backup area of the EEPROM.

I'd like to start this thread to see if some other have do such
things and also to know if someone have suggest or better idea how
to do that.

Thanks in advance

Best regards
Fabio Filippa Start a New Thread

On Thu, 14 Feb 2008 11:28:48 -0000, you wrote:

>Dear all,
>I've just finish to work on some lpc2106 new design.
>
>Now I like to discuss or know some working solution (of course we
>like to know the better way to do it then learn the concepts) to do
>a in field microcontroller firmware upgrade.
>
>For one of this design we need to connect remotely trough a
>industrial modem connection and we need to perform the
>microcontroller firmware update trough this way.
>
>As a first approach I can think to use a external EEPROM with stored
>the actual firmware (as backup) and then before performing the
>update process receive the data and store it into a another part of
>the EEPROM.
>When the receiving data process take end (all the new firmware was
>received and stored into the support section of the EEPROM) I can
>start the upgrade process.

This is a good approach where the comms process is complex or error-prone, as you can download and
verify the whole image first.
>Now I've some question:
>- upgrade from the same microcontroller by using IAP commands
>- use a external microcontroller and implement in this one the
> update task, like we do with the Philips LPC Flash utility trough
> the serial port number 0 of the LPC2106.
> At the end of the task the external microcontroller can read and
> check if the data was correctly stored inside the main
> microcontroller and then reset it to perform the system reboot.
> If somethings goes wrong we can try to restore the original
> data from the backup area of the EEPROM.
>
>I'd like to start this thread to see if some other have do such
>things and also to know if someone have suggest or better idea how
>to do that.

I think using a second MCU is overkill, and makes things more complex than they need to be.
Using IAP on the main processor should work fine.
The only risk is a power failure during the update process, however if you are concerned about this,
it can be protected against by having a permanent (never updated) bootloader section that will
restart the eeprom-to-flash process if programming was interrupted.
>Thanks in advance
>
>Best regards
>Fabio Filippa
> Start a New Thread

Fabio,

I think it boils down to one of two methods. 1) Erase app and flash
update as you RX, or 2) RX and store complete image.

Method 1 is very tough because the comms must reside in boot block and
be perfect. But if cost and space are small, you gotta do what you
gotta do.

I've found that the 2nd is easier if you have the space. After the new
image is RX'd, validate with a CRC and mark it good to go. On startup
erase and replace the old version with the new, or jump to the newest
version.

John G.

On Thu, 14 Feb 2008 11:28:48 -0000, you wrote:

>Dear all,
>I've just finish to work on some lpc2106 new design.



=======================================================================CONFIDENTIALITY NOTICE
----------------------
This message, together with any attachments, may be legally privileged
and is confidential information intended only for the use of the
individual or entity to which it is addressed. It is exempt from
disclosure under applicable law including court orders. If you are not
the intended recipient, you are hereby notified that any use,
dissemination, distribution or copy of this message, or any attachment,
is strictly prohibited. If you have received this message in error,
please notify the original sender and delete this message, along with
any attachments, from your computer. Start a New Thread

Thanks to Mike and John for suggest about this task, all are
welcomed for other suggest and idea.

Thanks again
Fabio Filippa

--- In l..., "Gerthoffer, John"
wrote:
>
> Fabio,
>
> I think it boils down to one of two methods. 1) Erase app and
flash
> update as you RX, or 2) RX and store complete image.
>
> Method 1 is very tough because the comms must reside in boot block
and
> be perfect. But if cost and space are small, you gotta do what you
> gotta do.
>
>
>
> I've found that the 2nd is easier if you have the space. After
the new
> image is RX'd, validate with a CRC and mark it good to go. On
startup
> erase and replace the old version with the new, or jump to the
newest
> version.
>
>
>
>
>
> John G.
>
>
>
> On Thu, 14 Feb 2008 11:28:48 -0000, you wrote:
>
> >Dear all,
> >I've just finish to work on some lpc2106 new design.
>
>
======================================================================> CONFIDENTIALITY NOTICE
> ----------------------
> This message, together with any attachments, may be legally
privileged
> and is confidential information intended only for the use of the
> individual or entity to which it is addressed. It is exempt from
> disclosure under applicable law including court orders. If you
are not
> the intended recipient, you are hereby notified that any use,
> dissemination, distribution or copy of this message, or any
attachment,
> is strictly prohibited. If you have received this message in
error,
> please notify the original sender and delete this message, along
with
> any attachments, from your computer.
>
> Start a New Thread

Dear all,
following the suggest then I can think to work in this direction:

1. set up a EEPROM with stored inside the backup firmware and a
area used to store the new firmware that I've to flash into the
microcontrolloer in order to perform the upgrade.

2. I can use the same microcontroller to perform the firmware
update feature.

3. When a incoming request for firmware update was received as a
first things I can receive and store the data into the EEPROM
parking area and check on the fly if the data stream received
was ok (basically a crc check of the data stream), if all is ok
then I can step into the flashing stage, if some is wrong
I can request the resend of the packet. To be fast into the
receiving stage I can define the minimum data packet to manage,
for example I can use block of 512 bytes and perform partial
checksum for every packet, when a crc error occour I can request
just the last packet instead to request the whole data stream.
May be this approach can be time saving into the update process.

4. Another scenario is if some critical event occour into the
updating process, events can be into the receiving stage,
when I'm writing to the EEPROM, when I'm updating the firmware.
The most strange event can be a power off of the system when
I'm into the one of the mentioned stage. Well, after the power off
I've to check, with a dedicated bootloader (that isn't never
updated and then always present into the microcontroller flash
memory), if the current flash CRC is equal to the one that is
stored inside the EEPROM, if the CRC is ok then the flash can be
assumed right and then I can take in execution my program, if the
CRC isn't right then some events has corrupted the flash
upgrading stage. Into this last scenario I've to update
the microcontroller firmware but before take start with this
process I've to check about the EEPROM data. As I've written
EEPROM should be store the original firmware and a backup of the
last one. If all is right the firmware release into the backup
area should be equal to the data into the update area then
I can perform the update process. If the data into the update
area have bad CRC somethings goes wrong with the receiving process
and I've to copy the data into the backup area to the update area
and then perform the firmware update process.

If anyone have criticism or suggest please let me know, I'm thinking
to write some tutorial about how to perform the live update of the
firmware into a LPC2106 microcontroller.

Best regards
Fabio Filippa Start a New Thread

Hi,

Most of the aspects of the design appear alright. The following
aspects have not been addressed by your proposal, like:

How will be the control given to the upgrader module? May be you
want to divide the execution area into upgrader and firmware area.
The control on device-reset, is always given to the upgrader. The
upgrader checks if it is required to upgrade the firmware or just
needs to givec control to the existing firmware. The upgrader and
the firmware will share the interrupt vectors.

Please follow the below link:
http://www.tnkernel.com/usb_fw_upgrader.html

This should give you an idea of what I am suggesting.
Hope that it helps you.

Warm regards
Ashwin Start a New Thread