Lpc2000

Hello everyone,
 
I am executing my program from flash memory, but I would like to relocate the IRQ vector and the code of the handlers (uart0_handler, timer0_handler,...) in RAM, so I won't miss incoming data from the UART while writing the internal flash using IAP routines.
 
I am using the GNU toolchain, but I couldn't find examples or documents about how to achieve this.
 
The parts I would like to relocate (IRQ vector + handlers) are written in assembly (actually it is Ashling's startup code for EVBA7), in the same section as the other vectors (reset, undef,...).
 
Do I have to relocate them all (vectors + code)? But then, the reset vector won't be anymore at address 0, and the code won't run after a hardware reset?
 
Does anyone know how to do this?
 
Thanks a lot,
 
Gilles
 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

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.

Gilles B wrote:

> Hello everyone,
>  
> I am executing my program from flash memory, but I would like to 
> relocate the IRQ vector and the code of the handlers (uart0_handler, 
> timer0_handler,...) in RAM, so I won't miss incoming data from the 
> UART while writing the internal flash using IAP routines.
>  
> I am using the GNU toolchain, but I couldn't find examples or 
> documents about how to achieve this.
>  
> The parts I would like to relocate (IRQ vector + handlers) are written 
> in assembly (actually it is Ashling's startup code for EVBA7), in the 
> same section as the other vectors (reset, undef,...).
>  
> Do I have to relocate them all (vectors + code)? But then, the reset 
> vector won't be anymore at address 0, and the code won't run after a 
> hardware reset?
>  
> Does anyone know how to do this?
>  
> Thanks a lot,
>  
> Gilles
>  
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> Yahoo! Groups Sponsor
> ADVERTISEMENT
> <http://us.ard.yahoo.com/SIG=1298hm3kj/M=295196.4901138.6071305.3001176/D=groups/S=1706554205:HM/EXP=1087460412/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/>.
>
>

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.

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.3001176/D=groups/S=1706554205:HM/EXP=1087461081/A=2164331/R=0/SIG=11eaelai9/*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/>.
>
>

Thanks Massimo.

Does anyone know where to find examples or documentations about code 
relocation? I am using arm-elf tools.

Gilles

--- 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.300117
6/D=groups/S=1706554205:HM/EXP=1087461081/A=2164331/R=0/SIG=11eaelai9/
*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/>.
> >
> >

At 08:31 AM 6/16/04 +0000, you 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,

Partly as a matter of curiosity, why not use the standard serial 
download?  Are you adding restrictions?  (I presume you are using the 
serial port simply since you are concerned about preserving the interrupt).

Hmmm, It just occurred to me.  Check the docs, there is a very good chance 
interrupts must be disabled during flash programming.  Preserving 
interrupts might not be worth the trouble.

Robert


" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

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/>.
> >
> >

At 01:54 PM 6/16/04 +0000, you wrote:
>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?

In the abstract it's simple, your reset block must distinguish between the 
two code areas and determine which one to use (maybe by using a patch table 
or some similar mechanism).  You could use some sort of sequence, version, 
date or even a HW switch to choose.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

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/>.
>
>

--- In lpc2000@yahoogroups.com, Gilles B <gilles_baracoda@y...> wrote:
> Hello everyone,
>  
> I am executing my program from flash memory, but I would like to 
relocate the IRQ vector and the code of the handlers (uart0_handler, 
timer0_handler,...) in RAM, so I won't miss incoming data from the 
UART while writing the internal flash using IAP routines.
>  
> I am using the GNU toolchain, but I couldn't find examples or 
documents about how to achieve this.
>  
> The parts I would like to relocate (IRQ vector + handlers) are 
written in assembly (actually it is Ashling's startup code for 
EVBA7), in the same section as the other vectors (reset, undef,...).
>  
> Do I have to relocate them all (vectors + code)? But then, the 
reset vector won't be anymore at address 0, and the code won't run 
after a hardware reset?
>  
> Does anyone know how to do this?
>  
> Thanks a lot,
>  
> Gilles
>  


I have an application where I need to reprogram application code from 
an MMC multimedia card.

The solution I've found is to have a flash programmer in the first 
sectors of flash which runs on reset. I then use the IAP commands to 
erase and write the application code I read off the MMC card. The 
application code is compiled to run from a set sector start.

Once programming is finished I copy the vector table from the 
application software into ram, remap the vector table to ram and jump 
to the start of the application code.

It works for me.