Compiler/CC2640: Linker fails but there is RAM available

Nicolas Venturo

Part Number: CC2640

Tool/software: TI C/C++ Compiler

Hello,

I'm working on a project based on the SimpleBLEPeripheral, and when increasing the stack size of one of my tasks, I run into this error.

cc26xx_ble_app_oad.cmd", line 119: error #10099-D: program will not fit into available memory. run placement with alignment fails for section ".stack" size 0x258 . Available memory ranges:
SRAM size: 0x44bf unused: 0x553 max hole: 0x23b

What I found weird about the error is that an allocation for 0x258 (600) bytes fails, there are 1363 (0x553) bytes free, and the biggest hole is only 0x23b (571) bytes long. Why is this happening? Is there any way to make the linker rearrange the RAM so that a bigger hole is created and I can use the remaining RAM?

This is my linker script:

#ifndef APP_BASE
#define APP_BASE                0x00000000
#endif //APP_BASE

#define FLASH_SIZE              0x20000
#define PAGE_SIZE               0x1000
#define RAM_BASE                0x20000000
#define RAM_SIZE                0x5000


/* System memory map */

MEMORY
{
    /* Application stored in and executes from internal flash starting at 0x0 */
    /* Flash Size 128 KB */
    #ifdef ICALL_STACK0_ADDR
        FLASH (RX) : origin = APP_BASE, length = ICALL_STACK0_ADDR - APP_BASE - 1
    #else // default
        FLASH (RX) : origin = APP_BASE, length = 0x0000CFFF
    #endif

    /* Application uses internal RAM for data */
    /* RAM Size 16 KB */
    #ifdef ICALL_RAM0_ADDR
        SRAM (RWX) : origin = RAM_BASE, length = ICALL_RAM0_ADDR - RAM_BASE - 1
    #else //default
        SRAM (RWX) : origin = RAM_BASE, length = 0x00002CFF
    #endif
}

/* Section allocation in memory */

SECTIONS
{
    .intvecs        :   > APP_BASE
    .text           :   > FLASH
    .const          :   > FLASH
    .constdata      :   > FLASH
    .rodata         :   > FLASH
    .cinit          :   > FLASH
    .pinit          :   > FLASH
    .init_array     :   > FLASH
    .emb_text       :   > FLASH

    .vtable         :   > SRAM
    .vtable_ram     :   > SRAM
     vtable_ram     :   > SRAM
    .data           :   > SRAM
    .bss            :   > SRAM
    .sysmem         :   > SRAM
    .stack          :   > SRAM (HIGH)
    .nonretenvar    :   > SRAM
}

/* Create global constant that points to top of stack */
/* CCS: Change stack size under Project Properties    */
__STACK_TOP = __stack + __STACK_SIZE;

Thanks!

over 7 years ago

0 Archaeologist over 7 years ago

TI__Guru* 84225 points

Show us your linker map file (linker option --map_file = filename)

0 Nicolas Venturo over 7 years ago in reply to Archaeologist

Intellectual 810 points

Hello Archaeologist,

Here is my .map (uploaded as .txt) file for the failing build. This is the application's .map file, the BLE stack and bootloader (based on BIMExtFlash) are built separately.

Bold.txt

Thanks!

0 Archaeologist over 7 years ago in reply to Nicolas Venturo

TI__Guru* 84225 points

There are several bound sections by the names dma(Rx/Tx)ControlTableEntry(0/1) that are in the middle of SRAM, fragmenting the available space. Yes, there's lots of space left in SRAM, but there is no single place large enough for your .stack section. The linke placed both .bss and .data at the high end of SRAM, probably because they would not fit anywhere else, leaving no room for .stack.

The easiest fix would be to change your linker map file as follows:

    .data           :   >> SRAM
    .bss            :   >> SRAM

The ">>" placement operator allows the linker to split .data and .bss into smaller chunks that will more easily fit in the available gaps due to the bound sections.

If this doesn't help, there are more things I can suggest.

0 Nicolas Venturo over 7 years ago in reply to Archaeologist

Intellectual 810 points

Great, that fixed it, thanks! I believe TI's SPI driver uses the DMA peripheral, but I don't know why those tables are bound to those memory regions.
Is there any reason to use '>' over '>>' (assuming I don't need the whole section to be contiguous)?

0 Archaeologist over 7 years ago in reply to Nicolas Venturo

TI__Guru* 84225 points

You must use > instead of >> when you need the section to be contiguous; for instance, .stack and .sysmem

0 Nicolas Venturo over 7 years ago in reply to Archaeologist

Intellectual 810 points

Hello again Archaeologist,

I started wondering yesterday, doesn't the .bss section usually hold unitialized global variables, and the .data section initialized variables? I always thought the low level initialization routines took advantage of this, for example by calling memset(bss, bss_length, 0) and memcpy(data, data_init_values, data_length). Does the TI initialization code perform similar steps? If that is the case, won't I be breaking this mechanism by allowing .bss and .data to be split?

Thanks!

0 Archaeologist over 7 years ago in reply to Nicolas Venturo

TI__Guru* 84225 points

As with many things in the compiler, if only it were that simple... In EABI, the linker generates a .cinit table with a series of initialization records, which are usually compressed; this table can easily handle split .bss and .data sections.

0 Nicolas Venturo over 7 years ago in reply to Archaeologist

Intellectual 810 points

Haha, maybe my understanding was a bit too simplistic. Thank you once again!

Code Composer Studio™︎

Code Composer Studio forum

Compiler/CC2640: Linker fails but there is RAM available