CLA Scratchpad allocation issue

Hi Lucas,

Within CCS delete any Debug or output folders in the project view before building. If you have multiple debug folders from any previous build, you run into issues while linking. It looks like its trying to copy sections of code to the scratchpad area which is incorrect. It should be copying them to Cla1Prog which should be mapped to RAML3.

If possible, can you post the contents of the linker command file or maybe all memories and sections related to the CLA C compiler

Hi Vishal,

  Thanks for your reply!

   I've tried deleting the debug folders and the same issue appears. I've copied the complete content of my command file below:

_Cla1Prog_Start = _Cla1funcsRunStart;

--undef_sym=__cla_scratchpad_end
--undef_sym=__cla_scratchpad_start

MEMORY
{
PAGE 0: /* Program Memory */
/* Memory (RAM/FLASH/OTP) blocks can be moved to PAGE1 for data allocation */
RAML1 : origin = 0x008800, length = 0x000400 /* on-chip RAM block L1, 1k*/
RAML3 : origin = 0x009000, length = 0x000D00 /* on-chip RAM block L3 CLA PROGRAM */
RAML3MATH : origin = 0x009D00, length = 0x000200 /* on-chip RAM block L3 CLA MATH TABLES */
OTP : origin = 0x3D7800, length = 0x000400 /* on-chip OTP */

FLASHH : origin = 0x3F0000, length = 0x006000 /* on-chip FLASH */
FLASHD : origin = 0x3F6000, length = 0x001000 /* on-chip FLASH */
FLASHA : origin = 0x3F7000, length = 0x000F80 /* on-chip FLASH */
CSM_RSVD : origin = 0x3F7F80, length = 0x000076 /* Part of FLASHA. Program with all 0x0000 when CSM is in use. */
BEGIN : origin = 0x3F7FF6, length = 0x000002 /* Part of FLASHA. Used for "boot to Flash" bootloader mode. */
CSM_PWL_P0 : origin = 0x3F7FF8, length = 0x000008 /* Part of FLASHA. CSM password locations in FLASHA */

IQTABLES : origin = 0x3FE000, length = 0x000B50 /* IQ Math Tables in Boot ROM */
IQTABLES2 : origin = 0x3FEB50, length = 0x00008C /* IQ Math Tables in Boot ROM */
IQTABLES3 : origin = 0x3FEBDC, length = 0x0000AA /* IQ Math Tables in Boot ROM */

ROM : origin = 0x3FF27C, length = 0x000D44 /* Boot ROM */
RESET : origin = 0x3FFFC0, length = 0x000002 /* part of boot ROM */
VECTORS : origin = 0x3FFFC2, length = 0x00003E /* part of boot ROM */

PAGE 1 : /* Data Memory */
/* Memory (RAM/FLASH/OTP) blocks can be moved to PAGE0 for program allocation */
/* Registers remain on PAGE1 */

BOOT_RSVD : origin = 0x000000, length = 0x000040 /* Part of M0, BOOT rom will use this for stack */
RAMM0 : origin = 0x000050, length = 0x0003B0 /* on-chip RAM block M0 */
RAMM1 : origin = 0x000400, length = 0x000400 /* on-chip RAM block M1 */
RAML0 : origin = 0x008000, length = 0x000800 /* on-chip RAM block L0, 2k*/

RAML2 : origin = 0x008C00, length = 0x000400 /* on-chip RAM block L2 CLA DATA*/

FLASHB : origin = 0x3F6000, length = 0x001000 /* on-chip FLASH */
CLA1_MSGRAMLOW : origin = 0x001480, length = 0x000080
CLA1_MSGRAMHIGH : origin = 0x001500, length = 0x000080
}

/* Allocate sections to memory blocks.
Note:
codestart user defined section in DSP28_CodeStartBranch.asm used to redirect code
execution when booting to flash ramfuncs user defined section to store functions
that will be copied from Flash into RAM
*/

SECTIONS
{

/* Allocate program areas: */
.cinit : > FLASHH PAGE = 0
.pinit : > FLASHH, PAGE = 0
.text : > FLASHH PAGE = 0
codestart : > BEGIN PAGE = 0

Cla1Prog : LOAD = FLASHH, PAGE = 0
RUN = RAML3, PAGE = 0
LOAD_START(_Cla1funcsLoadStart),
LOAD_SIZE(_Cla1funcsLoadSize),
RUN_START(_Cla1funcsRunStart)

//LOAD_START(_Cla1funcsLoadStart),
//LOAD_END(_Cla1funcsLoadEnd),
//RUN_START(_Cla1funcsRunStart)

Cla1ToCpuMsgRAM : > CLA1_MSGRAMLOW, PAGE = 1
CpuToCla1MsgRAM : > CLA1_MSGRAMHIGH, PAGE = 1
Cla1DataRAM : > RAML2, PAGE = 1

CLA1mathTables : LOAD = FLASHH, PAGE = 0
RUN = RAML2, PAGE = 1
LOAD_START(_Cla1mathTablesLoadStart),
RUN_START(_Cla1mathTablesRunStart),
LOAD_SIZE(_Cla1mathTablesLoadSize)

//LOAD_START(_Cla1mathTablesLoadStart),
//LOAD_END(_Cla1mathTablesLoadEnd),
//RUN_START(_Cla1mathTablesRunStart)

ramfuncs : LOAD = FLASHH, PAGE = 0
RUN = RAML1, PAGE = 0
LOAD_START(_RamfuncsLoadStart),
LOAD_END(_RamfuncsLoadEnd),
RUN_START(_RamfuncsRunStart)
CLAscratch :
{ *.obj(CLAscratch)
. += CLA_SCRATCHPAD_SIZE;
*.obj(CLAscratch_end) } > RAML2,
PAGE = 1

/*CLAscratch : { . += CLA_SCRATCHPAD_SIZE; } > RAML2,
START(__cla_scratchpad_start),
END(__cla_scratchpad_end),
PAGE = 1*/

csmpasswds : > CSM_PWL_P0 PAGE = 0
csm_rsvd : > CSM_RSVD PAGE = 0

/* Allocate uninitalized data sections: */
.stack : > RAMM0 PAGE = 1

.ebss : > RAML0, PAGE = 1
.esysmem : > RAML0, PAGE = 1
.sysmem : > RAML0, PAGE = 1

.cio : > RAML0, PAGE = 1

.bss_cla : > RAML2, PAGE = 1
.const_cla : > RAML2, PAGE = 1

/* Initalized sections go in Flash */
/* For SDFlash to program these, they must be allocated to page 0 */
.econst : > FLASHA PAGE = 0
.switch : > FLASHA PAGE = 0

/* Allocate IQ math areas: */
IQmath : > FLASHA PAGE = 0 /* Math Code */
IQmathTables : > IQTABLES, PAGE = 0, TYPE = NOLOAD

.reset : > RESET, PAGE = 0, TYPE = DSECT

vectors : > VECTORS PAGE = 0, TYPE = DSECT

}

SECTIONS
{
Net_terminals : > RAMM1, PAGE = 1
Controller : > RAMM1, PAGE = 1
}

Hmm, Nothing seems wrong with the cmd file. Have you defined the variable CLA_SCRATCHPAD_SIZE in the project properties??

Properties->C2000 linker->Command File Preprocessing-> --define "CLA_SCRATCHPAD_SIZE=0x100" or whatever size you can accomodate

Yes I did. This is the "summary of flags" for the linker:

-v28 -ml -mt --cla_support=cla0 -Ooff -g --verbose_diagnostics --diag_warning=225 --display_error_number --issue_remarks -k --c_src_interlist --asm_listing -z --stack_size=0x300 -m"CXR48_12kW_DCDCControlTest.map" --heap_size=0x500 --warn_sections -i"C:/ti/ccsv5/tools/compiler/c2000_6.1.2/lib" -i"C:/ti/ccsv5/tools/compiler/c2000_6.1.2/include" --reread_libs --define=CLA_SCRATCHPAD_SIZE=0x100 --rom_model

Here are Vishal's recommendations based on the reivew of your pruned down project.

Vishal said:

I might have the solution.

1. In the lcf, at the top the following lines were commented out:
   --undef_sym=__cla_scratchpad_end
   --undef_sym=__cla_scratchpad_start         
They need to be uncommented. Once done it will stop complaining about the missing section CLAScratch_end

2. This is probably trivial, but best to be sure: make sure that CCS thinks the “.cla” file is a C source file and not a text file. In the project you sent me there was no .cla file so the undef lines above were giving me errors, these went away when I added a cla file. See attached

3. When copying sections from FLASH to RAM, be sure that the any data that goes into FLASH is const. I had some issues with the CLA1MathTables, it kept complianing that it didn’t know the size of the section. If you do not declare the data as const, the compiler considers it an UNITINIALIZED section, as such it assumes that the _c_init00 function will initialize it at boot time. Since you cant write to flash at boot-time the linker will throw a fit stating that the LOAD_START or LOAD_SIZE operator is bad

Report back your results.

Hi Jason and Vishal,

  Thanks for the review of the code and figuring out those issues. We actually do have those lines commented in our non-strip out code as well as the .cla file which contains all the routines we run in the cla. Probably we reduced the code we have sent you way to much.

   However, all this exercise helped out to figure out where the actual problem is. We use two projects for all our projects. One compiles only to a library, the other produces the out file. The .cla file we use, we keep it in the library project and not in the executable. When we move this file (the .cla) to the executable project, then the problem disappears. For now we are keeping the file in the executable project to avoid the issue, but we would prefer to have it in our library project. Can you think of a way to do that without incurring into this issue? Or the only solution is to keep the .cla file inside of the executable project (the one who has the main and the cmd file)?

  Thanks again for your assistance,

Lucas

Thanks Vishal, I'll try it out.

L.

Hallo, Vishal:

I extracted your compressed file and look into map file "F28069_CLA_Template.map". I saw the definition of "CLAscratch_end":

"

CLAscratch_end
* 1 00000002 00000000 UNINITIALIZED

"

But what makes me confused if why "CLAscratch_end" is allocated to "BOOT_RSVD"'s memory region?

We always have problem with CLAscratch allocation.

BTW, allocation of "CLAscratch", "__cla_scratchpad_end", "__cla_scratchpad_start" are all right.

Hi Yanbin,

We identified an issue where multiple cla files are compiled and the CLAscratch_end symbol is allocated incorrectly. Replace the CLAscratch section allocation in the linker cmd with this one:

    CLAscratch      :
                  { *.obj(CLAscratch)
                    . += CLA_SCRATCHPAD_SIZE;
                    *.obj(CLAscratch_end)
                    *<*.obj>(CLAscratch_end)
                    } > CLARAM1,
                    PAGE = 1

Could you let me know if this works?

Hi, Vishal:

I have tried your cmd code. It works and all the former problems during linking disappear.

Just one question:

In map file, the symbol "CLAscratch_end" disappear. What happened? Does this change will affect something?

Thanks for your attention.

The CLAscratch_end sections are lumped into CLAscratch so I dont think you should see it in the map. Try it on a single CLA file and see if it shows up.

Hallo, Vishal:

Just give you an information:

When I use my own CLA library file (*.lib) during compilation and linking, your cmd code works well.

When I use seperate CLA source file (*.cla) during compilation and linking, your cmd code will have a warning with the additional statement "*<*.obj>(CLAscratch_end)":

#10068-D no matching section

Can you have a look at this issue? What's the problem?

Zhao.Yanbin

2013.11.22

Regarding your suggestion "Try it on a single CLA file and see if it shows up." I tried as you said but there's never section "CLAscratch_end" shown up again.

Hi Zhao,

for the single .cla, you need to go back to the original section description for CLAscratch...or since this is a warning, you could potentially ignore or suppress it.

Im guessing its complaining since it didnt find the CLAscratch_end symbol in any of the other obj files. You can probably test this theory by putting in a .c file in your library...im willing to bet it will complain that it didnt find a CLAscratch_end section in one of the obj files.

Sorry, Vishal:

I don't catch what you mean. From my understanding, CLAscratch is an area used to store internal temperory variables of CLA functions. Why should I test this theory by "You can probably test this theory by putting in a .c file in your library."?

Actually, my CLA library is built with both *.c and *.cla files.

I setup an example for you to investigate in this issue.

In this example, assembly file "Z_CLA_Asm.asm" contains a squart root function "_Z_CLA_Sqrt" in assembly code, in the beginning of this assembly file defines 4 byte temporary variable for CLAscratch area.

In the generated map file you will see section "CLAscratch" in "SECTION ALLOCATION MAP".

But there's still warning "no matching section" for *<*.obj>(CLAscratch_end). 

You will see symbol "CLAscratch_end" in generated object file "TestForCmd.obj".

One thing I need to emphasize is no matter this warning exists or not, I will not see symbol "CLAscratch_end" with your given definition for section CLAscratch.

My question is why there's still this warning although section "CLAscratch" exists in map file and symbol "CLAscratch_end" exists in "TestForCmd.obj"?

BTW, in my CLA library "Z_CS_2803x_HWLib_CLA.lib" there's a same implememtation of "_Z_CLA_Sqrt" which I don't thinks affects a lot.

Thanks for your attention.2781.CLAScratch_TEST.zip