Reply by petepen111 September 18, 20072007-09-18
Thanks all, I've taken you're remarks onboard and it will certainly be
helpful, thanks.

regards
Peter

--- In l..., "Paul Curtis" wrote:
>
> Whilst I question the upgrade process, you might want to figure out
where
> your stack is on entry to the upgrader. Personally I would separate
the app
> into two, a bootloader (upgrader) which is resident in flash always
and a
> replaceable firmware reprogrammed from SPI flash--in this way you're not
> vulnerable over a power fail or any other hardware hiccup. So, I'd
have:
>
> 1. Bootloader in flash CRCs application area to ensure correct app.
> 2. If app is good, run it.
> 3. If app is bad, take app from SPI flash and flash it into application
> area.
>
> The main app is responsible for downloading and placing a new
application
> into SPI flash and verifying the contents of the SPI flash. Once
verified,
> force a WD reset and the bootloader notices the new app in SPI and
tries to
> replace the main application in the CPU's flash.
>
> This is completely foolproof as long as the bootloader isn't
overwritten and
> you trust it.
>
> -- Paul.
>

An Engineer's Guide to the LPC2100 Series

Reply by Alexandre Kremer September 17, 20072007-09-17
Thats why i like ethernet. High data transfers,
reliability and no host/client hardware differences.
We do have this idea running on pdas using wifi to
upgrade some of our products. Using usb sounds good to
me, it worth a try.

Regards

--- bobtransformer escreveu:

>
> Has anyone here looked into either PDA's or Palms or
> just handheld
> computers with USB hosts for holding the new
> firmware to be
> flashed in the field ??? This would be nice so the
> service
> person doesn't have to have a laptop and the hand
> held device
> can have the upload software on it.
>
> Is this why some of you are using camera type flash
> memories ???
> That would be fine for me except that I don't think
> I have
> enough pins left over for SD Flash unless maybe I
> could use
> the JTAG connector which is on our finished unit ???
>
> Too bad the LPC214X doesn't have a USB host
> controller so the
> customer/service guy could just use a USB memory
> stick.
>
> boB
> --- In l..., "mjames_doveridge"
> wrote:
> >
> > --- In l..., "Paul Curtis"
> wrote:
> > >
> > > Peter,
> > >
> > > > In general, the flow is:
> > > >
> > > > 1) To create a firmware image in external spi
> flash during normal
> > > > application operation.
> > > >
> > > > 2) On completion of a valid image, the main
> application cleans up,
> > > > copies a function which copies from ext flash
> into main flash (using
> > > > the IAP), then reboot the micro (via
> watchdog).
> > > >
> > > > The function to copy external flash to
> internal is NOT resident in
> > > > SRAM (due to memory resrictions) but is copied
> there once the
> main app
> > > > has released resources.
> > > >
> > > > Prior to calling the 'copied' function in
> SRAM, interrupts are
> > > > stopped, the vector table is copied to SRAM,
> VIC is disabled and
> > > > MEMMAP is set to 0x2. The SRAM function is
> then called.
> > > >
> > > > However, soon after this, a prefetch abort
> occurs !!
> > > >
> > > > Is there anything else that needs to be set in
> order to run code in
> > > > SRAM on a device that is primarily setup to be
> run from FLASH? The
> > > > setup is ARM mode with interworking=yes. There
> is no apparent
> > > > conflicts with SRAM allocation and where the
> function is copied to.
> > > >
> > > > At this stage, any ideas would be appreciated.
> If you need any more
> > > > specific info, then I can forward that to you.
> > >
> > > Whilst I question the upgrade process, you might
> want to figure out
> > where
> > > your stack is on entry to the upgrader.
> Personally I would separate
> > the app
> > > into two, a bootloader (upgrader) which is
> resident in flash always
> > and a
> > > replaceable firmware reprogrammed from SPI
> flash--in this way
> you're not
> > > vulnerable over a power fail or any other
> hardware hiccup. So, I'd
> > have:
> > >
> > > 1. Bootloader in flash CRCs application area to
> ensure correct app.
> > > 2. If app is good, run it.
> > > 3. If app is bad, take app from SPI flash and
> flash it into
> application
> > > area.
> > >
> > > The main app is responsible for downloading and
> placing a new
> > application
> > > into SPI flash and verifying the contents of the
> SPI flash. Once
> > verified,
> > > force a WD reset and the bootloader notices the
> new app in SPI and
> > tries to
> > > replace the main application in the CPU's flash.
> > >
> > > This is completely foolproof as long as the
> bootloader isn't
> > overwritten and
> > > you trust it.
> > >
> > > -- Paul.
> >
> > That's pretty much the way I went. I have a
> secondary bootloader that
> > is always there in flash - I load it with the
> Philips serial thingy.
> > I build my main app twice at different locations
> in flash so that I
> > can keep two banks. Both builds are set to map
> their vectors to RAM
> > so that the boot loader always runs after a hard
> reset. The
> > bootloader and the two banks have two small,
> shared, fixed-location
> > 'interface segments' containing start address,
> checksum, length,
> > version etc, so allowing the bootloader to see
> what is loaded.
> > Normally upon startup, (if there is no SD card
> detected in the slot
> > and no keys are pressed on the keypad), the
> bootloader looks at the
> > two banks, checks them and, if both OK, runs the
> one with the latest
> > version number. If only one is OK, it runs that
> one. If an SD card is
> > detected in the slot, the bootloader checks to see
> if there are two
> > app image file names 'BANKA.BIN', 'BANKB.BIN' on
> it. If there are, it
> > reads and burns in one of them, depending on what
> is already loaded,
> > (overblowing oldest version number if both banks
> are already valid).
> > If a key is held down during a reset, or there is
> no valid bank
> > loaded, the bootloader retains control, displaying
> a menu so that the
> > user can manually direct it to load/blow/run/erase
> either bank.
> >
> > So far, I have not lost control of my system,
> (well, due to bugs, yes,
> > but not because of this bootup design).
> >
> > It has an additional advantage that, if the
> version number of my
> > current development/test software is left '0.0',
> the boot loader will
> > always run the 'other one' after a reset. I keep
> that 'other one' at
> > stable points & so I can always instantly
> demonstrate current progress
> > by stopping my JTAG debugger and power-cycling the
> board - the stable
> > version runs up straightaway :)
> >
> > Of course, you need to have room in flash for two
> loads :(
> >
> > Rgds,
> > Martin
> >
>
> Yahoo! Groups Links
=== message truncated ==
Flickr agora em portugu. Vocclica, todo mundo v
http://www.flickr.com.br/
Reply by bobtransformer September 17, 20072007-09-17
Has anyone here looked into either PDA's or Palms or just handheld
computers with USB hosts for holding the new firmware to be
flashed in the field ??? This would be nice so the service
person doesn't have to have a laptop and the hand held device
can have the upload software on it.

Is this why some of you are using camera type flash memories ???
That would be fine for me except that I don't think I have
enough pins left over for SD Flash unless maybe I could use
the JTAG connector which is on our finished unit ???

Too bad the LPC214X doesn't have a USB host controller so the
customer/service guy could just use a USB memory stick.

boB

--- In l..., "mjames_doveridge" wrote:
>
> --- In l..., "Paul Curtis" wrote:
> >
> > Peter,
> >
> > > In general, the flow is:
> > >
> > > 1) To create a firmware image in external spi flash during normal
> > > application operation.
> > >
> > > 2) On completion of a valid image, the main application cleans up,
> > > copies a function which copies from ext flash into main flash (using
> > > the IAP), then reboot the micro (via watchdog).
> > >
> > > The function to copy external flash to internal is NOT resident in
> > > SRAM (due to memory resrictions) but is copied there once the
main app
> > > has released resources.
> > >
> > > Prior to calling the 'copied' function in SRAM, interrupts are
> > > stopped, the vector table is copied to SRAM, VIC is disabled and
> > > MEMMAP is set to 0x2. The SRAM function is then called.
> > >
> > > However, soon after this, a prefetch abort occurs !!
> > >
> > > Is there anything else that needs to be set in order to run code in
> > > SRAM on a device that is primarily setup to be run from FLASH? The
> > > setup is ARM mode with interworking=yes. There is no apparent
> > > conflicts with SRAM allocation and where the function is copied to.
> > >
> > > At this stage, any ideas would be appreciated. If you need any more
> > > specific info, then I can forward that to you.
> >
> > Whilst I question the upgrade process, you might want to figure out
> where
> > your stack is on entry to the upgrader. Personally I would separate
> the app
> > into two, a bootloader (upgrader) which is resident in flash always
> and a
> > replaceable firmware reprogrammed from SPI flash--in this way
you're not
> > vulnerable over a power fail or any other hardware hiccup. So, I'd
> have:
> >
> > 1. Bootloader in flash CRCs application area to ensure correct app.
> > 2. If app is good, run it.
> > 3. If app is bad, take app from SPI flash and flash it into
application
> > area.
> >
> > The main app is responsible for downloading and placing a new
> application
> > into SPI flash and verifying the contents of the SPI flash. Once
> verified,
> > force a WD reset and the bootloader notices the new app in SPI and
> tries to
> > replace the main application in the CPU's flash.
> >
> > This is completely foolproof as long as the bootloader isn't
> overwritten and
> > you trust it.
> >
> > -- Paul.
>
> That's pretty much the way I went. I have a secondary bootloader that
> is always there in flash - I load it with the Philips serial thingy.
> I build my main app twice at different locations in flash so that I
> can keep two banks. Both builds are set to map their vectors to RAM
> so that the boot loader always runs after a hard reset. The
> bootloader and the two banks have two small, shared, fixed-location
> 'interface segments' containing start address, checksum, length,
> version etc, so allowing the bootloader to see what is loaded.
> Normally upon startup, (if there is no SD card detected in the slot
> and no keys are pressed on the keypad), the bootloader looks at the
> two banks, checks them and, if both OK, runs the one with the latest
> version number. If only one is OK, it runs that one. If an SD card is
> detected in the slot, the bootloader checks to see if there are two
> app image file names 'BANKA.BIN', 'BANKB.BIN' on it. If there are, it
> reads and burns in one of them, depending on what is already loaded,
> (overblowing oldest version number if both banks are already valid).
> If a key is held down during a reset, or there is no valid bank
> loaded, the bootloader retains control, displaying a menu so that the
> user can manually direct it to load/blow/run/erase either bank.
>
> So far, I have not lost control of my system, (well, due to bugs, yes,
> but not because of this bootup design).
>
> It has an additional advantage that, if the version number of my
> current development/test software is left '0.0', the boot loader will
> always run the 'other one' after a reset. I keep that 'other one' at
> stable points & so I can always instantly demonstrate current progress
> by stopping my JTAG debugger and power-cycling the board - the stable
> version runs up straightaway :)
>
> Of course, you need to have room in flash for two loads :(
>
> Rgds,
> Martin
>
Reply by mjames_doveridge September 17, 20072007-09-17
--- In l..., "Paul Curtis" wrote:
>
> Peter,
>
> > In general, the flow is:
> >
> > 1) To create a firmware image in external spi flash during normal
> > application operation.
> >
> > 2) On completion of a valid image, the main application cleans up,
> > copies a function which copies from ext flash into main flash (using
> > the IAP), then reboot the micro (via watchdog).
> >
> > The function to copy external flash to internal is NOT resident in
> > SRAM (due to memory resrictions) but is copied there once the main app
> > has released resources.
> >
> > Prior to calling the 'copied' function in SRAM, interrupts are
> > stopped, the vector table is copied to SRAM, VIC is disabled and
> > MEMMAP is set to 0x2. The SRAM function is then called.
> >
> > However, soon after this, a prefetch abort occurs !!
> >
> > Is there anything else that needs to be set in order to run code in
> > SRAM on a device that is primarily setup to be run from FLASH? The
> > setup is ARM mode with interworking=yes. There is no apparent
> > conflicts with SRAM allocation and where the function is copied to.
> >
> > At this stage, any ideas would be appreciated. If you need any more
> > specific info, then I can forward that to you.
>
> Whilst I question the upgrade process, you might want to figure out
where
> your stack is on entry to the upgrader. Personally I would separate
the app
> into two, a bootloader (upgrader) which is resident in flash always
and a
> replaceable firmware reprogrammed from SPI flash--in this way you're not
> vulnerable over a power fail or any other hardware hiccup. So, I'd
have:
>
> 1. Bootloader in flash CRCs application area to ensure correct app.
> 2. If app is good, run it.
> 3. If app is bad, take app from SPI flash and flash it into application
> area.
>
> The main app is responsible for downloading and placing a new
application
> into SPI flash and verifying the contents of the SPI flash. Once
verified,
> force a WD reset and the bootloader notices the new app in SPI and
tries to
> replace the main application in the CPU's flash.
>
> This is completely foolproof as long as the bootloader isn't
overwritten and
> you trust it.
>
> -- Paul.

That's pretty much the way I went. I have a secondary bootloader that
is always there in flash - I load it with the Philips serial thingy.
I build my main app twice at different locations in flash so that I
can keep two banks. Both builds are set to map their vectors to RAM
so that the boot loader always runs after a hard reset. The
bootloader and the two banks have two small, shared, fixed-location
'interface segments' containing start address, checksum, length,
version etc, so allowing the bootloader to see what is loaded.
Normally upon startup, (if there is no SD card detected in the slot
and no keys are pressed on the keypad), the bootloader looks at the
two banks, checks them and, if both OK, runs the one with the latest
version number. If only one is OK, it runs that one. If an SD card is
detected in the slot, the bootloader checks to see if there are two
app image file names 'BANKA.BIN', 'BANKB.BIN' on it. If there are, it
reads and burns in one of them, depending on what is already loaded,
(overblowing oldest version number if both banks are already valid).
If a key is held down during a reset, or there is no valid bank
loaded, the bootloader retains control, displaying a menu so that the
user can manually direct it to load/blow/run/erase either bank.

So far, I have not lost control of my system, (well, due to bugs, yes,
but not because of this bootup design).

It has an additional advantage that, if the version number of my
current development/test software is left '0.0', the boot loader will
always run the 'other one' after a reset. I keep that 'other one' at
stable points & so I can always instantly demonstrate current progress
by stopping my JTAG debugger and power-cycling the board - the stable
version runs up straightaway :)

Of course, you need to have room in flash for two loads :(

Rgds,
Martin
Reply by Alexandre Kremer September 17, 20072007-09-17
--- Brendan Murphy
escreveu:

> --- In l..., "Paul Curtis"
> wrote:
> > Whilst I question the upgrade process, you might
> want to figure out
> where
> > your stack is on entry to the upgrader.
> Personally I would
> separate the app
> > into two, a bootloader (upgrader) which is
> resident in flash always
> and a
> > replaceable firmware reprogrammed from SPI
> flash--in this way
> you're not
> > vulnerable over a power fail or any other hardware
> hiccup. So, I'd
> have:
> >
> > 1. Bootloader in flash CRCs application area to
> ensure correct app.
> > 2. If app is good, run it.
> > 3. If app is bad, take app from SPI flash and
> flash it into
> application
> > area.
> >
> > The main app is responsible for downloading and
> placing a new
> application
> > into SPI flash and verifying the contents of the
> SPI flash. Once
> verified,
> > force a WD reset and the bootloader notices the
> new app in SPI and
> tries to
> > replace the main application in the CPU's flash.
> >
> > This is completely foolproof as long as the
> bootloader isn't
> overwritten and
> > you trust it.
> >
> > -- Paul.
> > I'd 2nd this model of in-service firmware upgrade.
>
> Only thing I'd add is to keep the boot loader as
> simple as possible.
>
> Brendan.

Hum, since the new firmware will be in serial flash,
i suggest you to perform data encryption, just to
avoid piracy on your code.
On my coldfire and lpc designs, i used this approach
to my bootloader. The difference is that i implemented
data encryption as i stated before, and i also keep
the new firmware as short as possible on the serial
flash. So, on reset, the bootloader checks the serial
flash for new firmware, and do the CRC of it to check
if its a valid image. If its valid, it erases and
flashes the user program flash memory and then do the
CRC of the new program in internal flash. If OK, it
erases the serial flash and jump to main application,
if not, some internal flashing error occurred so it
resets and try again.

Flickr agora em portugu. Vocclica, todo mundo v
http://www.flickr.com.br/
Reply by Alexandre Kremer September 17, 20072007-09-17
--- Brendan Murphy
escreveu:

> --- In l..., "Paul Curtis"
> wrote:
> > Whilst I question the upgrade process, you might
> want to figure out
> where
> > your stack is on entry to the upgrader.
> Personally I would
> separate the app
> > into two, a bootloader (upgrader) which is
> resident in flash always
> and a
> > replaceable firmware reprogrammed from SPI
> flash--in this way
> you're not
> > vulnerable over a power fail or any other hardware
> hiccup. So, I'd
> have:
> >
> > 1. Bootloader in flash CRCs application area to
> ensure correct app.
> > 2. If app is good, run it.
> > 3. If app is bad, take app from SPI flash and
> flash it into
> application
> > area.
> >
> > The main app is responsible for downloading and
> placing a new
> application
> > into SPI flash and verifying the contents of the
> SPI flash. Once
> verified,
> > force a WD reset and the bootloader notices the
> new app in SPI and
> tries to
> > replace the main application in the CPU's flash.
> >
> > This is completely foolproof as long as the
> bootloader isn't
> overwritten and
> > you trust it.
> >
> > -- Paul.
> > I'd 2nd this model of in-service firmware upgrade.
>
> Only thing I'd add is to keep the boot loader as
> simple as possible.
>
> Brendan.

Hum, since the new firmware will be in serial flash,
i suggest you to perform data encryption, just to
avoid piracy on your code.
On my coldfire designs, i used this approach to my
bootloader. The difference is that i implemented data
encryption as i stated before, and i also keep the new
firmware as short as possible on the serial flash. So,
on reset, the bootloader checks the serial flash for
new firmware, and do the CRC of it to check if its a
valid image. If its valid, it erases and flashes the
user program flash memory and then do the CRC of the
new program in internal flash. If OK, it erases the
serial flash and jump to main application, if not,
some internal flashing error occurred so it resets and
try again.

Flickr agora em portugu. Vocclica, todo mundo v
http://www.flickr.com.br/
Reply by Brendan Murphy September 17, 20072007-09-17
--- In l..., "Paul Curtis" wrote:
> Whilst I question the upgrade process, you might want to figure out
where
> your stack is on entry to the upgrader. Personally I would
separate the app
> into two, a bootloader (upgrader) which is resident in flash always
and a
> replaceable firmware reprogrammed from SPI flash--in this way
you're not
> vulnerable over a power fail or any other hardware hiccup. So, I'd
have:
>
> 1. Bootloader in flash CRCs application area to ensure correct app.
> 2. If app is good, run it.
> 3. If app is bad, take app from SPI flash and flash it into
application
> area.
>
> The main app is responsible for downloading and placing a new
application
> into SPI flash and verifying the contents of the SPI flash. Once
verified,
> force a WD reset and the bootloader notices the new app in SPI and
tries to
> replace the main application in the CPU's flash.
>
> This is completely foolproof as long as the bootloader isn't
overwritten and
> you trust it.
>
> -- Paul.
>

I'd 2nd this model of in-service firmware upgrade.

Only thing I'd add is to keep the boot loader as simple as possible.

Brendan.
Reply by Paul Curtis September 17, 20072007-09-17
Peter,

> In general, the flow is:
>
> 1) To create a firmware image in external spi flash during normal
> application operation.
>
> 2) On completion of a valid image, the main application cleans up,
> copies a function which copies from ext flash into main flash (using
> the IAP), then reboot the micro (via watchdog).
>
> The function to copy external flash to internal is NOT resident in
> SRAM (due to memory resrictions) but is copied there once the main app
> has released resources.
>
> Prior to calling the 'copied' function in SRAM, interrupts are
> stopped, the vector table is copied to SRAM, VIC is disabled and
> MEMMAP is set to 0x2. The SRAM function is then called.
>
> However, soon after this, a prefetch abort occurs !!
>
> Is there anything else that needs to be set in order to run code in
> SRAM on a device that is primarily setup to be run from FLASH? The
> setup is ARM mode with interworking=yes. There is no apparent
> conflicts with SRAM allocation and where the function is copied to.
>
> At this stage, any ideas would be appreciated. If you need any more
> specific info, then I can forward that to you.

Whilst I question the upgrade process, you might want to figure out where
your stack is on entry to the upgrader. Personally I would separate the app
into two, a bootloader (upgrader) which is resident in flash always and a
replaceable firmware reprogrammed from SPI flash--in this way you're not
vulnerable over a power fail or any other hardware hiccup. So, I'd have:

1. Bootloader in flash CRCs application area to ensure correct app.
2. If app is good, run it.
3. If app is bad, take app from SPI flash and flash it into application
area.

The main app is responsible for downloading and placing a new application
into SPI flash and verifying the contents of the SPI flash. Once verified,
force a WD reset and the bootloader notices the new app in SPI and tries to
replace the main application in the CPU's flash.

This is completely foolproof as long as the bootloader isn't overwritten and
you trust it.

-- Paul.
Reply by petepen111 September 17, 20072007-09-17
Hi,

I am using the Rowley CrossStudio for an NXP LPC2129, with some
external SPI FLASH in addition to the internal flash. I have a problem
with a F/W upgrader I have been developing.

In general, the flow is:

1) To create a firmware image in external spi flash during normal
application operation.

2) On completion of a valid image, the main application cleans up,
copies a function which copies from ext flash into main flash (using
the IAP), then reboot the micro (via watchdog).

The function to copy external flash to internal is NOT resident in
SRAM (due to memory resrictions) but is copied there once the main app
has released resources.

Prior to calling the 'copied' function in SRAM, interrupts are
stopped, the vector table is copied to SRAM, VIC is disabled and
MEMMAP is set to 0x2. The SRAM function is then called.

However, soon after this, a prefetch abort occurs !!

Is there anything else that needs to be set in order to run code in
SRAM on a device that is primarily setup to be run from FLASH? The
setup is ARM mode with interworking=yes. There is no apparent
conflicts with SRAM allocation and where the function is copied to.

At this stage, any ideas would be appreciated. If you need any more
specific info, then I can forward that to you.

Regards,
Peter