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.

TMS320F280049: Failed eto parse the previous frame FP

Part Number: TMS320F280049
Other Parts Discussed in Thread: C2000WARE

Hello,


I am getting following error during debugging my code.

It happens after couple of seconds after enabling ePwm1 interrupt. Meantime the interrupt is invoked multiple times. So far, I have found out that such an error happens only when some global variables, which are calculated inside of ISR are set to 0 by default. 

Whenever I set variables to different value I get a bit different error. The MCU ends in Iterrput_defaultHandler function. It is evident the code went through _system_post_cinit() before.

Inside vectID variable is value 0x1F which means that MCU tried to invoke user interrupt 12 but it hasn'ţ defined an ISR vector. In fact, I am not trying to invoke this type of interrupt in my code.  
Could you please help me how to resolve this issue? 

Is it possible that the MCU is somehow damaged? I have uploaded the same code to another control card and it worked without any issue. 

What is stored at location 0x3FB02A? Is there any specific ROM function?

Thanks for reply.

Jozef

  • Hi Jozef,

    Could you try our C20000Ware example where we generate an interrupt from ePWM1 in C:\ti\c2000\C2000Ware_5_00_00_00\driverlib\f28004x\examples\epwm\epwm_ex2_updown_aq.c?

    Does this also crash after enabling ePWM1 interrupt?

    Best,

    Ryan Ma

  • Hi Ryan,

    Thank you for your reply,
    The example code runs without any problem.

    Let me provide you details about the issue.

    When I load the code, run the code for the first time, and enable ePwm1 ISR, there are executed for about 300k iterations of ePwm1 ISR before it ends in _system_post_cinit().

    After the CPU reset through the debugger, there are executed only about 100k iterations of ePwm1 ISR before it ends in Iterrput_defaultHandler();

    Both mentioned behaviors happen only when some specific float variables, used inside of ISR, have an initial value of 0. In the case of different values, I can observe the system perform more iterations until it crashes or even none crash for multiple hours of runtime.

    This is why it is so strange for me.
    I can not figure out how it is possible that MCU ends in _system_post_cinit() or tries to invoke an ISR that is not used inside a code.

     

  • Hello Jozef,

    Since you've already narrowed down the issue to a floating-point variable that has an initial value of 0, can you check to see where this variable is used, that it's declared in the proper scope, and that the interrupt vector used for the ePWM is not changed (i.e. the vector address set)? The default handler is usually caused by an interrupt not being declared or called incorrectly, not a hardware issue.

    I can not figure out how it is possible that MCU ends in _system_post_cinit() or tries to invoke an ISR that is not used inside a code.

    Can you clarify what you mean by invoking an ISR not used inside the code? If you're talking about the default interrupt handler, this is the measure the compiler takes when something improper happens trying to use/call an interrupt.

    Best regards,

    Omer Amir

  • Hi Omer,

    I am sure that the vector address is set properly. The ISR is performed more than a hundred thousand times before the issue happens. During that time the ISR vector is not changed anyhow.

    Sure I can clarify it. When I get an issue _system_post_cinit() I perform a CPU reset using debugger and run the code again. Then the code ends not with _system_post_cinit() as before, but it jumps to Iterrput_defaultHandler();


    There is a variable - vectID which contains the vector ID of the interrupt that occurred. The variable has the value of 31 which refers to user interrupt 12. But I am not using that interrupt in my code at all. The ISR vector is not assigned, this interrupt is not even enabled in my code. Generally, there is too little information available about user interrupts. All I found is that I can invoke it using TRAP instruction. This is why I am confused by the behavior of the code and why I am asking how it is possible I am getting such issues.

    As I mentioned in the first message, this type of issue occurs only on the one board. When I load the same code to another board, the code works well.

    Meantime I performed a further investigation of the code inside of ISR and I managed to locate the problematic section. However, it is even more confusing for me now :).

    The issue happens during the execution of the code below. This code is executed in each ISR iteration.

    static inline void CompDrv_Epwm_Modulator(void)
    {
        float32_t fI1temp, fI2temp, fI3temp;
        const float32_t fEpwmCmpaMax = 738.f;//EPWM_BUCK_BOOST_CMPA_MAX;
        const float32_t fEpwmCmpaMin = 7.0f;//EPWM_BUCK_BOOST_CMPA_MIN;
    
        fI1temp = fPwmOutTmp + fI1DutyCor;
        fI1temp = __fmax(__fmin(fI1temp, fEpwmCmpaMax), fEpwmCmpaMin);   // saturate temporary value to prevent overflowing of compare register
    
        fI2temp = fPwmOutTmp + fI2DutyCor;
        fI2temp = __fmax(__fmin(fI2temp, fEpwmCmpaMax), fEpwmCmpaMin);   // saturate temporary value to prevent overflowing of compare register
    
        fI3temp = fPwmOutTmp + fI3DutyCor;
        fI3temp = __fmax(__fmin(fI3temp, fEpwmCmpaMax), fEpwmCmpaMin);   // saturate temporary value to prevent overflowing of compare register
    
        EPwm1Regs.CMPA.bit.CMPA = (uint16_t)(fI1temp);
        EPwm1Regs.CMPA.bit.CMPAHR = (uint16_t)(65536.0f*(fI1temp - (float32_t)EPwm1Regs.CMPA.bit.CMPA)); 
        EPwm2Regs.CMPA.bit.CMPA = (uint16_t)(fI2temp);
        EPwm2Regs.CMPA.bit.CMPAHR = (uint16_t)(65536.0f*(fI2temp - (float32_t)EPwm2Regs.CMPA.bit.CMPA)); 
        EPwm3Regs.CMPA.bit.CMPA = (uint16_t)(fI3temp);
        EPwm3Regs.CMPA.bit.CMPAHR = (uint16_t)(65536.0f*(fI3temp - (float32_t)EPwm3Regs.CMPA.bit.CMPA)); 
    }

    I observed it does not matter what is the value of variables PwmOutTmp, fI1DutyCor, fI2DutyCor, fI3DutyCor.
    What is interesting, it does matter of variable fEpwmCmpaMin. I have never had the issue when it was set to 0.0f. On the other hand, when I set it to 7.0f, the issue occurs after numerous ISR iterations.

    Best regards,
    Jozef

  • Hello Jozef,

    I'm not sure about the vector ID and why that does not match the interrupt you're using, so if this turns out to be more focused on the interrupt configuration I will forward this to that expert.

    For now, if you open the declaration of __fmax and __fmin are you able to find anything that might throw an error? Is it possible to find the values of the temp variables that are being used when the error occurs? Also, have you checked the errata for this device to make sure that your interrupts situation do not already fall into one of the advisory notes? The code you included above looks like it's a static inline function used within the ISR, so I'm not sure what your ISR looks like.

    Best regards,

    Omer Amir

  • Hello Omer,

    __fmax and __fmin are compiler intrinsic instructions. 

    The overall ISR code is more complex but I believe that the problem is in the provided section because as soon as I remove it from the code the issue does not occur. It seems there is no dependency on the value of PwmOutTmp, fI1DutyCor, fI2DutyCor, fI3DutyCor. But definitely, there is a dependency on the value of fEpwmCmpaMin.

    Jozef

  • Hello Jozef,

    I am sure that the vector address is set properly. The ISR is performed more than a hundred thousand times before the issue happens. During that time the ISR vector is not changed anyhow.

    I assume that all ISRs which are used also have the interrupts registered?

    It seems there is no dependency on the value of PwmOutTmp, fI1DutyCor, fI2DutyCor, fI3DutyCor. But definitely, there is a dependency on the value of fEpwmCmpaMin.

    When you run the program, can you view the Disassembly window at this point to see if the assembly is as expected for lines using fEpwmCmpaMin? Are you able to find out if there's a range of values which will cause this error, or is it a specific value (i.e. is it only 0.0 or if you use anything below 0.0 or extremely large, etc.)?

    Best regards,

    Omer Amir