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.

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

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.

  • 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.

  • 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.
  • 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

  • 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;

  • 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

  • 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.