Placing Code in RAM
On most modern MCUs with built-in flash memory, code is normally executed directly from the flash. MCU vendors implement various techniques, such as prefetch buffering, to ensure that code will execute with minimal or zero wait states, even a higher clock frequencies. Please see the documentation for the MCU that you are using for more details.
Occasionally though, there can be advantages to relocating small, time critical functions so that they run out of RAM instead of flash memory. The simplest way to do this is actually to treat the section containing your RAM function(s) as data, and then the standard startup code should copy them into RAM for you!
The attached zipfile contains an example project for the LPC1114/301 shows the basic principle. You will need to import this into a workspace which contains the CMSISv1p30_LPC11xx library project.
When building this code, you may see an error of the form:
Warning: ignoring changed section attributes for .data
This is because you are placing your code into a data section, which by default does not expect to have the attributes associated with code. As this is what you intend you can ignore the warning. If the warning is a concern, then you will have to avoid the trick of placing the code into a data section, and instead modify your linker script and initialisation code to cope with placing/copying the code into ram yourself.
Long branch veneers and debugging
Due to the distance in the memory map between flash memory and RAM, you will typically require a "long branch veneer" between the function in RAM and the calling function in flash. The linker can automatically generate such a veneer for direct function calls (though Cortex-M0 users should see the note below), or you can effectively generate your own by using a call via a function pointer.
One point to note is that debugging code with a linker generated veneer can sometimes cause problems. This veneer will not have any source level debug information associated with it, so that if you try to step in to a call to your ram code, typically the debugger will step over it.
You can work around this by single stepping at the instruction level, setting a breakpoint in your RAM code, or by changing the function call from a direct one to a call via a function pointer.
Important note for Cortex-M0 users
There is an issue with the linker used by Code Red IDE v3 which causes an incorrect long branch veneer to be generated for Cortex-M0 parts (such as LPC11xx and LPC12xx). When executed this will cause a hard fault. The workaround for this is always to call between code in RAM and flash via function pointers (and the function pointer must be a global, otherwise problems will still be encountered when the compiler has optimisation turned on).
The linker used by Code Red IDE v4 does not have this problem, so either direct calls or calls via (global or local) function pointers can be used.