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.

TMS320F28069: CLAsin calculation error

Part Number: TMS320F28069
Other Parts Discussed in Thread: C2000WARE

Hi,

my customer is using CLA to calculate sin and got the waveform below:

The CLA code is:

C28x code is:

write angle to fCpuToCla1_PvCtrl, then software trigger CLATASK1, in CLATASK, calculate sin with CLAsin, and send the value to fCla1ToCpu_TestCla1, and then in the C28x code, we read out the calculated value.

2PI is divided into 384 points, so we draw the picture with 384 data, we can see that there are some data which is obviously wrong.

We tried to add more "nop" in C28x code before reading the sin value but it doesn't help.

If we add more "nop" in CLA code like below:

The waveform becomes this: there is still some error(red line is calculated by CLA, green line is calculated by C28x)

We are using cla0_math_library_fpu32.lib.

What may be wrong?

  • Howard, I am looking into this and will report back before the end of the week. 

    Best Regards

    Lori

  • Howard,

    I did a quick test with the CLA math library on F28004x (I don't have a 28069 available).  I took the CLA sin example from C2000Ware.  Changed the input to be 2pi/386 points.  Fed each point to the CLA and graphed the result.  I don't see the issue in the graph.

    Is the issue always at the same location?  If so can they see what value is fed into the CLAsin at that point and then check just that value?  Stepping through the CLA code may provide clues.

    Could it be a edge case of the buffer? 

  • Is the issue always at the same location?

    Yes if we keep the code unchanged. If we add more “nop” as said before, it will be different location.

     If so can they see what value is fed into the CLAsin at that point and then check just that value?  

    We’ve checked the input angle signal and all are correct.

    Stepping through the CLA code may provide clues.

    It’s the last step we can try.

    Could it be a edge case of the buffer?

    How can we check if it’s buffer issue?

  • Howard,

    The customer should try to debug the issue.  I don't think it is an issue with the CLA function itself but maybe something in the code around it or interaction in the system. 

    Since it is always the same location for a given piece of code, then the customer can set a watchpoint to halt the processor right before processing that value (i.e. use the previous value) and then step through the code to see what is going wrong.   This is also a way to check if it is a buffer issue - when I say this I mean maybe a circular buffer one value short so there is a weird value graphed, as an example.  

    Regards

    Lori

  • Lori,

    with exactly the same code, if we do not do single step debug and run the code, we will get the waveform below: the error happens at No.285-No.290 (among the 384 points)

    If we do single step debug, we will have error at No. 10-12 points.

    At the moment we step at No.10 points:

    The disassembly is as below:

  • Hi Howard,

    This seems very strange.  The problem seems to be timing related since moving the code with NOPs changes, but does not fix, the behavior.  

    When the problem shows itself single stepping, were you able to tell where in the calculations things went wrong? 

    I suggest trying to narrow the problem down by simplifying what the system is doing.  This will help to see if it is really a CLA issue or something else in the system.  What else is going on in the system?  Is the C28x waiting for an interrupt from the CLA? Or is it polling a value?  In my simple test case the C28x just waits for the RUN bit to clear and then reads the value.  

    To be safe, Please check that they are using the latest CLA math library and compiler tools.

    -Lori

  • Lori,

    Can we see anything wrong in the disassembly code, 

    I can't find what "MCCNDD" and "UNCF" means.

  • Howard Zou said:
    I can't find what "MCCNDD" and "UNCF" means.

    The CLA instruction set is documented in the device TRM. 

    • MCCNDD is Call Conditional Delayed and
    • UNCF means - Unconditional with flag modification

    Howard Zou said:
    Can we see anything wrong in the disassembly code, 

    I don't see anything wrong, however using the latest compiler tools will help make sure this is true.  The compiler will check for pipeline conflicts. 

    Regards

    Lori