• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 53 subscribers
  • Views 1518 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Compiler/TMS320F28035: Automatic section splitting for RAM in TMS320F2803x with CCS7.2

Vikas Chola
Expert 5250 points
Part Number: TMS320F28035


Tool/software: TI C/C++ Compiler

Hello Team,

One of my customer is using CCS with TMS320F28035 for his Solar grid connect inverter application where he is looking for combining multiple non-contiguous SRAM section for data RAM i.e. for .ebss as his RAM usage is increasing. I have gone through spru513n section 8.5.5.6 and spraa46a.pdf for automatic splitting the section and allocation by CCS. So I have imported default Example_28035_Flash in CCS7.2 and done below change:

In Example_2803xFlash.c I have declared below two Array totaling 1200 bytes (2 array so that one array could be fit in one section as my one section RAML2/RAMM1 is of 1024 bytes in TMS320F28035).

unsigned char Tempdata[400];

unsigned char Tempdata1[800];

 

Now I have changed 28035.cmd as below:

.ebss               : { * (.ebss) } >> (RAML2 | RAMM1)      PAGE = 1

 

But this example hasn't got compiled and gave me error as below:

________________________________________________________________

>> Compilation failure
makefile:151: recipe for target 'Example_28035_Flash.out' failed
"../F28035.cmd", line 136: error: program will not fit into available memory.
run placement with alignment/blocking fails for section ".ebss" size 0x52c
page 1. Available memory ranges:
RAML2 size: 0x400 unused: 0x3f8 max hole: 0x3f8
RAMM1 size: 0x400 unused: 0x400 max hole: 0x400
.ebss : { * (.ebss) } >> (RAML2 | RAMM1) PAGE = 1
error: errors encountered during linking; "Example_28035_Flash.out" not built
gmake: *** [Example_28035_Flash.out] Error 1
gmake: Target 'all' not remade because of errors.

**** Build Finished ****

____________________________________________________________________

I have discussed this issue with Team and got below feedback:

All the global variables in a given file or .obj is being attempted to fit in a single RAM Block only (even though there can be multiple variables in the same file).

I can understand that one Array should completely filled in one section but one obj file /one c file is only fitting in one section might not be acceptable to many customers..There are lot of customers who work in single file /some specific work in one file which might create issue with this. 

 Please advise what setting should I done for making CCS automatic splitting of .ebss section for getting fitted in different non-contiguous SRAM section.

Regards,

Vikas Chola

  • 0
    TI__Guru**** 250140 points

    I don't know for certain, but it seems likely that these array definitions ...

    Vikas Chola said:

    unsigned char Tempdata[400];

    unsigned char Tempdata1[800];

    ... appear in one file.  This means they are in one input section of size 1200 (0x480).  Automatic section splitting cannot split up an input section.  It can only split up an output section on input section boundaries.  Since your memory ranges are 1024 (0x400), this input section cannot be allocated.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    TI__Expert 5250 points

    Hello George,

    I couldn't understand what your meaning from input section... I have defined two array which are independent from each other so it should be fitted within my RAM declared by cmd file. My understanding from >> operator is that it splits the section like .text, .ebss etc... So my .ebss section should look for RAM space where it can fit both array separately.. CCS/compiler shouldn't look space for both of these combined as these are two independent array.

    Consider a customer is working in one file for his whole application then in that case with current CCS implementation, compiler will choose only one section (may be largest of all) of SRAM so effectively useful RAM will reduce or customer has to use #pragma for allocating some variable. Please look into this matter and advise if we can make this better....

    Regards,

    Vikas Chola

  • 0 in reply to Vikas Chola
    TI__Guru**** 250140 points

    Vikas Chola said:
    I couldn't understand what your meaning from input section

    Please learn about the terms input section and output section from the first part of the article Linker Command File Primer.  

    Vikas Chola said:
    I have defined two array which are independent from each other so it should be fitted within my RAM declared by cmd file.

    That is incorrect.  Because those array definitions are in the same file, they are in the same input section, and an input section cannot be split.

    The solution is to have those arrays be in separate input sections.  One method is to put them in different files.  That is probably impractical, or inconvenient.  Another method is to use the variable attribute section ...

    unsigned char Tempdata[400]
__attribute__ ((section(".ebss:Tempdata")));
unsigned char Tempdata1[800]
__attribute__ ((section(".ebss:Tempdata1")));

    If you prefer, you can do a similar thing with the DATA_SECTION pragma.  These attributes put each array into a subsection of .ebss with the name shown.  Even though they are subsections of .ebss, this still counts as separate input sections.  If the linker command file ever changes to not split .ebss, this code does not need to change.  Those subsections will be combined with other .ebss input sections to form the .ebss output section.

    Thanks and regards,

    -George