SPNU118Z September 1995 – March 2023 66AK2E05 , 66AK2H06 , 66AK2H12 , 66AK2H14 , AM1705 , AM1707 , AM1802 , AM1806 , AM1808 , AM1810 , AM5K2E04 , OMAP-L132 , OMAP-L137 , OMAP-L138 , SM470R1B1M-HT , TMS470R1A288 , TMS470R1A384 , TMS470R1A64 , TMS470R1B1M , TMS470R1B512 , TMS470R1B768
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.