> Is there a more elegant solution than adding a dummy function?
> Can I search the next RET instruction or something like this?
>

More elegant (and more reliable, if you've got heavy optomisations enabled
on newer gcc) is to put your function in the initialised data section:

void __attribute__ ((section ("data"))) prog_function(void) { ... }

This results in the function being compiled normally, and linked with an
address in the data section in ram.  The actual code, however, is placed in
flash along with other initialisers such as "int default = 1;", and it is
copied over to ram by the startup code in the same way.

You can then call this function directly from other code, since the link
address is in ram.  You can even step through it and add breakpoints while
debugging.  There are no problems about using parameters or return values,
nor about using as many such functions as you need (and they can be placed
anywhere in your source).

There are a couple of issues to consider, however - make sure no library
routines or other functions are called (unless they are also in "data"), and
make sure that interrupts are switched off during programming (since they
require flash access).

I haven't tried this on an msp430, but I've used the same arrangement on
other systems.

mvh.,

David





> ----------------------------
>
> I think something like (be sure to check the syntax, I'm typing this
> from
> memory!):
>
> unsigned char *rampointer;
>
>
> void prog_function()
> {
> ...function...
> }
>
> void next_to_prog_function()
> {
> //dummy function
> }
>
> memcpy(rampointer, progfunction, next_to_prog_function-prog_function);
> (void*())(rampointer)(); //execute function from ram
>
> Rampointer is the pointer to the memory area (make sure you initialize
> this). prog_function is the function you want to copy to ram.
> next_to_prog_function is a dummy function which identifies the end of
> prog_function. Don't forget function names are pointers to their
> function
> in C.
> You should also consider what to do when programming is finished.
> Probably
> a call to the reset vector. It is a good idea to make a function which
> blinks an LED and runs this from RAM first.
>
> Nico Coesel
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon
> 2005
> Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
> Embedded(r) & Windows Mobile(tm) platforms, applications & content.
> Register
> by 3/29 & save $300 http://ads.osdn.com/?ad_idh83&alloc_id149&op=ick
> _______________________________________________
> Mspgcc-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 3/21/2005
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 3/21/2005
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
> Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
> Embedded(r) & Windows Mobile(tm) platforms, applications & content.
Register
> by 3/29 & save $300
http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
> _______________________________________________
> Mspgcc-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
>
>



Reply via email to