Hello Fabien,
> but when I make a software reset there is an : " Exception vector name: Adresse error".
Does the error occur even before you enable interrupts? If so, then I'd suggest looking at the first two 32 bit words of your default VBR (at address 0), where your initial SP and PC are stored... Note that once you are running, your code might move the VBR to RAM (but those words are not read again).
> First what is "RAM_CODE_PAGE"
It is just a 2k byte buffer anywhere in RAM. It can be smaller than 2k bytes for this purpose (just big enough to hold the memcpy()'d function), but I use it for other purposes as well.
> do you need to erase the RAM before to copy the code in RAM ?
Nope, the memcpy() will overwrite it. Note that you should be able to step into the RAM copy of the function just fine with the debugger and see what it is doing. That function has to be carefully constructed to not generate "relocations", since it is running from a different address (in RAM) than where it was compiled/linked (in FLASH) for... So the function cannot call other functions, for example (you can use #defines to essentially inline other functions, however).
> For my application, I need to use all the flash so I have put the new code I
> want to program in an external memory flash and then I want to program
> the code I read in the external flash in the internal flash.
> so my problem is that I need to use more than one function
Ah, you have to use more than one function because you need to read the external flash via SPI? Yes, that makes it harder. You might be able to use "position independent code", either from a #pragma or from the compiler options, but I have never done this. The problem is that by default, a function call will use an absolute address... So if foo() calls boo(), and you copy both foo() and boo() to RAM, when you run foo(), it will call the *original* boo(), in FLASH, rather than the one in RAM -- and the copy in flash might have been obliterated already by the update... You might be able to also patch the assembly language, but that is a lot of work as well...
I would probably suggest you try putting all the functions you want to use (including flash and SPI functions) in a single file, in the order they are referenced, and asking the compiler to explicitly inline them all... That *might* give you one huge function with no relocations -- you can use the "disassemble" option on the source file in the project pane to test this... Or you can do #define ugliness (by using #defines to implement your SPI functions) to make the whole thing one real function -- that will work, but it may be ugly...
> Can I use data which are in RAM during I am programming the flash ?
Yes, since RAM data won't change addresses even if you copy the functions to RAM... Be really careful to make sure that you disable interrupts before transferring control to the RAM functions, as that will wreak havoc on things if you do not...
> Which file it is better to use to reprogram the flash .bin or .s19 ?
-- Rich