• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 83 subscribers
  • Views 246 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F2812: Linker Can’t Fit in Memory Section When Less Than Half Full

Ed Sanders
Genius 3860 points
Part Number: TMS320F2812

Greetings,

 I have a project which, in the linker cmd file, defines a memory space of 0x30 words.  According to the linker, the program has consumed 0x15 words, or less than half of what has been allocated.  But it produces the error below (which is much more readable if you copy and paste into a notepad).  Clearly the condition of “will not fit into available memory “ does not exist, so it must be the “call site that requires a trampoline that can't be generated for this section”.  What does that mean, and how is it fixed?

Thank you,

Ed

 

Cmd File

MEMORY

{

   PAGE 1: MY_MEM:  origin = 0x000010, length = 0x000030

}

 

SECTIONS

{

   vars1 > MY_MEM   PAGE 1

   vars2 > MY_MEM   PAGE 1

}

Linker Output

#10099-D program will not fit into available memory, or the section contains a call site that requires a trampoline that can't be generated for this section. run placement with alignment/blocking fails for section "vars1" size 0x11page 1.  Available memory ranges:            <ProjectName>.cmd      /<ProjectName>              line 104 C/C++ Problem

#10099-D program will not fit into available memory, or the section contains a call site that requires a trampoline that can't be generated for this section. run placement with alignment/blocking fails for section "vars2" size 0x4page 1.  Available memory ranges:            <ProjectName>.cmd      /<ProjectName>              line 105 C/C++ Problem

  • 0
    TI__Mastermind 34765 points

    Hi, 

    The error reported is due to insufficent memory avaialble for the placement of the code/data into the sections.  

    What is the size of vars1 and vars2 in your project? Both of these are allocated to MY_MEM and hence it should have sufficient space to accomodate both. 

    Does increasing the size of MY_MEM resolve the issue?

    Best Regards

    Siddharth

  • 0 in reply to Siddharth Deshpande
    Genius 3860 points

    Hi Siddharth,

    As a reminder, this has come from code and cmd file which build using the old tools.  I am modifying it so that we can use the newer CCS tools.  So something in the conversion to the new tools is the issue.

    I don’t know if it makes a difference, but I should note that both of these come from assembly files in libraries which are being linked into the main program.  The sizes of vars1 and vars2 match the linker’s calculation of 0x11 and 0x4 or a total of 0x15.

    To your request, the old cmd file originally allocated 0x30 for them.  I have now temporarily increased that to 0x71 and the linker still cannot fit both.

    So I don’t think it is the memory size which is the issue.  It must be the “trampoline”.  Do you know what that is?

    Thank you,

    Ed

  • 0 in reply to Ed Sanders
    TI__Mastermind 34765 points

    Ed, 

    Which version of the compiler was used earlier and which one are you using now?

    A trampoline call is a linker specific feature that implements a  long branch instruction.

    Suppose function A calls function B, which happens to be too far away for the short CALL instruction to reach.  The linker inserts a tiny trampoline function T which executes a long branch to function B, and rewrites A's call so that it actually calls T.  However, T must be placed close to function A, or the short CALL in A won't reach it.  For this reason, T needs to go in the same section as A.

    Best Regards

    Siddharth

     

  • 0 in reply to Siddharth Deshpande
    Genius 3860 points

    Hi Siddharth,

    Thank you for the explanation of trampolines.  That all makes sense.  I assume there is an equivalent associated with accessing variables?

    BTW, All of the variables in question are in assembly files in dependent projects, and defined using .usect.  They don’t seem to be used anywhere else other than their respective projects.  So the issue may be solely within those projects, and a compiler switch to use long accesses is all that is needed.

    Here is the info on the compilers.  Since the focus is on them, I have also included the command line options for the old tools.

    Old tools v4.1.1

    Old Dependent Projects

    cpp files: cl2000 -v28 -c -ea .cls -b -g -ss -k -mf -ml -mn -mt -mx -pe -os -o3 <files>

    asm files: cl2000 -v28 -c -eo .aob -al -as <files>

    link:          lnk2000 -q -m<map file name>.map <files> <cmd file>

     

    Old Main Project

    cpp files: cl2000 -v28 -c -ea .cls -b -g -ss -k -mf -ml -mn -mt -mx -pe -os -o3 <files>

    link:         lnk2000 -q -m<map file name> -o<output file name>.abs <files> <abs files> <libraries> <cmd file>

     

    New tools v20.2.5.LTS.

     

    Thank you,

    Ed

  • 0 in reply to Ed Sanders
    TI__Mastermind 34765 points

    Ed, 

    Will forward your query to the compiler team. 

    Best Regards

    Siddharth

  • +1
    TI__Guru**** 245180 points

    Please make sure it is not a data blocking problem.  Please see the article Data blocking in the C2000 MCU compiler explained.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Genius 3860 points

    That worked George.  I changed all the definitions, which were in assembly, to non-blocking.  Do you have any thoughts as to why it worked with the older tools?

    Thank you,

    Ed

  • 0 in reply to Ed Sanders
    TI__Guru**** 245180 points

    Apparently, the problem data sections were not blocked when built by the old tools.  To verify that, and explain it, would require test cases that reveal a lot about your code and how you build it.  I suspect you are not willing to submit that much detail.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Genius 3860 points

    That is correct.  Thanks for your help.

    Ed