SPRUI03E June 2015 – January 2023
Consider an application that contains a memory overlay that must be managed at run time. The memory overlay is defined using a UNION in the linker command file as illustrated in Using a UNION for Memory Overlay:
SECTIONS
{
...
UNION
{
GROUP
{
.task1: { task1.c.obj(.text) }
.task2: { task2.c.obj(.text) }
} load = ROM, LOAD_START(_task12_load_start), SIZE(_task12_size)
GROUP
{
.task3: { task3.c.obj(.text) }
.task4: { task4.c.obj(.text) }
} load = ROM, LOAD_START(_task34_load_start), SIZE(_task_34_size)
} run = RAM, RUN_START(_task_run_start)
...
}The application must manage the contents of the memory overlay at run time. That is, whenever any services from .task1 or .task2 are needed, the application must first ensure that .task1 and .task2 are resident in the memory overlay. Similarly for .task3 and .task4.
To affect a copy of .task1 and .task2 from ROM to RAM at run time, the application must first gain access to the load address of the tasks (_task12_load_start), the run address (_task_run_start), and the size (_task12_size). Then this information is used to perform the actual code copy.