- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
In this TI Wiki
http://processors.wiki.ti.com/index.php/C2000_CLA_C_Compiler
It says
Local variables and compiler temps are placed into a scratchpad memory area. On older CGT (before 6.4.0) these variables were accessed directly using the symbols '__cla_scratchpad_start' and '__cla_scratchpad_end' and it was expected that the user would manage this area and define these symbols using a linker command file. In CGT 6.4.0 (and above) these variables are placed in a ".scratchpad" memory section, which the compiler will then partition into local frames, one for the all eight tasks, and one for each leaf function. These local frames will have unique symbols that the compiler will use to access variables.
...
The old convention for CLAScratch will still be supported by the new compiler, albeit, inefficiently from a memory allocation standpoint. The new compiler creates a common local frame for the 8 tasks, i.e. each task's local frame is overlayed on top of each other - they use the same memory locations; this is possible since there is no nesting of tasks, so one task cannot corrupt the scratch area of another. By having the CLAScratch memory section, the compiler cannot take advantage of the overlaying strategy and is, instead, forced to allocate each task's locals in separate locations within the scratchpad.
So your .cmd file either looks like this (6.2.x and older)
// Define a size for the CLA scratchpad area that will be used
// by the CLA compiler for local symbols and temps
// Also force references to the special symbols that mark the
// scratchpad area.
CLA_SCRATCHPAD_SIZE = 0x100; // If using --define CLA_SCRATCHPAD_SIZE=0x100, remove this line
--undef_sym=__cla_scratchpad_end
--undef_sym=__cla_scratchpad_start
.....
MEMORY
{
.....
}
SECTIONS
{
//
// Must be allocated to memory the CLA has write access to
//
CLAscratch :
{ *.obj(CLAscratch)
. += CLA_SCRATCHPAD_SIZE;
*.obj(CLAscratch_end) } > CLARAM1, PAGE = 1
}or like this (6.4.x and newer)
.....
MEMORY
{
.....
}
SECTIONS
{
//
// Must be allocated to memory the CLA has write access to
//
.scratchpad : > CLARAM1, PAGE = 1
}One thing to note is that the CLA math library still uses the "CLAscratch" section. So even with 6.4.x compiler, if you are using CLA math library, you'd need to do the .cmd file as if you had 6.2.x or older.
I have tried to modify the CLA math library source and replace every .usect "CLAscratch" with .usect ".scratchpad" ?? Then recompile the library and use that one instead (with 6.4.x or newer). Then you would need to only specify .scratchpad in your .cmd file, even if you are using the CLA math library.
Should I have any concern about the CLA math library functions having the same frame as the overlayed task frames? Or are they considered leaf functions that have their own frames?
From what I see, it looks like they are all using the same frame:
This is how it was before with the old convention:
Hi there,
I was pretty happy that I have found the thread obove.
I've included all the libaries and file search paths and so on as supposed, but I still get the message from the old convention:
#10247-D creating output section "CLAscratch" without a SECTIONS specification
I'm using an F28377S on the Launchpad LAUNCHXL.
Attatched is my .cmd for creating all sections and some screenshots of the properties.
MEMORY
{
PAGE 0 : /* Program Memory */
/* BEGIN is used for the "boot to FLASH" bootloader mode */
.....
/* Local Shared Memory */
LS0304SARAM : origin = 0x009800, length = 0x001000 /* on-chip RAM for CLA program and CLAmath lookup tables */
// LS04SARAM : origin = 0x00A000, length = 0x000800 /* on-chip RAM for CLA program and CLAmath lookup tables*/
....
FLASHC : origin = 0x084000, length = 0x002000 /* on-chip Flash, reserved for CLA*/
...
PAGE 1 : /* Data Memory */
/* Local Shared Memory */
LS00SARAM : origin = 0x008000, length = 0x000800 /* on-chip RAM for CLA data */
LS01SARAM : origin = 0x008800, length = 0x000800 /* on-chip RAM for CLA data and scratchpad*/
LS02SARAM : origin = 0x009000, length = 0x000800 /* on-chip RAM */
LS05SARAM : origin = 0x00A800, length = 0x000800 /* on-chip RAM */
/* Message Memory */
CLA1_MSGRAMLOW : origin = 0x001480, length = 0x000080
CLA1_MSGRAMHIGH : origin = 0x001500, length = 0x000080
....
}
SECTIONS
{
....
/* CLA specific sections */
Cla1Prog : LOAD = FLASHC,
RUN = LS0304SARAM ,//| LS04SARAM,
LOAD_START(_Cla1funcsLoadStart),
LOAD_END(_Cla1funcsLoadEnd),
RUN_START(_Cla1funcsRunStart),
LOAD_SIZE(_Cla1funcsLoadSize),
PAGE = 0, ALIGN(4)
CLA1mathTables : LOAD = FLASHC, PAGE = 0
RUN = LS01SARAM, PAGE = 1
LOAD_START(_Cla1mathTablesLoadStart),
LOAD_END(_Cla1mathTablesLoadEnd),
RUN_START(_Cla1mathTablesRunStart),
LOAD_SIZE(_Cla1mathTablesLoadSize)
CLADataLS0 : > LS00SARAM, PAGE=1
CLADataLS1 : > LS01SARAM, PAGE=1
Cla1ToCpuMsgRAM : > CLA1_MSGRAMLOW, PAGE = 1
CpuToCla1MsgRAM : > CLA1_MSGRAMHIGH, PAGE = 1
/* CLA C compiler sections */
//
// Must be allocated to memory the CLA has write access to
//
.scratchpad : > LS01SARAM, PAGE = 1
.bss_cla : > LS01SARAM, PAGE = 1
.const_cla : LOAD = FLASHC,
RUN = LS01SARAM,
RUN_START(_Cla1ConstRunStart),
LOAD_START(_Cla1ConstLoadStart),
LOAD_SIZE(_Cla1ConstLoadSize),
PAGE = 1
....
}
Where my CLAmath is located:
What libaries did I include:
What type of processor do I have set up
What did I wrong?
Best regards.
Tommy
Vishal_Coelho said:Tommy,
There is a 4.00.01.00 and the newer 4.01.00.00. You're sure you are using the latest library? Perhaps rebuild the library in CCS, the project for it should be in the ccs folder. I would recommend using the CGT used to build it - 15.12.0 i think.
Hi,
In the picture below, you can see that I am using the 4.01.00.00 version, as well as the libs I included.
This can't be the problem as well as the CGTs. I tried all I have (15.12.1 / 2 / 3 LTS and 16.3.0.STS) and no one got the requiered CLAscratch section moved away.
When I am trying to build the libraryin its standalone project CCS is giving me an error:
Description Resource Path Location Type
gmake: *** No rule to make target 'clean'. cla1_math_library Unknown C/C++ Problem
I still have no idea where this is coming from.
Do you have another solution approach?
P.S.: The warning he is pushing back is as follows:
Description Resource Path Location Type
#10247-D creating output section "CLAscratch" without a SECTIONS specification daidalos C/C++ Problem
