28035 linker file problem: .no sufficient memory space for .ebss

Will,

The linker does not have infinitely small granularity when splitting a section.  I ran a quick test and it looks like the linker will only split the .ebss section down to the object module level.  For example, suppose you have two source files: main.c, and foo.c, and you declare global variables in each.  The linker will keep the global vars from each source file together.  It will not split them.  This seems reasonable.  I reason it this way: if you have an array for example, you'd agree that it cannot be split.  I suspect the linker cannot see into each object module and determine the composition of the .ebss section.  It treats the contribution of each object module as an "Array" that cannot be split.

So, it may be that despite your trying to split your section up and put in multiple memories that would appear to have sufficient capacity, the linker may not have been able to do it.

There is actually text in the Assembly Language Tools User's Guide, SPRU513E, p.196, that says the .bss section should not be split (and I'd assume this means .bss and .ebss).  It also says that if you use >> the linker will issue a warning and ignor the >>.  I've found this to be incorrect, as in my testing I was able to get the .ebss to split along object module boundaries, and I get no warning.

Here is what I would suggest.  First, define some large dummy memory block in your .cmd file (this is fake memory, just for building your project).  Then, link your .ebss section to this memory.  That will allow you to successfully build your project, and then you can look at the .map file and find out what's going on.  You can see the contribution of each object module to the total .ebss section.  You might be able to see why the link was unable to split te .ebss and fit into the RAM blocks you specified.

Do you have any large arrays?  If so, you can use a DATA_SECTION pragma to place them in a named section other than .ebss.  You can then link this section specifically in the .cmd file.  In effect, you are manually splitting out one or more large blocks and allocating them yourself to help the linker split the remaining pieces of the .ebss.

Regards,

- David

Hello David!

A small remark.

In controlSUITE there are many examples of CMD where splitting is used (mainly for F28M35/36) for .ebss section. I have used this method successfully also (for experimental goals). Compiler (6.0.1) swallows even such feints:

RUN = RAML2|RAML3|RAML4, PAGE = 1

Thus the issue of Will is non-trivial.

Regards,

Igor

Hello Igor,

To be clear, I am not suggesting that .ebss section cannot be split.  What I'm saying is that there are limits to how finely the linker will split things.  It is easy to produce a simple example where there is plenty of memory to fit everything, but the linker cannot split the .ebss.

main.c:

volatile int x[64];
volatile int y[64];
void main(void) {}

linker .cmd:

L7SARAM_A   : origin = 0x00F000, length = 0x000060
L7SARAM_B   : origin = 0x00F060, length = 0x000060

.ebss         : >> L7SARAM_A | L7SARAM_B,    PAGE = 1

The above will fail to link.  The linker will not split a section from a single object file.  In this case, the .ebss section from main.obj.  The error message is:

"../F28335_nonBIOS_ram.cmd", line 53: error #10099-D: program will not fit into
   available memory.  run placement with alignment/blocking fails for section
   ".ebss" size 0x8a page 1.  Available memory ranges:
   L7SARAM_A    size: 0x60         unused: 0x58         max hole: 0x58
   L7SARAM_B    size: 0x60         unused: 0x60         max hole: 0x60

But, if you move the declaration of y[64] to a different source file, say foo.c, the linker will split the .ebss section along object module boundaries and fit things in the specified memories.  The resulting .map file shows the split into two different .ebss sections, .ebss.1 and .ebss.2:

.ebss.1    1    0000f000    00000048     UNINITIALIZED
                  0000f000    00000040     foo.obj (.ebss)
                  0000f040    00000004     rts2800_fpu32.lib : _lock.obj (.ebss)
                  0000f044    00000004                       : exit.obj (.ebss)

.ebss.2    1    0000f080    00000040     UNINITIALIZED
                  0000f080    00000040     main.obj (.ebss)

Regards,

David