[quote user="George Mock"]The idea is to apply the HIGH location specifier to all the uninitialized sections.[/quote]I modified the linker command file for my example which previously showed the problem of the large bin file to be:
-stack 0x0008 /* SOFTWARE STACK SIZE */ -heap 67108864 /* HEAP AREA SIZE */ -e Entry /* Since we used 'Entry' as the entry-point symbol the compiler issues a */ /* warning (#10063-D: entry-point symbol other than "_c_int00" specified: */ /* "Entry"). The CCS Version (5.1.0.08000) stops building from command */ /* line when there is a warning. So this warning is suppressed with the */ /* below flag. */ --diag_suppress=10063 /* SPECIFY THE SYSTEM MEMORY MAP */ MEMORY { DDR_MEM : org = 0x80000000 len = 0x7FFFFFF /* RAM */ IRAM_MEM : org = 0x40300000 len = 0x000FFFF /* RAM */ } /* SPECIFY THE SECTIONS ALLOCATION INTO MEMORY */ SECTIONS { // for relocation GROUP { IRAM_CODE : { } IRAM_DATA : { } }load=DDR_MEM, run=IRAM_MEM, START(iram_start), SIZE(iram_size), RUN_START(relocstart) .text:Entry : load > 0x80000000 .text : load > DDR_MEM /* CODE */ .data : load > DDR_MEM /* INITIALIZED GLOBAL AND STATIC VARIABLES */ .bss : load > DDR_MEM(HIGH) /* UNINITIALIZED OR ZERO INITIALIZED */ /* GLOBAL & STATIC VARIABLES */ RUN_START(bss_start) RUN_END(bss_end) .const : load > DDR_MEM /* GLOBAL CONSTANTS */ .stack : load > 0x87FFFFF0 /* SOFTWARE SYSTEM STACK */ .sysmem: load > DDR_MEM(HIGH) } With the changes to use DDR_MEM(HIGH) as suggested the size of the generated .bin file reduced from >64 Mbytes to 209 Kbytes. The linker command file shows that the initialized sections have been allocated consecutive addresses in DDR_RAM:
[quote]SEGMENT ALLOCATION MAP
run origin load origin length init length attrs members
---------- ----------- ---------- ----------- ----- -------
40300000 80033f90 00000018 00000018 r-x
40300000 80033f90 00000018 00000018 r-x IRAM_CODE
40300018 80033fa8 00000004 00000000 rw-
40300018 80033fa8 00000004 00000000 rw- IRAM_DATA
80000000 80000000 00033f90 00033f90 r-x
80000000 80000000 000000d4 000000d4 r-x .text:Entry
800000d4 800000d4 0002707e 0002707e r-- .const
80027154 80027154 0000ce3c 0000ce3c r-x .text
80033fac 80033fac 00000140 00000140 rw-
80033fac 80033fac 00000140 00000140 rw- .data
83ef4000 83ef4000 00109e10 00000000 rw-
83ef4000 83ef4000 00109e10 00000000 rw- .bss
83fffff0 83fffff0 04000008 00000000 rw-
83fffff0 83fffff0 04000000 00000000 rw- .sysmem
87fffff0 87fffff0 00000008 00000000 rw- .stack[/quote][quote user="George Mock"]The .data section is uninitialized in EABI builds.[/quote]Are you sure about that?
The StarterWare game example used was set to EABI, and with TI ARM compiler 5.1.3 the .data section is shown as initialized in the Segment Alocation Map - and so to avoid a large .bin file size I had to use ".data : load > DDR_MEM" in the linker command file.
[quote user="George Mock"] I will try to get a StarterWare expert to comment on this thread.[/quote]
Also, the StarterWare linker command files set the size of the .stack segment to only 8 bytes. With the above modified the linker command file the .sysmem segment is adjacent to the .stack segment. Need to check if that will cause the stack to corrupt the .sysmem segment (heap). It would be useful if a StarterWare expert could also comment on how the stack is used. i.e. was the stack set to 8 bytes at the top of memory with the assumption that the stack would grow downwards and that there wouldn't be any other memory used below the initial stack location?