Ok, the situation is quite different.
1. You are lucky if you may have double flash space for your program.
2. If 1. is correct then you may copy the old program on space 2 and
then program new program on space 1.
3. I think that you have to do a different thing, my bootloaders don't
permit to loose the bootloader itself and may recover a failed download.
So I think that these are secured steps:
when you need to program the mcu you have to:
a) if you have some data that you can't loose on ram you have to
backup them (if you use a serial port you may transfer ram content to
the PC)
b) you have to store the original program (may be also in the PC or
in spare flash area)
c) you have to write the new program in flash (possibly you have to
inform the bootloader about the program length and its CRC or checksum
to verify correctness)
d) the download process have to be flow controlled and end
controlled, at the end the bootloader have to reload the eventually
saved ram and then jump to reset.
In this way you need only a small amount of ram and of reserved to the
bootloader. If there is any error bootloader may reload the original
program or may rest the board without restore the ram and then the board
will restart with the bootloader running.
Leighton Rowe wrote:
> Hey there Massimo,
>
> Your reply was very helpful as I'm looking to write a bootloader
> component to update user code. You might be able to help me with
> this problem:
>
> Let's say I have Flash Memory set up like below.....
>
> ---------------------------
> User Program (space 2) | --assume empty
> ---------------------------
> User Program (space 1) | --holds original code
> ---------------------------
> Interrupt Block |
> (includes Handler + ISRs) |
> ---------------------------
> Software Bootloader Block |
> ---------------------------
> Reset Block |
> (Interrupt Jumps) |
> + initializer routines |
> ---------------------------
>
> After downloading newer version code to space 2, what must be done
> to make the system execute from space 2 instead of space 1?
>
> thanks in advance,
> Leighton
>
>
>
> --- In lpc2000@yahoogroups.com, Micron Engineering <micronpn@t...>
> wrote:
> > Ok, then if you need to write a bootloader it is a different thing.
> > 1. Start studing the possibility to use LPC way to program the
> flash
> > with ISP bootloader and/or using JTAG
> > 2. If the previous approach doesn't work for you, you have
> basically to
> > store in flash your bootloader (but it is compiled to work
> residing in ram)
> > and then when you need to program the flash:
> > - copy bootloader code in ram
> > - start executing code from ram
> > - use some space in ram to collect data to program on flash (a
> block
> > multiple i.e. 2KB)
> > - program flash coping data from ram to flash
> > - provide a communication protocol with some arbitration because
> write
> > to flash takes some time
> > - provide the communication protocol with a command to reset the
> LPC
> > - provide a timeout in bootloader code to automatically reset the
> LPC if
> > no data received for more then x milliseconds.
> > I wrote some bootloaders for various microcontrollers to use
> different
> > interfaces to program microcontrollers or flash chips working in
> this
> > way and they perform very well. May be that you also require some
> sort
> > of ram backup and some sort of security if the programming
> procedure
> > stops before the end (i.e. power failure). Due t the big ram space
> on
> > LPC microcontrollers may be not so difficult to obtain these
> goals.
> > Remember that ARM7 is a RISC microcontroller with no different
> address
> > space for data and code, so you have only to write a relocatable
> program.
> > Best regards,
> > Massimo Manca, Micron Engineering
> >
> > gilles_baracoda wrote:
> >
> > > Actually what I would like to do is upgrade the code of the
> MCU...so
> > > I have no choice but writing the internal flash!
> > >
> > > Thanks for the reply anyway.
> > > Regards,
> > >
> > > Gilles
> > >
> > > --- In lpc2000@yahoogroups.com, Micron Engineering
> <micronpn@t...>
> > > wrote:
> > > > I think that if you haven't a lot of data to write it is more
> > > simple and
> > > > time efficient to use a simple I2C eeprom or an SPI eeprom
> > > external
> > > > connected to the LPC. Flash programming generally is used to
> write
> > > > calibration data and so on during production or calibration not
> > > many times.
> > >
> > >
> > >
> > > Yahoo! Groups Sponsor
> > > ADVERTISEMENT
> > >
> <http://us.ard.yahoo.com/SIG=1292cceqj/M=298184.5022502.6152625.30011
> 76/D=groups/S=1706554205:HM/EXP=1087461081/A=2164331/R=0/SIG=11eaelai
> 9/*http://www.netflix.com/Default?mqso=60183351>
> > >
> > >
> > >
> > > -----------------------------------------------------------------
> -------
> > > Yahoo! Groups Links
> > >
> > > * To visit your group on the web, go to:
> > > http://groups.yahoo.com/group/lpc2000/
> > >
> > > * To unsubscribe from this group, send an email to:
> > > lpc2000-unsubscribe@yahoogroups.com
> > > <mailto:lpc2000-unsubscribe@yahoogroups.com?
> subject=Unsubscribe>
> > >
> > > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> > > Service <http://docs.yahoo.com/info/terms/>.
> > >
> > >
>
>
> Yahoo! Groups Sponsor
> ADVERTISEMENT
> <http://us.ard.yahoo.com/SIG=1298i2qb7/M=295196.4901138.6071305.3001176/D=groups/S=1706554205:HM/EXP=1087480471/A=2128215/R=0/SIG=10se96mf6/*http://companion.yahoo.com>
>
>
>
> ------------------------------------------------------------------------
> Yahoo! Groups Links
>
> * To visit your group on the web, go to:
> http://groups.yahoo.com/group/lpc2000/
>
> * To unsubscribe from this group, send an email to:
> lpc2000-unsubscribe@yahoogroups.com
> <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>
> * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> Service <http://docs.yahoo.com/info/terms/>.
>
>Message
Re: [lpc2000] Re: IRQ vector and handlers relocation
2004-06-16 by Micron Engineering
Attachments
- No local attachments were found for this message.