Compiler/CC1310: Linker Wasting Space for SysBios on CC1310

Chris Carter

Part Number: CC1310
Other Parts Discussed in Thread: SYSBIOS

Tool/software: TI C/C++ Compiler

This may belong in a different forum, but here is what I'm seeing:

I've reserved the top two pages for application use in my memory map : (condensed cmd file)

#define FLASH_BASE              0x0
#define FLASH_SIZE              0x6000

#define APPFLASH_LENGTH		0x2000
#define APP_FLASH_BASE		0x6000

/* System memory map */

MEMORY
{
    /* Application stored in and executes from internal flash */
    FLASH (RX) : origin = FLASH_BASE, length = FLASH_SIZE
    /* App Flash */
    AppFlash(RW) : origin = APP_FLASH_BASE, length = APPFLASH_LENGTH

My program compiles and is smaller 24k (using CC1310F32RHB), but I get an error saying my .text section won't fit in available flash. When I look at my allocation map, the linker appears to be wasting almost an entire page of flash reserving space for sys bios.

SEGMENT ALLOCATION MAP

run origin load origin length init length attrs members
---------- ----------- ---------- ----------- ----- -------
00000000 00000000 0000003c 0000003c r--
00000000 00000000 0000003c 0000003c r-- .resetVecs
00000000 00000000 00004c48 00004c48 r-x
00000000 00000000 00004c48 00004c48 r-x .text
0000003c 0000003c 00000164 00000164 r--
0000003c 0000003c 00000164 00000164 r-- .const
000001a0 000001a0 0000020c 0000020c r--
000001a0 000001a0 0000020c 0000020c r-- .cinit
00001000 00001000 000004f0 000004f0 r--
00001000 00001000 0000003c 0000003c r-- .const:ti_sysbios_knl_Task_Object__PARAMS__C
0000103c 0000103c 00000034 00000034 r-- .const:ti_sysbios_knl_Mailbox_Object__PARAMS__C

Is it possible to move the ti objects, or place other objects between 20C and 1000?

over 9 years ago

0 Alan DeMars over 9 years ago

TI__Mastermind 30830 points

The "ti_sysbios_xxx" objects that begin at 0x1000 are being referenced by ROM code and therefore can not be moved. I don't see why the linker can't place stuff between 0x20c and 0x1000. The .map file does indicate that the .text section begins at 0x0 and is 0x4c48 bytes in length. Are you there are no pieces of code placed between 0x20c and 0x1000? At the bottom of the .map file is a list of symbols in order of their value. Check there.

You may need to put this question to a different forum.

Alan

0 Chris Carter over 9 years ago in reply to Alan DeMars

Expert 1030 points

Thanks for the feedback. I'll try and create a separate region and move some of my functions in there.

If i manually adjust the flash size to allow the compiler to succeed this is what the map file looks like (still a huge gap):
SEGMENT ALLOCATION MAP

run origin load origin length init length attrs members
---------- ----------- ---------- ----------- ----- -------
00000000 00000000 000004e4 000004e4 r--
00000000 00000000 0000003c 0000003c r-- .resetVecs
0000003c 0000003c 00000164 00000164 r-- .const
000001a0 000001a0 00000344 00000344 r-- .cinit
00001000 00001000 00005138 00005138 r-x
00001000 00001000 0000003c 0000003c r-- .const:ti_sysbios_knl_Task_Object__PARAMS__C
0000103c 0000103c 00000034 00000034 r-- .const:ti_sysbios_knl_Mailbox_Object__PARAMS__C

0 Chris Carter over 9 years ago in reply to Chris Carter

Expert 1030 points

This resolved my problem with wasted space, but was a manual fix:

Basically, I just calculated the wasted space between the end of Const and the beginning of the sysbios calls, and found objects in the .text sections that would mostly fill it up.

SECTIONS
{
.intvecs : > FLASH_BASE
.cinit : > FLASH
.const : > FLASH
.text:fsmActiveState : > FLASH
.text:NOROM_SysCtrlSetRechargeBeforePowerDown : > FLASH
.text:Power_sleep : > FLASH
.text:calibrateRcoscHf1 : > FLASH
.text:RF_postCmd : > FLASH
.text:Power_init : > FLASH

.text : > FLASH

The sections above resulted in the following map file:

SEGMENT ALLOCATION MAP

run origin load origin length init length attrs members
---------- ----------- ---------- ----------- ----- -------
00000000 00000000 00000edc 00000edc r-x
00000000 00000000 0000003c 0000003c r-- .resetVecs
0000003c 0000003c 000003d8 000003d8 r-x .text:fsmActiveState
00000414 00000414 00000228 00000228 r-x .text:NOROM_SysCtrlSetRechargeBeforePowerDown
0000063c 0000063c 00000248 00000248 r-x .text:Power_sleep
00000884 00000884 000001ec 000001ec r-x .text:calibrateRcoscHf1
00000a70 00000a70 000001fc 000001fc r-x .text:RF_postCmd
00000c6c 00000c6c 0000014c 0000014c r-x .text:Power_init
00000db8 00000db8 00000124 00000124 r-- .const
00001000 00001000 0000453c 0000453c r-x
00001000 00001000 0000003c 0000003c r-- .const:ti_sysbios_knl_Task_Object__PARAMS__C
0000103c 0000103c 00000034 00000034 r-- .const:ti_sysbios_knl_Mailbox_Object__PARAMS__C

Still wasting a few bytes, but better than 3.5k

0 Chris Carter over 9 years ago in reply to Chris Carter

Expert 1030 points

Quick update on this. The linker command file in the CC13xx is generating its map using a single >. This prevents splitting of sections. From the linker documentation:
www.ti.com/.../spru186w.pdf
"You can also use the >> operator to indicate that an output section can be split within a single memory
range."

If I switch from > to >> then I no longer need to manually break out objects from the .text section. One added benefit (see segment map below) is that gaping in the sysbios sections get filled up as well resulting in complete flash utilization. One disadvantage is I noticed more trampolines. For my application the space savings was higher than the overhead cost.

// Section allocation in memory

SECTIONS
{
.intvecs: > FLASH_BASE
.cinit: > FLASH
.const: >> FLASH
.text: >> FLASH
.constdata: >> FLASH
.rodata: >> FLASH
.binit: > FLASH
.pinit: >> FLASH
.init_array: >> FLASH
.emb_text: >> FLASH
.ccfg: > FLASH (HIGH)

Results in:
SEGMENT ALLOCATION MAP

run origin load origin length init length attrs members
---------- ----------- ---------- ----------- ----- -------
00000000 00000000 00005b60 00005b60 r-x
00000000 00000000 0000003c 0000003c r-- .resetVecs
0000003c 0000003c 00000fc4 00000fc4 r-x .text.1
00001000 00001000 0000003c 0000003c r-- .const:ti_sysbios_knl_Task_Object__PARAMS__C
0000103c 0000103c 00000034 00000034 r-- .const:ti_sysbios_knl_Mailbox_Object__PARAMS__C
00001070 00001070 00000030 00000030 r-- .const:ti_sysbios_family_arm_m3_Hwi_Object__PARAMS__C
000010a0 000010a0 0000002c 0000002c r-- .const:ti_sysbios_hal_Hwi_Object__PARAMS__C
000010cc 000010cc 00000028 00000028 r-- .const:ti_sysbios_heaps_HeapMem_Module__FXNS__C
000010f4 000010f4 00000028 00000028 r-- .const:ti_sysbios_knl_Swi_Object__PARAMS__C
0000111c 0000111c 00000024 00000024 r-- .const:ti_sysbios_gates_GateHwi_Module__FXNS__C
00001140 00001140 00000024 00000024 r-- .const:ti_sysbios_gates_GateMutex_Module__FXNS__C
00001164 00001164 00000024 00000024 r-- .const:ti_sysbios_heaps_HeapMem_Object__PARAMS__C
00001188 00001188 00000024 00000024 r-- .const:ti_sysbios_knl_Clock_Object__PARAMS__C
000011ac 000011ac 00000024 00000024 r-- .const:ti_sysbios_knl_Semaphore_Object__PARAMS__C
000011d0 000011d0 00000020 00000020 r-- .const:ti_sysbios_family_arm_m3_Hwi_Object__DESC__C
000011f0 000011f0 00000020 00000020 r-- .const:ti_sysbios_gates_GateHwi_Object__DESC__C
00001210 00001210 00000020 00000020 r-- .const:ti_sysbios_gates_GateMutex_Object__DESC__C
00001230 00001230 00000020 00000020 r-- .const:ti_sysbios_hal_Hwi_Object__DESC__C
00001250 00001250 00000020 00000020 r-- .const:ti_sysbios_heaps_HeapMem_Object__DESC__C
00001270 00001270 00000020 00000020 r-- .const:ti_sysbios_knl_Clock_Object__DESC__C
00001290 00001290 00000020 00000020 r-- .const:ti_sysbios_knl_Mailbox_Object__DESC__C
000012b0 000012b0 00000020 00000020 r-- .const:ti_sysbios_knl_Queue_Object__DESC__C
000012d0 000012d0 00000020 00000020 r-- .const:ti_sysbios_knl_Semaphore_Object__DESC__C
000012f0 000012f0 00000020 00000020 r-- .const:ti_sysbios_knl_Swi_Object__DESC__C
00001310 00001310 00000020 00000020 r-- .const:ti_sysbios_knl_Task_Object__DESC__C
00001330 00001330 00000018 00000018 r-- .const:ti_sysbios_gates_GateHwi_Object__PARAMS__C
00001348 00001348 00000018 00000018 r-- .const:ti_sysbios_gates_GateMutex_Object__PARAMS__C
00001360 00001360 00000018 00000018 r-- .const:ti_sysbios_knl_Queue_Object__PARAMS__C
00001378 00001378 00000008 00000008 r-- .const:ti_sysbios_knl_Idle_funcList__C
00001380 00001380 00000004 00000004 r-x .text.2
00001384 00001384 00000004 00000004 r-- .const:ti_sysbios_family_arm_cc26xx_Timer_startupNeeded__C
00001388 00001388 00000004 00000004 r-- .const:ti_sysbios_family_arm_m3_Hwi_E_alreadyDefined__C
0000138c 0000138c 00000004 00000004 r-- .const:ti_sysbios_family_arm_m3_Hwi_E_hwiLimitExceeded__C
00001390 00001390 00000004 00000004 r-- .const:ti_sysbios_family_arm_m3_Hwi_NUM_INTERRUPTS__C

0 Alan DeMars over 9 years ago in reply to Chris Carter

TI__Mastermind 30830 points

I don't know why the linker command files shipped with CCS don't do this. I'll recommend that we move to this in the .cmd files we ship with the TI-RTOS examples.

0 Chris Carter over 9 years ago in reply to Alan DeMars

Expert 1030 points

I can see both sides. The extra space for the trampolines, combined with the time consumed for jumping would impact performance, so I think its application/use case specific. Though, for people who aren't intimately familiar with the linker and compiler a little note in the command file would probably be worth including. Something like this:

// existing defaults with explanation on pros and cons.
.intvecs: > FLASH_BASE
.cinit: > FLASH
.const: > FLASH
.text: > FLASH
.constdata: > FLASH
.rodata: > FLASH
.binit: > FLASH
.pinit: > FLASH
.init_array: > FLASH
.emb_text: > FLASH
.ccfg: > FLASH (HIGH)
// Comments on when to select section splitting
/*
.intvecs: > FLASH_BASE
.cinit: > FLASH
.const: >> FLASH
.text: >> FLASH
.constdata: >> FLASH
.rodata: >> FLASH
.binit: > FLASH
.pinit: >> FLASH
.init_array: >> FLASH
.emb_text: >> FLASH
.ccfg: > FLASH (HIGH)
*/

0 Alan DeMars over 9 years ago in reply to Chris Carter

TI__Mastermind 30830 points

Yup. Good points. We'll discuss internally.

Processors

Processors forum

Compiler/CC1310: Linker Wasting Space for SysBios on CC1310