I use the LPC1768 board and I want to copy a function from flash to RAM in runtime. I use the following code
void f() { int x=0; printf("%d\n",x); } void g() { int x=5; printf("Hello: g"); printf("%d\n",x); } int main(void) { char c; static void (*fnRAM_code)(void) = &f; int offset= (int)((long)g-(long)f); int i=0; int z=0; int *x; extern void uart0_init(void); unsigned char *pCodeStart = (unsigned char *)f;
uart0_init();
//(*fnRAM_code)();
//thump2 addresss /* Thumb 2 address */ pCodeStart = (unsigned char *)(((unsigned int)pCodeStart) & ~0x1); while (i < PROG_SIZE) { ProgRamSpace[i] = pCodeStart[i]; i++;
} (*fnRAM_code)(); fnRAM_code = (void(*)(void))(ProgRamSpace); (*fnRAM_code)(); }
But when I access the new address of the function I get the following error access violation at 0x100000018: no execute /read permision. Can anyone provide a solution for this issue Best regards, George
The scatter file is the following ; ************************************************************* ; *** Scatter-Loading Description File generated by uVision *** ; *************************************************************
LR_IROM1 0x00000000 0x00080000 { ; load region size_region ER_IROM1 0x00000000 0x00080000 { ; load address = execution address *.o (RESET, +First) *(InRoot$$Sections) .ANY (+RO) } RW_IRAM1 0x10000000 0x00008000 { ; RW data .ANY (+RW +ZI) } }
It's real hard to determine the size of a compiled function and it's literal pool, or the relative position to branch to external subroutines, etc.
Thumb code needs to be copied to 16-bit half-word address, but execution will be at an ODD address, nominally the base address you copied to plus one.
The RAM may, or may not, permit execution, don't know about NXP/LPC, but others fault at 0x10000000, but work at 0x20000000
Try a little assembler code fragment that sets R0 with a value and returns, and print the result from that.
Thank you for the prompt reply, Yes I know that is very hard and maybe does not work in this way. For this reason I have an really small f function. Then, I have already checked the instructions that are saved in the ProgRamSpace and seems to be correct. The problem as I explain above is that the function can not execute in this memory space Your point is to allocate the ProgRamSpace in the address 0x20000000, is this? Thank you George
I have already check this in address 0x20000000 and does not works. When access the function pointer that indicates to the buffer, that are saved the instructions a HardFault exception is triggered The scatter file LR_IROM1 0x00000000 0x00080000 { ; load region size_region ER_IROM1 0x00000000 0x00080000 { ; load address = execution address *.o (RESET, +First) *(InRoot$$Sections) .ANY (+RO) } RW_IRAM1 0x20000000 0x00008000 { ; RW data .ANY (+RW +ZI) } } George
As I said, I know very little about the NXP/LPC part, would have to research addresses and if core design permits execution from RAM, or requires remapping, so more generically
#include <stdio.h> #include <string.h> typedef int (*pFunction)(void); void ExecuteFromRAM(void) { static const uint16_t CodeStart[] = { 0xF04F, 0x007B, 0x4770 }; // function, in ROM uint8_t ProgRamSpace[16]; // as big as required, here on stack pFunction fnRAM_code; memcpy(ProgRamSpace, CodeStart, sizeof(CodeStart)); // Copy code fnRAM_code = (pFunction)&ProgRamSpace[1]; // +1 for Thumb code printf("%d\n",fnRAM_code()); }
Why not let the linker place the function in RAM? Then the startup code will perform the copy of the code from flash into RAM and all references to that function will make use of the RAM address.
The datasheet for the processor contains information which memory regions that supports code execution, DMA transfers etc.
Clearly there are many solutions to the problem, but the problem is multifaceted and one really has to understand the requirements and ramification very precisely.
If you start calling functions, or libraries from RAM based code you need to make sure everything in the call tree is brought there too, if the goal is to modify or erase flash, or other things that would preclude running from flash, or would cause significant stalling of execution.
IAR has a directive like 'ramfunc' in Keil I think you need to use attributes, sections and scatter files, I've made that work in the past too, but don't have my example to hand.
If reprogramming a flash, then it's often best to create a self-contained piece of assembler code to run in RAM to make really sure there aren't any hidden helper functions that gets referenced from flash.
But if the goal is to use RAM for additional speed, like critical ISR or evaluation code, then it works well to just make use of the scatter file.
Here I put a whole object file in RAM, but you can do so on a section or function basis also. http://www.keil.com/forum/24821/
Hello, Thanks for the sample. It is very useful George