• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 83 subscribers
  • Views 449 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

TMS320F28P650DK: Critical bug (?)/CPU crash on C2000/ CLA1 GPIO code

TMS320F28P650DK: Task not running on large-ish CLA program

ALon G
Prodigy 55 points

Part Number: TMS320F28P650DK
Other Parts Discussed in Thread: C2000WARE, SYSCONFIG

Tool/software:

Hi All,

CCS: 20.2.0.12_1.8.0, compiler v22.6.2.LTS

Issue: CLA task size makes another task stop running correctly

To re-create:

1. Import cla_ex1_asin project
2. Add an extra line #300 in cla_ex1_asin.c, in order to run task 2:

299       CLA_forceTasks(CLA1_BASE,CLA_TASKFLAG_1);
300       CLA_forceTasks(CLA1_BASE,CLA_TASKFLAG_2);  
3. Modify tasks 2 and 3 in asin.cla as follows:
unsigned long x1,x2,x3;
 
unsigned int result[3];
interrupt void Cla1Task2 ( void )
{
    unsigned long i;
    i  = 1;
 
    x2 = i%32;     
    x3 = i+1;
 
    if (x2==1)
      result[0]=1;
    else result[0]=2;
}

#define USELESS_WORK {  x1= 1 + (1U << (i%32));}
interrupt void Cla1Task3 ( void )
{
 unsigned int i;

 USELESS_WORK  USELESS_WORK  USELESS_WORK USELESS_WORK  USELESS_WORK  USELESS_WORK
 USELESS_WORK  USELESS_WORK  USELESS_WORK USELESS_WORK  USELESS_WORK  USELESS_WORK
 USELESS_WORK  USELESS_WORK  USELESS_WORK USELESS_WORK  USELESS_WORK  USELESS_WORK
 USELESS_WORK  USELESS_WORK  USELESS_WORK USELESS_WORK  USELESS_WORK  USELESS_WORK
 USELESS_WORK  USELESS_WORK  USELESS_WORK USELESS_WORK  USELESS_WORK  USELESS_WORK
 //USELESS_WORK  USELESS_WORK  USELESS_WORK USELESS_WORK  USELESS_WORK  USELESS_WORK
 

}
And run the program.
The resulting variables x1,x2 are set the correct values:
x2:1
x3:2
Now remove the // comment from the last superfluous code line in task 3, so task 3 becomes:

interrupt void Cla1Task3 ( void )
{
 unsigned int i;

 USELESS_WORK  USELESS_WORK  USELESS_WORK USELESS_WORK  USELESS_WORK  USELESS_WORK
 USELESS_WORK  USELESS_WORK  USELESS_WORK USELESS_WORK  USELESS_WORK  USELESS_WORK
 USELESS_WORK  USELESS_WORK  USELESS_WORK USELESS_WORK  USELESS_WORK  USELESS_WORK
 USELESS_WORK  USELESS_WORK  USELESS_WORK USELESS_WORK  USELESS_WORK  USELESS_WORK
 USELESS_WORK  USELESS_WORK  USELESS_WORK USELESS_WORK  USELESS_WORK  USELESS_WORK
 USELESS_WORK  USELESS_WORK  USELESS_WORK USELESS_WORK  USELESS_WORK  USELESS_WORK
 

}
 
And run the program again.
Now x1 and x2 are both 0.

Task 3 is not even run, it is simply taking up more space, and unless I have misunderstood how these should work, it somehow affects how task 2 is run.
Task 3 size is 1688 bytes, well below the task code size limit specified in the documentation for CLA2.
Thank You,
-Alon.

  • 0
    TI__Mastermind 22580 points

    Hi Alon,

    I will try to replicate your setup and see if I get the same behavior. I do see a potential issue which is that the i variable in task 3 is used in the USELESS_WORK define before its actually initialized. I'm not sure how this could cause the behavior you are seeing but maybe try initializing i in task 3 before the defines to see if it changes anything in the meantime.

    Best Regards,

    Delaney

  • 0 in reply to Delaney Woodward
    Prodigy 55 points

    Hi Delaney,
    Thank you for your reply.
    Task 3 in not run and the contents of task 3 do not really matter, only the code space they take up.
    You can re-create this issue with any code that sits there (or in task 4 etc.) and takes space.
    Thank You,

    -Alon.

  • 0 in reply to ALon G
    TI__Mastermind 22580 points

    Hi Alon,

    I will test this out and get back to you with a response in the next 1-2 days. Apologies for the delay.

    Best Regards,

    Delaney

  • 0 in reply to Delaney Woodward
    TI__Mastermind 22580 points

    Hi Alon,

    Apologies for the long delay. I have tried the steps from above and end up getting a memory error once I uncomment the last line in task 3. I am also using the same compiler version: v22.6.2.LTS.

    Have you made any modifications to the linker cmd file? Which C2000ware version did you import the project from?

    Thanks,

    Delaney

  • 0 in reply to ALon G
    TI__Mastermind 22580 points

    Hi Alon,

    Thank you for providing the linker cmd files. I will try building and running the project with these and get back to you.

    Best Regards,

    Delaney

  • 0 in reply to Delaney Woodward
    TI__Mastermind 22580 points

    Hi Alon,

    I see the issue. In Sysconfig, you configure LS8 as CLA program memory and LS9 as CPU dedicated memory. However, the linker cmd file assigns Cla1Prog to:

       Cla1Prog         : > RAMLS0 | RAMLS9

    Due to the syntax ">" used, the linker will place the Cla1Prog memory into either LS0 or LS9, whichever has enough space for all the CLA program memory. When the extra line is commented out, the linker places all of the CLA program memory into LS0 without issue. When the extra line in CLA task 3 is commented in, the Cla1Prog section can no longer fit in LS0 and is placed in LS9 instead. But as we established, LS9 isn't configured for CLA program memory in Sysconfig, it is configured as CPU dedicated memory which is an issue. 

    There are also some additional nuances with LS8 and LS9 on this device. They have different addresses from the CPU and CLA perspectives. Because of this, we need to define separate LOAD and RUN addresses in the linker cmd file for the CLA program. 

    Solution: 

    1. Add the below as a new MEMORY element. This is already present as a comment in the linker cmd file you sent - comment it into the file.

        RAMLS8_CLA    : origin = 0x004000, length = 0x002000  // Use only if configured as CLA program memory

    1. Change the Cla1Prog SECTIONS specification to the below:

       Cla1Prog        : LOAD = RAMLS8,
                     RUN = RAMLS8_CLA,
                     ALIGN(4)

    Here is the fixed linker cmd file for reference:

     https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/171/28p65x_5F00_cla_5F00_ram_5F00_lnk_5F00_cpu1.cmd

    Please upvote this response if the solution works for you. Note that there are some extra steps needed to get LS8 and LS9 working for a flash build. See the C2000ware example cla_asin_ls8_9. 

    Best Regards,

    Delaney

  • 0 in reply to Delaney Woodward
    Prodigy 55 points

    Thanks! this solved the issue.

    I find it odd that no error or warning has been issued, the linker knows which areas of memory belong to what.

    So instead of me catching my oversight myself in 19 seconds it has taken 19 days to resolve.

    Thank You,

    -Alon.

  • 0 in reply to ALon G
    TI__Mastermind 22580 points

    Hi Alon,

    I agree, it's difficult to pinpoint this issue without an error or warning from the linker. I'm not sure if it's possible to have the linker detect the settings selected in Sysconfig, but I will look into it. I've also filed requests for the below enhancements to try and avoid people running into this situation in the future:

    • Sysconfig warning if LS8 or LS9 are selected as CLA program memory mentioning that different RUN and LOAD addresses are needed in the linker cmd file as well as additional steps in the application code for flash builds. 
    • Add additional comments to all F28P65x and F28P55x linker cmd files explaining how LS8 or LS9 need to be used if added for the CLA

    Best Regards,

    Delaney