External RAM working and memory management

Question

How can an external RAM be utilised with respect to an MCU that also has an internal RAM?

Can stack/heap etc. regions will be created in the external RAM?

How to link/execute functions in external RAM? (Keil 4 IDE)

Answer 1

The memory will be used in the manner defined in your scatter file or linker script - it has nothing particular to do with the MCU and internal/external RAM.

You describe the available physical memory regions on your platform in the scatter file (various toolchains may use different terms such as linker script), and assign attributes to each section to inform the linker what each memory may be used for and possibly explicitly locating certain code or data items to specific sections.

The linker will not locate anything in memory you have not informed it of. You may want to treat all memory in the same manner and give the linker free reign to allocate where it pleases, but in the case of an MCU this may not be optimal. For example the internal memory bus may be faster then the external, so you might constrain time-critical processing to that. If you let the linker allocate as it chooses, modifications to your code could change performance significantly if some critical object is moved to slower memory.

Even in internal RAM, the part may segment that into different regions with independent busses so that for example you might use a region specifically for DMA to reduce or eliminate bus contention.

So while some default linker script for your part provided by your tool chain may suit for general purposes, if you have complex memory requirements with internal, external, QSPI etc. running at different speeds and with different attributes, you may want to customise the script to make best use of the available resources.

In Keil specifically, you can assign basic memory region arrangements in the project configuration "Target" tab:

In this case you can add you external memory in the RAM1/2/3 fields.

For more complex requirements (such as creating named sections), in the linker tab: you need to un-check the "Use Memory Layout from Target dialog" box, and click "Edit" against the scatter file (or provide a new scatter file path). The default scatter file is that created by your settings in the target dialog, but now you have decoupled it so that you can customise it to your needs.

One thing to note is that often access to external memory requires correct configuration of an external memory controller (to assign bus pins and set correct bus timing for example). If the linker is to allocate use of such memory, it is important that the memory is configured in the run-time start-up code before application memory initialisation is performed by the C or C++ run-time start-up code. It is normally necessary at least initially for the system stack to be placed in internal memory, since the start-up code will need a stack probably before the external memory is initialised. It is possible to later move system the stack before the C runtime start, but if you are using an RTOS this may not be necessary since each task will have its own stack established after the external memory is working. Besides that on parts where the system stack is also the interrupt stack, you will want that to be in the fastest and most reliable (in the sense of availability) memory.

Another consideration is that architectures such as ARM Cortex-M have separate busses intended for code and data which allows them to fetch instruction and data simultaneously. If you place code in data RAM, you may significantly slow down execution as instruction and data fetches from the same memory must be performed sequentially. Coupled with the often lower bus speed of external memory, you may want to exercise caution in placing code for execution in external RAM (or in fact any RAM). On some parts - typically those with Von Neumann architectures, RAM execution is faster than execution from ROM, but for parts with Harvard architecture buses and Flash memory accelerators or caches, that is not necessarily the case. So don't assume there is a benefit to be had in locating code in external RAM.