Lpc2000

I forgot to mention few important points in my
previous email.

1. I favor Method-1. It had less overhead & also PIC
objects would run slightly slower & would take-up more
memory. Method-2 is useful in case of run-time loaded
module, OSes like Linux do that (Where modules get
loaded at random locations).
2. Method-1 (RISC architecture related issue): RISC
architectures (for instance ARM) have a limitation on
the Branching ability (The address range is
restricted). ARM7 can only branch within + or - 32MB.
If the Flash & RAM are more than 32MB apart then, the
function call cannot be made just like another normal
function (linker would complain about the long
branch). In such a case the call should be made using
function pointers.

Cheers,
-Mike.

--- Michael Anburaj <embeddedeng@...> wrote:
> Arvid,
> 
> As somebody said it depends on the tool-chain.
> 
> Method 1: Different Load & execute address (liner
> script method)
> 
> ARM tools (ADS or SDT):
> 
> Create a scatter map file much like the following:
> 
> flash 0x00000000 0x00020000
> {
> 	TEXT +0
> 	{
> 		*(+RO)
> 	}
> 
> 	LOADTEXT 0x40001000
> 	{
> 		flashlib.o
> 	}
> }
> 
> Where LOADTEXT is the section which will contain the
> flashlib.o object (The object which you want to run
> out of RAM). Now that in the link step use this
> scatter map & the linker would link this object
> (flashlib.o) for RAM address 0x40001000, but load it
> in flash following the .text (or) RO regions of
> other
> objects when creating the executable
> (elf/axf/bin/hex/srec).
> 
> And the linker (ADS or SDT) would provide the
> following run-time variables. And it is the
> responsibility of the run-time code/writer to move
> the
> code from ROM to RAM:
> 
> Load$$LOADTEXT$$Base        -- Address in ROM
> Image$$LOADTEXT$$Base       -- Address in RAM
> Image$$LOADTEXT$$Length     -- Length to be copied
> 
> These variables should be used to copy the code from
> flash to RM at run-time (done either at the startup
> assembly code or in C code initializing this
> library).
> 
> And you call the function just like any other
> function. And the call will be made to the copied
> location in RAM
> 
> myflashlibfunction(); /* this should call the
> function
> in RAM */
> 
> The same idea can be used in GCC using linker
> scripts.
> 
> 
> Method 2: PIC (position independent code)
> 
> 1. compile this particular code (which needs to run
> out of RAM) as PIC -- check the right flags in the
> compiler manual.
> 
> 2. Then just as you explained, do the things to move
> the code to RAM. Since, its PIC code, it can run
> from
> any location.
> 
> Call the function as someone explained -- using
> function pointers.
> 
> Cheers,
> -Mike.
> 
> --- ateichtmann <arvid_teichtmann@...> wrote:
> > 
> > Hi,
> > 
> > for an in-system update of the firmware i have the
> > following idea:
> > 1. store the new firmware in an external serial
> > flash
> > 2. allocate memory in RAM with malloc() for the
> > update function
> > 3. copy update-function from ROM to RAM
> > 4. call update-function in RAM
> > 5. update-function copies firmware from external
> > serial flash to 
> > internal flash with IAP commands
> > 
> > My question is, how code can be executed in RAM.
> > How can i call a function in RAM?
> > Thanks for all hints.
> > 
> > Regards
> > Arvid
> > 
> > 
> > 
> > 
> > 
> 
> 
> 		
> __________________________________ 
> Do you Yahoo!? 
> Yahoo! Small Business - Try our new resources site!
> http://smallbusiness.yahoo.com/resources/ 
> 

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