Hi,
basically it *is* possible to do what you want, but it's not that
easy as you might think. As you want to have the possibilty to
exchange the *complete* flash data (that means not only an
application area) and the LPC's can not write into the flash memory
execting from you have to do as follows:
You must write a so-called secondary bootloader, which is fully
running in RAM (image loaded from flash at power up). This secondary
bootloader can check the sanity of your application area and jump to
the application when everything is ok. If this is not the case it
must communicate with the "host" to get data and write it to flash
then and make a reboot finally (by not servicing the watchdog).
To bring the bootloader into effect (itmormally does a santity check
of the app area only and the "terminates" by jumping to the app) you
could either do some minimal communication with the host before it
jumps to the app, or you let the app modify something in the flash
area checked by the bootloader via it's santity check to force an
update.
Hope that helps to estimate the effort.
Regards
Herbert
At 10:30 31.05.2008 -0700, you wrote:
>
>Hi everybody, my name's Yaque, I'm working in a project with
>microcontrollers of family LPC2000. Basically I have 100 electronic
>terminals, each one is controlled by a microcontroller LPC2212 of
>NXP family. They are linked or connected to a main server by means
>of RS485 network. Now one main consideration to have is that these
>terminals need to be reprogrammed completely every certain time So
>it's required to make this updating of software in the
>microcontrollers in the less time possible.
>
>So I have two options. Reprogramming everyboard manually using a
>programmer, that requires going to each terminal, getting access to
>the microcontroller board and making all the steps to get the
>reprogramming done. OR the second option would be using the main
>server (what is possible) to reprogram the 100 terminal through just
>one procedure.
>Here comes the help I need from you, I know that we can reprogram
>the complete flash memory using the IAP commands stored in the Boot
>loader. So I was thinking in that every microcontroller can receive
>a command through the RS485 to start the reprogram mode. This means
>loading a piece of program (this would contain the software to
>manipulate the IAP commands) from flash to the RAM that waits
>for the updated firmware and store it in the RAM (this can be
>received in pieces as the update is larger than the RAM size) and
>then program it to the flash. After this we can use the watchdog
>timer to make a rest and the new user application would start.
>
>I'm new in using these features of this microcontroller and it's
>taking me too much time to try to implement this. Please can you
>help me with some information or program you have to use the IAP and
>RAM memory to make a reprogram of the complete flash memory.
>
>Thanks.
>Yaque.
Re: REPROGRAMMING THE FULL FLASH MEMORY USING IAP THROUGH RS485 NETWORK
Started by ●June 1, 2008
Reply by ●June 1, 20082008-06-01
> -----Original Message-----
> From: l...
> [mailto:l...]On Behalf
> Of Herbert Demmel
> Sent: Sunday, June 01, 2008 1:07 PM
> To: l...
> Subject: Re: [lpc2000] REPROGRAMMING THE FULL FLASH MEMORY USING IAP
> THROUGH RS485 NETWORK
> Hi,
>
> basically it *is* possible to do what you want, but it's not that
> easy as you might think. As you want to have the possibilty to
> exchange the *complete* flash data (that means not only an
> application area) and the LPC's can not write into the flash memory
> execting from you have to do as follows:
>
> You must write a so-called secondary bootloader, which is fully
> running in RAM (image loaded from flash at power up). This secondary
> bootloader can check the sanity of your application area and jump to
> the application when everything is ok. If this is not the case it
> must communicate with the "host" to get data and write it to flash
> then and make a reboot finally (by not servicing the watchdog).
>
> To bring the bootloader into effect (itmormally does a santity check
> of the app area only and the "terminates" by jumping to the app) you
> could either do some minimal communication with the host before it
> jumps to the app, or you let the app modify something in the flash
> area checked by the bootloader via it's santity check to
> force an update.
>
> Hope that helps to estimate the effort.
>
> Regards
> Herbert
The secondary bootloader can exist in flash, and does not need to be
copied to RAM. Since you are making calls to the IAP routines to
actually modify the flash, the bootload code will not be running.
After the write has completed, a return to the flash bootload code
is done, and all is well.
Mike
> From: l...
> [mailto:l...]On Behalf
> Of Herbert Demmel
> Sent: Sunday, June 01, 2008 1:07 PM
> To: l...
> Subject: Re: [lpc2000] REPROGRAMMING THE FULL FLASH MEMORY USING IAP
> THROUGH RS485 NETWORK
> Hi,
>
> basically it *is* possible to do what you want, but it's not that
> easy as you might think. As you want to have the possibilty to
> exchange the *complete* flash data (that means not only an
> application area) and the LPC's can not write into the flash memory
> execting from you have to do as follows:
>
> You must write a so-called secondary bootloader, which is fully
> running in RAM (image loaded from flash at power up). This secondary
> bootloader can check the sanity of your application area and jump to
> the application when everything is ok. If this is not the case it
> must communicate with the "host" to get data and write it to flash
> then and make a reboot finally (by not servicing the watchdog).
>
> To bring the bootloader into effect (itmormally does a santity check
> of the app area only and the "terminates" by jumping to the app) you
> could either do some minimal communication with the host before it
> jumps to the app, or you let the app modify something in the flash
> area checked by the bootloader via it's santity check to
> force an update.
>
> Hope that helps to estimate the effort.
>
> Regards
> Herbert
The secondary bootloader can exist in flash, and does not need to be
copied to RAM. Since you are making calls to the IAP routines to
actually modify the flash, the bootload code will not be running.
After the write has completed, a return to the flash bootload code
is done, and all is well.
Mike
Reply by ●June 1, 20082008-06-01
Mike,
the original poster Yaque was speaking about the FULL FLASH MEMORY (I
don't want to shout, it's only copied from the subject line), so if
he wants to do so, he has the need to overwrite the secondary
bootloader as well: I'm not aware about any other posibilty to do so
than to run it out of RAM.
Herbret
At 14:06 01.06.2008 -0600, you wrote:
> > -----Original Message-----
> > From: l...
> > [mailto:l...]On Behalf
> > Of Herbert Demmel
> > Sent: Sunday, June 01, 2008 1:07 PM
> > To: l...
> > Subject: Re: [lpc2000] REPROGRAMMING THE FULL FLASH MEMORY USING IAP
> > THROUGH RS485 NETWORK
> >
> >
> > Hi,
> >
> > basically it *is* possible to do what you want, but it's not that
> > easy as you might think. As you want to have the possibilty to
> > exchange the *complete* flash data (that means not only an
> > application area) and the LPC's can not write into the flash memory
> > execting from you have to do as follows:
> >
> > You must write a so-called secondary bootloader, which is fully
> > running in RAM (image loaded from flash at power up). This secondary
> > bootloader can check the sanity of your application area and jump to
> > the application when everything is ok. If this is not the case it
> > must communicate with the "host" to get data and write it to flash
> > then and make a reboot finally (by not servicing the watchdog).
> >
> > To bring the bootloader into effect (itmormally does a santity check
> > of the app area only and the "terminates" by jumping to the app) you
> > could either do some minimal communication with the host before it
> > jumps to the app, or you let the app modify something in the flash
> > area checked by the bootloader via it's santity check to
> > force an update.
> >
> > Hope that helps to estimate the effort.
> >
> > Regards
> > Herbert
> >
> >The secondary bootloader can exist in flash, and does not need to be
>copied to RAM. Since you are making calls to the IAP routines to
>actually modify the flash, the bootload code will not be running.
>After the write has completed, a return to the flash bootload code
>is done, and all is well.
>
>Mike
>
the original poster Yaque was speaking about the FULL FLASH MEMORY (I
don't want to shout, it's only copied from the subject line), so if
he wants to do so, he has the need to overwrite the secondary
bootloader as well: I'm not aware about any other posibilty to do so
than to run it out of RAM.
Herbret
At 14:06 01.06.2008 -0600, you wrote:
> > -----Original Message-----
> > From: l...
> > [mailto:l...]On Behalf
> > Of Herbert Demmel
> > Sent: Sunday, June 01, 2008 1:07 PM
> > To: l...
> > Subject: Re: [lpc2000] REPROGRAMMING THE FULL FLASH MEMORY USING IAP
> > THROUGH RS485 NETWORK
> >
> >
> > Hi,
> >
> > basically it *is* possible to do what you want, but it's not that
> > easy as you might think. As you want to have the possibilty to
> > exchange the *complete* flash data (that means not only an
> > application area) and the LPC's can not write into the flash memory
> > execting from you have to do as follows:
> >
> > You must write a so-called secondary bootloader, which is fully
> > running in RAM (image loaded from flash at power up). This secondary
> > bootloader can check the sanity of your application area and jump to
> > the application when everything is ok. If this is not the case it
> > must communicate with the "host" to get data and write it to flash
> > then and make a reboot finally (by not servicing the watchdog).
> >
> > To bring the bootloader into effect (itmormally does a santity check
> > of the app area only and the "terminates" by jumping to the app) you
> > could either do some minimal communication with the host before it
> > jumps to the app, or you let the app modify something in the flash
> > area checked by the bootloader via it's santity check to
> > force an update.
> >
> > Hope that helps to estimate the effort.
> >
> > Regards
> > Herbert
> >
> >The secondary bootloader can exist in flash, and does not need to be
>copied to RAM. Since you are making calls to the IAP routines to
>actually modify the flash, the bootload code will not be running.
>After the write has completed, a return to the flash bootload code
>is done, and all is well.
>
>Mike
>
Reply by ●June 1, 20082008-06-01
> -----Original Message-----
> From: l...
> [mailto:l...]On Behalf
> Of Herbert Demmel
> Sent: Sunday, June 01, 2008 2:27 PM
> To: l...
> Subject: RE: [lpc2000] REPROGRAMMING THE FULL FLASH MEMORY USING IAP
> THROUGH RS485 NETWORK
> Mike,
>
> the original poster Yaque was speaking about the FULL FLASH MEMORY (I
> don't want to shout, it's only copied from the subject line), so if
> he wants to do so, he has the need to overwrite the secondary
> bootloader as well: I'm not aware about any other posibilty to do so
> than to run it out of RAM.
>
> Herbret
You are correct, I missed that. Though, if he has to copy the bootloader
to RAM, then it must be in flash anyhow, so he might as well just
allocate a chunck of flash to the bootloader. This simplifies things
quite a bit, but the bootloader code has to be reliable, as it cannot
be easily replaced. But, then the upgrade is much safer if something
goes wrong, as you can try again. With code only existing in RAM,
things could go very wrong.
Mike
>
> At 14:06 01.06.2008 -0600, you wrote:
>
> > > -----Original Message-----
> > > From: l...
> > > [mailto:l...]On Behalf
> > > Of Herbert Demmel
> > > Sent: Sunday, June 01, 2008 1:07 PM
> > > To: l...
> > > Subject: Re: [lpc2000] REPROGRAMMING THE FULL FLASH
> MEMORY USING IAP
> > > THROUGH RS485 NETWORK
> > >
> > >
> > > Hi,
> > >
> > > basically it *is* possible to do what you want, but it's not that
> > > easy as you might think. As you want to have the possibilty to
> > > exchange the *complete* flash data (that means not only an
> > > application area) and the LPC's can not write into the
> flash memory
> > > execting from you have to do as follows:
> > >
> > > You must write a so-called secondary bootloader, which is fully
> > > running in RAM (image loaded from flash at power up).
> This secondary
> > > bootloader can check the sanity of your application area
> and jump to
> > > the application when everything is ok. If this is not the case it
> > > must communicate with the "host" to get data and write it to flash
> > > then and make a reboot finally (by not servicing the watchdog).
> > >
> > > To bring the bootloader into effect (itmormally does a
> santity check
> > > of the app area only and the "terminates" by jumping to
> the app) you
> > > could either do some minimal communication with the host before it
> > > jumps to the app, or you let the app modify something in the flash
> > > area checked by the bootloader via it's santity check to
> > > force an update.
> > >
> > > Hope that helps to estimate the effort.
> > >
> > > Regards
> > > Herbert
> > >
> > >
> >
> >The secondary bootloader can exist in flash, and does not need to be
> >copied to RAM. Since you are making calls to the IAP routines to
> >actually modify the flash, the bootload code will not be running.
> >After the write has completed, a return to the flash bootload code
> >is done, and all is well.
> >
> >Mike
> >
>
> From: l...
> [mailto:l...]On Behalf
> Of Herbert Demmel
> Sent: Sunday, June 01, 2008 2:27 PM
> To: l...
> Subject: RE: [lpc2000] REPROGRAMMING THE FULL FLASH MEMORY USING IAP
> THROUGH RS485 NETWORK
> Mike,
>
> the original poster Yaque was speaking about the FULL FLASH MEMORY (I
> don't want to shout, it's only copied from the subject line), so if
> he wants to do so, he has the need to overwrite the secondary
> bootloader as well: I'm not aware about any other posibilty to do so
> than to run it out of RAM.
>
> Herbret
You are correct, I missed that. Though, if he has to copy the bootloader
to RAM, then it must be in flash anyhow, so he might as well just
allocate a chunck of flash to the bootloader. This simplifies things
quite a bit, but the bootloader code has to be reliable, as it cannot
be easily replaced. But, then the upgrade is much safer if something
goes wrong, as you can try again. With code only existing in RAM,
things could go very wrong.
Mike
>
> At 14:06 01.06.2008 -0600, you wrote:
>
> > > -----Original Message-----
> > > From: l...
> > > [mailto:l...]On Behalf
> > > Of Herbert Demmel
> > > Sent: Sunday, June 01, 2008 1:07 PM
> > > To: l...
> > > Subject: Re: [lpc2000] REPROGRAMMING THE FULL FLASH
> MEMORY USING IAP
> > > THROUGH RS485 NETWORK
> > >
> > >
> > > Hi,
> > >
> > > basically it *is* possible to do what you want, but it's not that
> > > easy as you might think. As you want to have the possibilty to
> > > exchange the *complete* flash data (that means not only an
> > > application area) and the LPC's can not write into the
> flash memory
> > > execting from you have to do as follows:
> > >
> > > You must write a so-called secondary bootloader, which is fully
> > > running in RAM (image loaded from flash at power up).
> This secondary
> > > bootloader can check the sanity of your application area
> and jump to
> > > the application when everything is ok. If this is not the case it
> > > must communicate with the "host" to get data and write it to flash
> > > then and make a reboot finally (by not servicing the watchdog).
> > >
> > > To bring the bootloader into effect (itmormally does a
> santity check
> > > of the app area only and the "terminates" by jumping to
> the app) you
> > > could either do some minimal communication with the host before it
> > > jumps to the app, or you let the app modify something in the flash
> > > area checked by the bootloader via it's santity check to
> > > force an update.
> > >
> > > Hope that helps to estimate the effort.
> > >
> > > Regards
> > > Herbert
> > >
> > >
> >
> >The secondary bootloader can exist in flash, and does not need to be
> >copied to RAM. Since you are making calls to the IAP routines to
> >actually modify the flash, the bootload code will not be running.
> >After the write has completed, a return to the flash bootload code
> >is done, and all is well.
> >
> >Mike
> >
>
