CCS/TMS320F28379D: I have some behavioral issue while I'm executing CLA C-code

Diego Bellachioma

Part Number: TMS320F28379D
Other Parts Discussed in Thread: CCSTUDIO, CONTROLSUITE, TMS320F28075

Tool/software: Code Composer Studio

Good morning.

I notice some problem when I'm using CLA1 after CPU1 configuration. I use CCStudio 7 with TI v6.4.2 Compiler on F28379D target [TI v16.9.1.LTS makes a lot of #2638 error: The alignment
of an array element is greater than the element size].
Anyway, my simple test code follows a TI sketch but it sets only Task1 on CLA for easily changing a local CLA variable. The compilation steps are ok; also debug steps
improve correctly.
When I starting CPU1 code, after that I connect in debug window either CPU1/CLA1, CPU1 executes own code upto waiting in Cla1ForceTask1andWait() function: CPU1 state
is in Running mode while focus pass on CLA1 that is in Suspended mode with no symbols defined for 0x0000A000 [I know is the origin LS4-LS5 RAM assigned to CLA1 by
2837xD_RAM_CLA_lnk_cpu1.cmd]. Finally, when I load symbols on CLA1, it stops in the first C istruction that is 'a = 1'.

Follow it is the assembly code with one istruction over MSTOP.

Cla1Task1(), c:
0000a000: 78400000 MMOVIZ MR0, #0x0
0000a002: 78800001 MMOVXI MR0, #0x1
0000a004: 74C08900 MMOV32 @0x8900, MR0
43 __mdebugstop();
0000a006: 7FA00000 MNOP
0000a008: 7FA00000 MNOP
0000a00a: 7FA00000 MNOP
0000a00c: 7F600000 MDEBUGSTOP
0000a00e: 7FA00000 MNOP
0000a010: 7FA00000 MNOP
0000a012: 7FA00000 MNOP
0000a014: 7FA00000 MNOP
52 }
0000a016: 7FA00000 MNOP
0000a018: 7FA00000 MNOP
0000a01a: 7FA00000 MNOP
0000a01c: 7F800000 MSTOP
27 kft = 16384; // 1) E 2) DEBUG kf FISSO
osc_test():
0000a01e: 40008F00 MMPYF32 MR0, MR0, MR0 || MMOV32 @0x8f00, MR0

The questions are relative the follow event:

1) If I execute a single step, MPC arrived in 0x000a006 while the blue arrow pointed __mdebugstop() function. MR0 register would be changed in 1 value and then it will
be loaded in 0x8900 that is CLA1 Data RAM assigned for 'a' variable. If I check MR0,'a' in Variable window and 0x8900 RAM location, I don't see any right value [it
preserves 0 value]. However, If I manually change value in a Variable window or in Memory, it changes correctly. It seems that CLA have some problem with memory
control but also with own MR0 register [???];
2) If I continue with two steps, MPC overruns MSTOP CLA istruction and reaches 0x000a01e program location that it would be assigned to CPU1 code [???].

Is there somebody that clarify this behavioral ? Thank's a lot.

Diego.

PS: I apologize cause my bad english.

over 8 years ago

0 Vishal_Coelho over 8 years ago

TI__Mastermind 20850 points

Hi Diego

Diego Bellachioma said:
If I execute a single step, MPC arrived in 0x000a006 while the blue arrow pointed __mdebugstop() function. MR0 register would be changed in 1 value and then it will
be loaded in 0x8900 that is CLA1 Data RAM assigned for 'a' variable. If I check MR0,'a' in Variable window and 0x8900 RAM location, I don't see any right value [it
preserves 0 value]. However, If I manually change value in a Variable window or in Memory, it changes correctly. It seems that CLA have some problem with memory
control but also with own MR0 register [???];

I would recommend you single step in the disassembly window. When you single step on the CLA you push the pipeline 1 cycle ahead, its different from the c28x where if you single step it flushes the pipeline and simply executes 1 instruction. In the disassembly window you will need to single step a couple times till the MMOVXI MR0, #0x1 instruction gets into its execute phase and MR0 actually gets loaded with 1. You then step an additional two times for MMOV32 @0x8900, MR0 to get into its write phase and the value in MR0 gets written to the address 0x8900

Diego Bellachioma said:
2) If I continue with two steps, MPC overruns MSTOP CLA istruction and reaches 0x000a01e program location that it would be assigned to CPU1 code [???].

the CLA stops execution when the MSTOP reaches the D2 (decode 2) phase in the pipeline. At this point the CLA will fire an end-of-task interrupt to the PIE.

I created a video on CLA debugging a while back, it covers the pipeline in a bit more detail.

0 Diego Bellachioma over 8 years ago in reply to Vishal_Coelho

Intellectual 500 points

Hi Vishal. Thank's a lot for your help.

It's one day that I try to understand what's happen. I prove now your advice but, unfortunately, it doesn't work. If I use 'Assembly Step Into' button, I see either MPC and Disassembly window's code continues by single step but, although I cover the follow assembly section code, any changing in register or memory take place (pipeline is 8 stages and D2 is the 4th, if I not in wrong; I try for 14 steps...).

00009ffe: 00000000 MMPYF32 MR0, MR0, MR0 || MMOV32 MR0, @0x0
42 __mdebugstop();
Cla1Task1(), c:
0000a000: 7FA00000 MNOP
0000a002: 7FA00000 MNOP
0000a004: 7FA00000 MNOP
0000a006: 7F600000 MDEBUGSTOP
0000a008: 7FA00000 MNOP
0000a00a: 7FA00000 MNOP
0000a00c: 7FA00000 MNOP
0000a00e: 7FA00000 MNOP
44 __asm(" MMOVXI MR0, #0x1");
0000a010: 7FA00000 MNOP
0000a012: 78800001 MMOVXI MR0, #0x1
0000a014: 7FA00000 MNOP
45 a = 1;
0000a016: 78400000 MMOVIZ MR0, #0x0
0000a018: 78800001 MMOVXI MR0, #0x1
0000a01a: 74C08900 MMOV32 @0x8900, MR0
53 }
0000a01c: 7FA00000 MNOP
0000a01e: 7FA00000 MNOP
0000a020: 7FA00000 MNOP
0000a022: 7F800000 MSTOP
58 }
Cla1Task2(), c:
0000a024: 7FA00000 MNOP
0000a026: 7FA00000 MNOP
0000a028: 7FA00000 MNOP
0000a02a: 7F800000 MSTOP
63 }

In particular, If I try to change CLA's MRx registrer, that would be R/W also in debug registers window, nothing happen; also with an assembler istruction! I try to change TI 2837xD_RAM_CLA_lnk_cpu1.cmd copied in my code folder but I don't find a workaround [Es. I split RAMLS4 & 5 with Cla1Prog : > RAMLS4, PAGE=0; CLA_SCRATCHPAD_SIZE = 0x100 -> 0x200 but nothing changes.

Is there something test that I prove for debug this situation? That's happen also with cla_logig_cpu1 example.

Best regards,

Diego.

0 Jairo70593 over 8 years ago in reply to Diego Bellachioma

Intellectual 390 points

Hi Diego,

I think I'm experiencing a very similar behavior. When I step through the code in the disassembly, the CLA appears to continue executing past the MSTOP instructions. If I continue to step through the code, it'll go thought task1, task2, task3... task8 and then past task 8.

I'm able to reproduce this issue on the example project "cla_divide_cpu01" in controlSUITE/device_support/F2807x/v210/F2807x_examples.

Did you find a workaround or solution?

I'm using the following:

MCU: TMS320F28075 (F2807x)
ti-cgt-c2000_16.9.1.LTS (CGT 16.9.1 LTS)
controlSUITE 3.4.6
OS: macOS
Compile commands:

cl2000 -v28 -ml -mt --float_support=fpu32 --tmu_support=tmu0
  --include_path="/ti/ccsv7/tools/compiler/ti-cgt-c2000_16.9.1.LTS/include"
  --include_path="/ti/controlSUITE/device_support/F2807x/v210/F2807x_headers/include"
  --include_path="/ti/controlSUITE/device_support/F2807x/v210/F2807x_common/include"
  --include_path="/ti/controlSUITE/device_support/F2807x/v210/F2807x_examples_Cpu1/cla_divide/cpu01/"
  -g --define=CPU1 --display_error_number --diag_warning=225 --diag_suppress=10068

Link commands:

cl2000 -v28 -ml -mt --float_support=fpu32 --tmu_support=tmu0 -g
  --define=CPU1 --display_error_number --diag_warning=225 --diag_suppress=10068 -z
  -m"cla_divide_cpu01.map" --stack_size=0x100 --warn_sections
  -i"/ti/ccsv7/tools/compiler/ti-cgt-c2000_16.9.1.LTS/lib"
  -i"/ti/ccsv7/tools/compiler/ti-cgt-c2000_16.9.1.LTS/include"
  -i"/ti/controlSUITE/device_support/F2807x/v210/F2807x_common/cmd"
  -i"/ti/controlSUITE/device_support/F2807x/v210/F2807x_headers/cmd"
  --reread_libs --define=CLA_C=1 --display_error_number
  --xml_link_info="cla_divide_cpu01_linkInfo.xml"
  --rom_model

Thank you,

Jairo

0 Vishal_Coelho over 8 years ago in reply to Diego Bellachioma

TI__Mastermind 20850 points

Hi Diego,

sorry, i missed your response. Have you configured RAMLS4 for CLA ownership in your setup code?

//
// Select LS4RAM to be the programming space for the CLA
// First configure the CLA to be the master for LS4 and then
// set the space to be a program block
//
MemCfgRegs.LSxMSEL.bit.MSEL_LS4 = 1;
MemCfgRegs.LSxCLAPGM.bit.CLAPGM_LS4 = 1;

0 Jairo70593 over 8 years ago in reply to Vishal_Coelho

Intellectual 390 points

Hi Vishal,

Do you think there is an error in the example code in controlSUITE? Below I paste the relevant parts.

This is in device_support/F2807x/v210/F2807x_examples_Cpu1/cla_divide/cpu01/cla_divide_cpu01.c).

    MemCfgRegs.LSxMSEL.bit.MSEL_LS5 = 1;
    MemCfgRegs.LSxCLAPGM.bit.CLAPGM_LS5 = 1;

    MemCfgRegs.LSxMSEL.bit.MSEL_LS0 = 1;
    MemCfgRegs.LSxCLAPGM.bit.CLAPGM_LS0 = 0;

    MemCfgRegs.LSxMSEL.bit.MSEL_LS1 = 1;
    MemCfgRegs.LSxCLAPGM.bit.CLAPGM_LS1 = 0;

The linker command used in the CCS project is F2807x_common/cmd/2807x_RAM_CLA_lnk.cpu1.cmd and has these CLA related lines:

    /* CLA specific sections */
   Cla1Prog         : > RAMLS4_LS5, PAGE=0

   CLADataLS0		: > RAMLS0, PAGE=1
   CLADataLS1		: > RAMLS1, PAGE=1

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

also these:

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

   .scratchpad      : > RAMLS1,       PAGE = 1
   .bss_cla		    : > RAMLS1,       PAGE = 1
   .const_cla	    : > RAMLS1,       PAGE = 1

Thanks,

Jairo

0 Diego Bellachioma over 8 years ago in reply to Jairo70593

Intellectual 500 points

Hi Jairo.

Unfortunately, in Italy it was (1 May) a Worker Holiday so I take advantage to do a travel in Naples. Anyway, I think your solution is in my another thread that I linked follow:

e2e.ti.com/.../588757

In it you can found also Vishal's advice. I hope it'll be help for you.

Bye, Diego.

C2000™︎ microcontrollers

C2000 microcontrollers forum

CCS/TMS320F28379D: I have some behavioral issue while I'm executing CLA C-code