This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Compiler/TMS320F28375D: Is this known bug of old compiler?

Part Number: TMS320F28375D


Tool/software: TI C/C++ Compiler

I came across strange behavior again...

I'm using an old C2000 compiler, TI v6.2.8.

I set two structures to CLARAM area using DATA_SECTION pragma for data exchange between CPU and CLA.
And I copied data at CPURAM to a structure member at CLARAM.
But one menber of structure wasn't copied.
C source code is like below.

[C source]

#pragma DATA_SECTION(rd_cpu1, "CLARAM");
#pragma DATA_SECTION(wr_cpu1, "CLARAM");

wr_cpu1.menber11 = A;
wr_cpu1.menber14 = B;
wr_cpu1.menber19 = C;
wr_cpu1.menber13 = D;

This is very simple code, but copy to member19 is failed. So I checked assembly code.

[Assembly source]
MOV       PL, _A
MOV       T, _B
MOV       PH, _D
MOV       AH,_C
...
MOVW      DP,#_wr_cpu1+11
MOV       @_wr_cpu1+11,P
MOV       @_wr_cpu1+14,T
MOV       @_wr_cpu1+19,AH
MOVH      @_wr_cpu1+13,P
...

This also looks right, but it didn't work correct.
So I executed assembly code step by step on targe device using CCS debug.
At that time I found the cause of this abnormality in disassembly view.

[Disassembly view]

00b611:   761F020F    MOVW         DP, #0x20f
00b613:   3F39        MOV          @0x39, P
00b614:   213C        MOV          @0x3c, T
00b615:   9701        MOV          @0x1, AH
00b616:   573B        MOVH         @0x3b, P

Member19 has an offset 19 word from top of structure.
But in above code, offset of member19 is 1.
and offsets of other members is wrong too.
Result of execute of row 00b615 above code, _rd_cpu1.member1 was overwrited by content of AH.

I checked .map file and an absolute address of structure in CCS Expressions view.

[map file]
000083c0     20f (000083c0)     _rd_cpu1
000083ee     20f (000083c0)     _wr_cpu1

[Expressions]
wr_cpu1.member11  ... Address 0x000083F9@Data
wr_cpu1.member13  ... Address 0x000083FB@Data
wr_cpu1.member14  ... Address 0x000083FC@Data
wr_cpu1.member19  ... Address 0x00008401@Data

Maybe the structure wr_cpu1 at CLARAM is not alined top of data page, so C2000 compiler mistake an offset culcuration from top of structure.
This is caused the difference of architekture between C2000 CPU core and CLA core, from using DP register to access memory or not.

Is this known bug of old compiler?
And is there a way to avoid this?

  • This is a known issue.  All data shared between the CLA and the C28x CPU must be defined in the C or C++ code, and not the CLA code.  For further background, please see this forum thread.

    Thanks and regards,

    -George

  • 1. I want to know the definition of CLA code strictly. Is the code listed in the .cla file? Or the code placed in LSxRAM?
    2. Where is this restriction stated? How can I know such information?
  • Please tell me more about what conditions this problem is caused.
    Only the structures defined in CLA code? Or are arrays, multi-byte variable (long long, long double, etc.) included?
  • user3941789 said:
    I want to know the definition of CLA code strictly.

    The code written in the .cla file(s).

    user3941789 said:
    Where is this restriction stated?

    We owe you an apology.  We have not added this restriction to our documentation. I filed the entry CODEGEN-6160 in the SDOWP system to have the documentation updated.  You are welcome to follow it with the SDOWP link below in my signature.

    Thanks and regards,

    -George

  • user3941789 said:
    Please tell me more about what conditions this problem is caused.
    Only the structures defined in CLA code? Or are arrays, multi-byte variable (long long, long double, etc.) included?

    All of the data shared between the CLA and the C28x CPU must be defined in the C (or C++) code, and not the CLA code.  

    Thanks and regards,

    -George