Compiler/CCSTUDIO-SITARA: Heap increase the binary file.

In the plateform I remove the DDR3Heap.

 

In the .cfg file I try with this code:

Program.sectMap["systemHeap"].loadAddress = 0x81000000;

But I have a compilation error....

Do you know the syntax ?

It's also possible and more easy to reserved the array in a static variable and assign it to a DDR3Spy section:

In the spy.cpp file:
int32 m_spyData[0x100000] __attribute__((section("SPY_DATA")));

in the .cmd file:
SPY_DATA :
{
. = ALIGN(4);

*(SPY_DATA*)

} > DDR3Spy

In the Platform window: I added a DDRSpy section at the end of the ram.

So the result is the same, the size of the file do 16Mb .

jm

Please see if the discussion in this forum thread is useful.

Thanks and regards,

-George

Thank you for your answer.

Ok for the "Hole" so, is it a normal comportment to include the .bss segment in a binary file ?

If I increase the size of DDR3 section and I declare the spy array in static variable, the array was reserved in the .bss segment.

static int32 m_spyData[SPYDATASIZE];

I can see the résult in the map file:

.bss 0x8007b048     0x0      ./Axis/CommonInterface/commonInterface.o

.bss 0x8007b048     0x1000000    ./Axis/CommonInterface/spy.o

.bss 0x8107b048     0x0      ./Axis/Filters/cFilter.o

 

To notice: In an old project using CCS3 composer, I have the same code. If I try to decrease the size of array from 80000 to 80 integer the size of the .out file don't change.

For a const array it's useful and relevant to include the data in the binary/out files, but for a variable what is the utility ?

In my opinion, the binary file contains only the code to be programmed in the flash, no ?.

Jm

Perhaps that if I remove the zero init (initilize the variables to zero), the linker don't recopy the .bss segment in the .bin file ?

After investigation the problem doesn't appear if I don't use sections in the Platform.
With a single section : DDR3, it's ok. How is it possible to force the linker to ignore a datas section ?

Bye
JM

I can explain a few things.  But I cannot, in the end, tell you how to fix your problem.

jean-Michel Vignolles said:

Ok for the "Hole" so, is it a normal comportment to include the .bss segment in a binary file ?

If initialized sections are present on either side of it, then yes.  If all the initialized sections are before it, or after it, then it is effectively ignored.

jean-Michel Vignolles said:

the binary file contains only the code to be programmed in the flash, no ?.

Binary files are commonly used to program the flash.  But they do not contain only the initialized sections.  

If there is a hole in the memory map, between initialized sections, a binary file has exactly one method for representing that hole: fill it with 0.  One way such a hole may be introduced is for an uninitialized section, like .bss, to be placed in between initialized sections.  

Speaking in very general terms, the solution is to avoid (or minimize) the occurrence of holes in the memory map.  In the other thread I previously referred to, uses an elaborate technique to avoid a hole.  The problem initialized section gets allocated twice.  Once for load, and once for run.  The load allocation is next to all the other initialized sections.  The run allocation is where it needs to be for execution.  One of the steps taken at system start up is to copy this section from the load address to the run address.

You need to do something similar.  I'm sorry, but I am not familiar enough with your system, or TI-RTOS, to give any specific advice.

Thanks and regards,

-George

Hello George,

Thank you for your help and your explanations.

I have no enough time to look for a solution.

I have generated sections to isolate sensible safety code.

I have supressed all the sections, it's ok now, sections cause the problem. For my nedd, an other way was to watch the integrity of the code with a CRC/hashtable.

Have a nice day.

jm