The target files created by TI's new assembler and linker use a COFF (Common Object File Format), which is more conducive to modular programming and provides a powerful and flexible programming method for managing code segments and target system memory. Users can put link information in a file by writing a link command file (.cmd file) so that it can be called when the same link information is used multiple times. Two very useful pseudo-instructions MEMORY and SECTIONS are used in the command file to specify the memory structure and address mapping in actual applications. Memory is used to specify the target memory structure. The address space can be configured through the PAGE option under Memory. The linker treats each page as an independent storage space. Usually, PAGE0 represents the program memory for storing programs, and PAGE1 represents the data memory for storing data. The relocatable code and data blocks generated by the compiler are called "SECTIONS", which are used to control the composition and address allocation of segments. For different system configurations, the allocation method of "SECTION" is also different. The linker controls the address allocation through "SECTIONS", so the allocation of "SECTIONS" becomes an important part of configuring the .cmd file. The following is a detailed introduction to the definition and allocation of "SECTIONS".
(1)
Initialized "SECTIONS" (including data tables and executable code)
.text It includes all executable code and constants (different from constants) and must be placed in the program page;
.cinit It includes initialized external or static variables and constant tables, which are required to be placed in the program page; store initialized values
.pinit It includes variables and constant tables initialized by the global constructor (C++) and are required to be placed in the program page;
.const It includes strings, declarations, and explicitly initialized global and static variables, which are required to be placed in the low-address data page; this part is a constant, so it can be in the ROM of the data page. If const declaration is not used, it is stored in cinit. After running, it needs to be transferred from cinit in rom to bss in ram, occupying two storage spaces.
.econst It is used when using large memory mode, including strings, declarations, and explicitly initialized global and static variables, which can be placed anywhere in the data page.
.switch It includes a table set up for conversion declarations, which can be placed in the program page or in the low-address data page.
(2) Uninitialized "SECTIONS" (reserving space in memory for variables created and stored during program execution)
.bss It reserves space for global variables and static variables. When the program starts running, the C import path copies the data from the .cinit section and stores it in the .bss section, which is required to be placed in the data page with a low address;
.ebss It is used in far access (only for C) and large storage mode, and it reserves space for global variables and static variables. When the program starts running, the C import path copies the data from the .cinit segment and stores it in the .ebss section, which can be placed anywhere in the data page;
.stack reserves space for the C system stack. This part of the memory is used to pass declarations to functions and to reserve space for local variables, and is required to be placed in the data page with a low address;
.system reserves space for dynamic memory allocation. This space is used for the malloc function. If the malloc function is not used, the size of this segment is 0, and it is required to be placed in the data page with a low address;
.esystem dynamic memory allocation reserved space, this space is used for the external malloc function. If the external malloc function is not used, the size of this segment is 0, and it can be placed anywhere in the data page.
The content that can be stored in ROM or RAM is stored in RAM when using the emulator and in ROM when burning into the chip.
3. Give an example to illustrate the allocation method of .cmd file.
The following is the allocation of .cmd file when simulating and debugging the serial communication interface SCI, which has been well applied in TMS320F2812 simulation debugging.
Paging is artificial, describing the actual hardware resources, putting the memory for storing programs in PAGE0, and the memory for storing data in PAGE1
MEMORY
{PAGE0:
/*ProgramMemory*/
RAMH0: origin=0x3F8000, length=0x001000
RAML0: origin=0x008000, length=0x001000
RAML1: origin=0x009000, length=0x001000
ROM:
origin=0x3FF000, length=0x000FC0
RESET: origin=0x3FFFC0, length=0x000002M
VECTORS: origin=0x3FFFC2, length=0x00003EM
PAGE1: /*DataMemory*/
RAMM0: origin=0x000000, length=0x000400
RAMM1: origin=0x000400, length=0x000400
RAMH0: origin=0x3F9000, length=0x001000
,,,
}
Segment allocation: Allocate
SECTIONS according to the specific location and size of a segment
{/*Allocateprogramareas:*/
.cinit
:>RAMH0
PAGE=0
.pinit
:>RAMH0
PAGE=0
.text
:>RAMH0
PAGE=0
.reset
:>RESET,PAGE=0,TYPE=DSECT
Vectors :>VECTORS,PAGE=0,TYPE=DSEC
/*Allocateuninitalizeddatasections:*/
.stack
:>RAMM0
PAGE=1
.ebss
:>RAMH0
PAGE=1
.esysmem :>RAMH0
PAGE=1
.econst :>RAMM1
PAGE=1
.switch:>RAMM1
PAGE=1
,,,
}
In order to make full use of the 18k×16-bit SARAM, this example divides the high-address 8k×16-bit H0 SARAM into two parts, one part is used to store the program in PAGE0, and the other part is used to store data in PAGE1 to achieve reasonable allocation; the allocation of peripheral frames frame0, frame1, frame2, etc. in the actual simulation debugging process will not be introduced in detail due to space constraints.
|