TMS320F28377D: Assignment error encountered in structure initialization: Tricky compiler behavior for .cla file

Hi experts,

Background:
As shown in picture one and two. We define and declare a structure variable in .cla file to share data between CLA and CPU in F28377D device. It was linked to local shared RAM. This LSxRAM is configured to be owner by both CPU and CLA, also as a data block for CLA.

Compiler version: v18.12.0LTS

Problem:

When we initialize this variable in CPU unintended write occured in some RAM address. We can easily see the compiler seems don't handle this assignment well.
From the disassembly in picture three, we can see why this happens:
1. Data page (DP) is first assigned as 0x28F, every data page has a valid offset of 0x00 to 0x3F. So, this data page can access data from 0xA3C0 to 0xA3FF in the RAM.
2. First three assignment is correct, f32ResCtrl has an offset of 0x3a and an actual address of 0xA3FA; f32BefPreResCtrl has an offset of 0x3c and an actual address of 0xA3FC; f32BefPreResCtrl has an offset of 0x3e and an actual address of 0xA3FE;
3. Then, assignment get into error, we can see f32A1 should has an offset of 0x40 but compiler gives a 0x00 instead. In this case data at 0xA3C0 will be changed which is not our purpose.
4. Consecutive assignments are all failed.

Questions:
If we define this structure variable in CPU instead (still initialize it in CPU), compiler will give right assembly code. Data page and offset will be handled correctly even crossing a large RAM area. Why define it in .CLA will not give the right result?

I will try to get compiler version and makefile from my customer soon....

Thanks

Sheldon H

Hi George,

One more question for you:

Does SDSCM00050582 and the red line in below document say the same thing?

Thanks

Sheldon

Sheldon He said:

in Open_defects.html of ti-cgt-c2000_18.12.1.LTS. I didn't see any line mentioned this. Does that mean this is not a problem for this compiler version?

Unfortunately, it is a problem in version 18.12.x.LTS.   The related entry in SDOWP is CODEGEN-1407.  It is not classified as a bug, but an enhancement.  That is why it is not listed among the open defects.

Thanks and regards,

-George

Sheldon He said:

Does SDSCM00050582 and the red line in below document say the same thing?

I think you forgot an attachment or a screen shot.  So, I am not sure what you are asking.

Thanks and regards,

-George