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.

TMS320F28075: Dealing with ISR overflow in CLA

Part Number: TMS320F28075

Hi team,

I am supporting my customer to test their housekeeping code to handle CLA and ADC overflow. This is a question related to both CLA and compliler, please feel free to involve some experts.

1. To create overflow condition:

How they produce overflow by purpose is to repeat some simple code in CLA task. However  have some interesting findings:

1) Repeat EPwm1Regs.CMPA.bit.CMPA = 1;

With level 4 optimization, we noticed if repeat this code for <18 times, the CLA task execution time does not change. However, if repeat it for 19 times, the overflow would occur. 

2) Do the same thing with address pointer:

This time, the overflow would occur when they repeat the code for 2 times.

3) Turn off the optimazing:

The same code could be repeat for 50 times, and no overflow happens

Customer would like to know what is the optimizating principle behind this?

 

2. Handing overflow:

1) In order to clear ADC and CLA overflow, customer have the following code in CLA:

AdcdRegs.ADCINTOVFCLR.bit.ADCINT1 = 1;

AdcdRegs.ADCINTFLGCLR.bit.ADCINT1 = 1;

__meallow();

Cla1Regs.MICLROVF.bit. INT1 = 1;

__medis();

   But we noticed the related flag is not cleared, and CLA task cannot be entered anymore.

2) If we try to clear the overflow flag in PWM. Both flag can be cleared, but CLA task cannot be entered.

Why we cannot clear oveflow flag in CLA and CLA task cannot be enter? Commets are welcomed.

Regards,

Brian

  • Brian,

    I'm not sure I understand what the customer is trying to achieve.  Are they trying to set the overflow/underflow flags in the CLA status register?  

    I'm not clear how writing to the CMPA register repeatedly would do this.  The flags are related to FPU math operations overflowing and underflowing. 

    Please clarify.

    Lori

  • Hi Lori,

    As I stated at the very beginning, customer is just trying to reproduce an CLA overflow and verify their overflow handler. So setting PWM compare is just to extend the CLA ISR length to produce a overflow on purpose. 

    The reason why the do this test is the observed CLA and ADC overflow in products after changing to a new compiler version. So they did several test based on different operation and optimzation. This the point 1 question in previous post.

    After the overflow is produced, they need a handler to make sure even there is an overflow, the next interrupt can still be responded. So they did several test like I summarized in point 2.

    Regards,

    Brian

  • Brian,

    As I stated in my response, the CLA overflow flag is for math calculations that produce an overflow. 

    If the CLA task length is only limited by the size of the CLA program memory on the device.  If they exceed this length, then the task will not not work because part of the task will be in memory that can not be accessed by the CLA.   The linker itself can detect this.

    If I have misunderstood what the customer is doing, please provide additional details. 

    Regards

    Lori

  • As description of MIOVF register in datasheet:

    ”Each bit in the overflow flag register corresponds to a CLA task. The bit is set when an interrupt overflow event has occurred for the specific task. An overflow event occurs when the MIFR register bit is already set when a new interrupt is received from a peripheral source.”

    I believe the what my customer is doing should make sense.

    Regards,

    Brian

  • Brian,

    Now I understand.  My apologies as I was thinking of the MSTF register overflow flag.  Thank you for clarifying which overflow flag.  

    For item (1) the optimization - I'm not sure what is occurring.  The register is volatile so the compiler shouldn't be optimizing the access out.  Can you post a screenshot of the disassembly in each case? 

    For item (2.1) the CLA registers are not accessible via the CLA itself.  This is why the CLA is not able to clear the flag and the C28x can.  This information is missing from the peripheral register map in the F2807x datasheet and I have filed a request for it to be added.  (It is documented in the F28004x datasheet)

    For item (2.2) is the flag still set for the task?  This may also need to be cleared in order to get the task to start running again.

    Regards

    Lori

  • Hi Lori,

    Thanks for the kindly response.

    As for the optimization result, I am coordinating customer to show us the result. Would reach back to team once we get the result.

    Actually, the reason why customer is doing these complicated test is because they are confused by the optimization in CLA. With optimization enabled, they found even with minimum modification of CLA code, their might be some fault happens like overflow or task cannot be triggered.

    Thus customer have the follow 2 request:

    1. They would like to know whether we have any guidance/training of how the optimization works. Will would help them to identify what would be the root cause for this mess.

    2. Can they only apply optimization to C28 code but not CLA code. Do we have any commmand to tell the compiler not to optimize a certain part of code? I have an impression of this function, more detail would be appreciated.

    Regards,

    Brian 

  • Brian Wang0 said:
    1. They would like to know whether we have any guidance/training of how the optimization works. Will would help them to identify what would be the root cause for this mess.

    Let me investigate and get back to you by end of Tuesday next week. 

    Brian Wang0 said:
    2. Can they only apply optimization to C28 code but not CLA code. Do we have any commmand to tell the compiler not to optimize a certain part of code? I have an impression of this function, more detail would be appreciated.

    In CCS, right click on a specific file and select properties.  In the dialog box the customer can select the optimization that will be applied to a specific file. 

    Best Regards

    Lori

  • This was closed offline.

    The overflow issue is highly related to the unused RAM size of CLA. 

    The root cause was a modification to the CMD file, allocating CLA RAM to RAMD, which is not allowed to operate by CLA. Thus, when CLA code reaches a certain size, the code would be allocated to RAMD0, which would apparently cause problem. Since the engineer directly changed origin address and length definition of the memory in CMD, it is pretty hard to notice. After fixing this problem, the code runs well.