This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/TMS320F28377D: Working on CMD file to allocate a larger variable: error #10099-D: program will not fit into available memory.

Part Number: TMS320F28377D

Tool/software: Code Composer Studio

Hello,

Could you please advice a common way to allocate a larger variable?

Is it neccesary to edit MEMORY directive in a *.CMD file?


volatile Uint16 abc[0x1100];


The size of the array abc[] is 0x1100 words.
My customer would like to allocate the array at RAMGS5 (Addr=0x11000).


With no edit of *.CMD, linker error was generated:


<Linking>
"../2837xD_RAM_lnk_cpu1_edit.cmd", line 70: error #10099-D: program will not
   fit into available memory.  run placement with alignment/blocking fails for
   section ".ebss" size 0x110d page 1.  Available memory ranges:
   RAMGS5       size: 0x1000       unused: 0xff6        max hole: 0xff6
   RAMGS6       size: 0x1000       unused: 0x1000       max hole: 0x1000
   RAMGS7       size: 0x1000       unused: 0x1000       max hole: 0x1000   
error #10010: errors encountered during linking;
   "blinky_cpu01_edit02_Linker_01.out" not built

>> Compilation failure
makefile:151: recipe for target 'blinky_cpu01_edit02_Linker_01.out' failed
gmake: *** [blinky_cpu01_edit02_Linker_01.out] Error 1
gmake: Target 'all' not remade because of errors.

The linker error was cleared by the following *.CMD edit to prepare a larger memory range:

#define EDIT 1

MEMORY
{

..

PAGE 1 :

#if EDIT // successful
   RAMGS5      : origin = 0x011000, length = 0x003000
#else// original
   RAMGS5      : origin = 0x011000, length = 0x001000
   RAMGS6      : origin = 0x012000, length = 0x001000
   RAMGS7      : origin = 0x013000, length = 0x001000
#endif

..
}


SECTIONS
{

..
   .ebss            : > RAMGS5,    PAGE = 1

..
}

We are working on the SPRU513 8.5.5.6 ~ 8.5.5.7.

8.5.5.6  Allocation Using Multiple Memory Ranges
~ To allocate whole a section into a named memory range.

8.5.5.7 Automatic Splitting of Output Sections Among Non-Contiguous Memory Ranges
~ To allow splitting a section to fit.

/cfs-file/__key/communityserver-discussions-components-files/81/2837xD_5F00_RAM_5F00_lnk_5F00_cpu1_5F00_edit.cmd.txt

/cfs-file/__key/communityserver-discussions-components-files/81/blinky_5F00_cpu01.c

  • So far as the compiler and linker are concerned, this ...

    Hideaki Nambu said:
    #if EDIT // successful
       RAMGS5      : origin = 0x011000, length = 0x003000
    #else// original
       RAMGS5      : origin = 0x011000, length = 0x001000
       RAMGS6      : origin = 0x012000, length = 0x001000
       RAMGS7      : origin = 0x013000, length = 0x001000
    #endif

    ... is a good solution.  

    That said, I don't know why that linker command file, as supplied, uses 3 separate memory ranges when it could use one.  There might be a reason for it that is somehow related to a hardware limitation.  I recommend you ask about that in the C2000 forum.  Or, if you prefer, I can move this thread to that forum.

    Thanks and regards,

    -George

  • George,

    Thank you fro your reply.

    I'd like to close.

    >> That said, I don't know why that linker command file, as supplied, uses 3 separate memory ranges when it could use one.

    I think the point is useful. As long as I know the RAMGSx is shared between CPU1 and CPU2.  The 0x1000 is boundaries to set the owner CPU #.