Locating code and data in memory (Scatterloading)

In most embedded systems, the code and data for an application will be permamently stored in non-volatile memory (e.g. ROM or Flash) so that it is available for execution at the moment of power-up. Normally though, parts of this code and data (e.g. interrupt handlers, global variables) will need to be copied from the non-volatile memory into volatile memory (RAM) in order for the application to be able to execute correctly. In ADS this is done using the linker's scatterloading mechanism.

     Scatterloading allows you to partition an application into a number of separate code and data regions spread throughout the address map. The location of these regions can differ between load time and run time:

1) Load Regions contain application code and/or data used by the application at power-on/load time (typically ROM).

2) Execution Regions are used by the application whilst it is executing.

     The details of the memory map used by a scatterloaded application are contained in a description file which is passed as a parameter to armlink. The benefit of using a scatter description file is that all the (target-pecific) absolute addresses chosen for your devices, code and data are located in one file, making maintenance easy. Furthermore, if you decide to change your memory map (e.g. if peripherals are moved), you do not need to rebuild your entire project - you only need to re-link the existing objects.

     Within a scatter description file, a load region is represented by the outer set of braces, and this can contain a number of execution regions (the inner braces). Execution regions can be /'rooted/' (executed at their load address), or non-rooted (copied at run-time) regions. Consider the following typical example:

LOAD_FLASH 0x04000000 0x80000      ; start address and length

{

     EXE_FLASH 0x04000000 0x80000

     {

         init.o (Init, +First)      ; Put this area first in region

         * (+RO)                      ; wildcard to collect all other RO

     }

     32bitRAM 0x0000 0x2000

     {

         vectors.o (Vect, +First)   ; Put this area first in region

         int_handler.o (+RO)

     }

     16bitRAM 0x2000 0x80000

     {

         * (+RW,+ZI)                      ; wildcard to collect RW & ZI

     }

}

     This defines one load region (LOAD_FLASH), and three execution regions (EXEC_FLASH, 32bitRAM, 16bitRAM):

      The exception vectors (in vectors.s) and exception handlers (in int_handler.c)  are relocated to 32bitRAM at address 0 (for speed)

      The RW variables are copied from Flash to the 16bitRAM at address 0x2000

      The ZI data will follow the RW data in the 16bitRAM

      All other code (init, main program, libraries, etc) does not need to be relocated, so just runs from the Flash.

     Note that one key point to remember is that the ordering of objects in the scatter file does not affect their ordering in the output image. Within each region, the linker collects together input sections with the same attribute (RO, RW or ZI). The basic placement rule for sections within a region is: RO sections precede RW sections which precede ZI sections. Within this ordering, sections will be ordered:

     by attribute (e.g RO-Code before RO-Data), then by name, then by the order they were specified on the armlink command line.

     A section may be placed first or last in an execution region using +FIRST and +LAST, e.g. to place a checksum at the end of a region (as long as this does not break the basic placement rules). It should also be noted that if a system implements ROM/RAM remapping (i.e. ROM is aliased to 0x0 at reset, but RAM is at 0x0 during normal execution), then the descriptor file should describe the memory map after remapping has occurred.

For more details of scatterloading please see:

ADS 1.0 - Tools Guide, Chapter 6, "The ARM linker" and Developer Guide, Chapter 7, "Writing Code for ROM"

ADS 1.1 - Compiler, Linker & Utilities Guide, Chapter 5, "The ARM linker" and Developer Guide, Chapter 6, "Writing Code for ROM"