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.
Tool/software: TI C/C++ Compiler
Hi expert,
My customer meet with a CLA compiler behavior issue in their near production project. Variable assignment in CLA get delayed with instructions generated by compiler which causes wrong data in the program.
Device: TMS320F28377D
Compiler: TI v18.12.1.LTS
We have tried to debug this with below method:
1. Define data structure and array cla_sInvCurrCtrlPR3 and cla_af32Db[5]. Initiate them as below:
cla_sInvCurrCtrlPR3.f32BefPreResCtrl = 1.0f;
cla_sInvCurrCtrlPR3.f32PreResCtrl = 2.0f;
cla_sInvCurrCtrlPR3.f32ResCtrl = 3.0f;
cla_sInvCurrCtrlPR3.f32A1 = 2.0f;
cla_af32Db[4] = 2.0f;
2. Using CCS to find structure and array address as below:
3. They implemented below calculation:
cla_sInvCurrCtrlPR3.f32BefPreResCtrl = cla_sInvCurrCtrlPR3.f32PreResCtrl;
cla_sInvCurrCtrlPR3.f32PreResCtrl = cla_sInvCurrCtrlPR3.f32ResCtrl;
cla_af32Db[0] = cla_sInvCurrCtrlPR3.f32A1 * cla_sInvCurrCtrlPR3.f32PreResCtrl;
4. They have tried three pieces of code to do the same thing but get different behavior.
A. (Wrong result) cla_sInvCurrCtrlPR3.f32ResCtrl and cla_sInvCurrCtrlPR3.f32PreResCtrl are in adjecent address,Compiler generated instruction MMOVD32 here
B. (Right result) replace cla_sInvCurrCtrlPR3.f32PreResCtrl with cla_af32Db[4] to make memery address none adjacent, Compiler generated instruction MMOV32 and inserted MNOP here.
C. (Right result) Similar to "B", adding __mnop() in "A" to force MNOP here.
5. We assume instruction "MMOVD32 MR0, @0xa0f0" may need some time for @0xa0f2 to be updated, or @0xa0f2 will keep the old value to get the wrong result.
Questions here. Why some cases get MNOP but some not? How do we make sure other part of code is reliable with this compiler?
Example code:
1. cla_af32Db[0] = 4.0: wrong
2. cla_af32Db[1] = 6.0;right
3. cla_af32Db[2] = 6.0;right
Thanks
Sheldon
Sheldon He said:A. (Wrong result) cla_sInvCurrCtrlPR3.f32ResCtrl and cla_sInvCurrCtrlPR3.f32PreResCtrl are in adjecent address
Sheldon He said:B. (Right result) replace cla_sInvCurrCtrlPR3.f32PreResCtrl with cla_af32Db[4] to make memery address none adjacent
Sheldon,
I think this is likely due to the datatype size differences on the C28x and CLA. See this FAQ in the CLA SW developers guide for information on how to handle this:
Also check that shared variables are defined in the C28x code (not the CLA code). See item #3 in this FAQ:
Regards
Lori
Sheldon,
This is a bug in the CLA compiler. Please see below Jira for details:
jira.itg.ti.com/.../EXTSYNC-2429
The issue is with MMOVD32 instructions. They do an extra data copy write to next address.
MMOVD32 MR0,mem1 ;
loads MR0: MR0=mem1
data copy: mem1+2=mem1
Any following instruction that reads from the same memory location (mem1+2) must wait for three instructions.
MMOVD32 MR0,mem1
MMOV32 MR1,mem1+2 ; too soon
MMOV32 MR1,mem1+2 ; too soon
MMOV32 MR1,mem1+2 ; too soon
MMOV32 MR1,mem1+2 ; good
Regards,
Greg
Hi Greg,
My I kindly get the document listed all the defect for this version of compiler?
Will this issue also in newer version of compiler?
When will you give a fixed release?
Thanks
Sheldon
Sheldon,
This bug is in every version of the compiler.
I'll send an update for when we expect to have a fix once our support team has reviewed the bug.
I sent latest bug list to your email.
Thanks
Greg