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.

non-handle interrupt causes context switch corruption in TI-RTOS

Other Parts Discussed in Thread: EK-TM4C1294XL

hi,

I think I have found a bug in TI-RTOS 2.16.00.08 (and earlier version)  when you use a non-handled (zero latency) interrupt on a EK-TM4C1294XL.

My system consists of

  • 10ms SWI user function that runs for 7ms.
  • 1ms HWI RTOS tick timer
  • 5us non-handled HWI user function.

It seems that if the 5us HWI (not shown below) interrupts the RTOS 1ms HWI tick timer just at the wrong time and causes it not to restore the SWI context correctly. This causes the SWI code to go wrong.

I've raised the same issue here TIVA SYS/BIOS FPU context switch corruption with zero latency interrupts.with code but was suggested to post it here on the TI-RTOS forum instead.

I really want to know if this is a TI-RTOS bug or limitation.

cheers

Chris

  • Are you making any kernel calls from your non-managed ISR? This is not allowed.

    Todd
  • hi Todd,

    the non-managed HWI just calculates a value for a 3p3z controller and updates a GPIO pin and PWM values. It just uses integer multiplication and addition.

    #define _xsmmlar(a,c,acc) (((int32_t)(((int64_t)(a)*(c))>>32))+(acc))
    
    inline void CNTRL_3p3zFixedUnified(CNTRL_DataFixedUnified* pCtrl)
    {
    	int32_t acc =0;
    
    	acc = _xsmmlar(pCtrl->m_B3, pCtrl->m_E[2], acc); pCtrl->m_E[2] = pCtrl->m_E[1];
    	acc = _xsmmlar(pCtrl->m_B2, pCtrl->m_E[1],acc); pCtrl->m_E[1] = pCtrl->m_E[0];
    	acc = _xsmmlar(pCtrl->m_B1, pCtrl->m_E[0],acc); pCtrl->m_E[0] = pCtrl->m_Kerr*((pCtrl->m_Ref - pCtrl->m_FeedBack));
    	acc = _xsmmlar(pCtrl->m_B0, pCtrl->m_E[0],acc);
    
    	acc = _xsmmlar(pCtrl->m_A3, pCtrl->m_U[2],acc); pCtrl->m_U[2] = pCtrl->m_U[1];
    	acc = _xsmmlar(pCtrl->m_A2, pCtrl->m_U[1],acc); pCtrl->m_U[1] = pCtrl->m_U[0];
    	acc = _xsmmlar(pCtrl->m_A1, pCtrl->m_U[0],acc);
    
    	pCtrl->m_Out = (uint32_t)acc;
    }
    
    __interrupt void HwiPwmFunc( void )
    {
    	HWREG(GPIO_PORTL_BASE + (GPIO_O_DATA + ((1<<2) << 2))) = 0xFF; //PL2 on
    
        Buck.m_Ref = m_AdcVlimit;
        Buck.m_FeedBack = m_AdcVout;
        CNTRL_3p3zFixedUnified(&Buck);
    
        HWREG(PWM0_BASE + PWM_GEN_0 + PWM_O_X_ISC) = PWM_INT_CNT_LOAD; //PWMGenIntClear(PWM0_BASE, PWM_GEN_0, PWM_INT_CNT_LOAD);
        HWREG(GPIO_PORTL_BASE + (GPIO_O_DATA + ((1<<2) << 2))) = 0x00; //PL2 off
    }

    cheers

    Chris

  • Hi,

    I've now reproduced the fault on a  MSP-EXP432P401R (that's two TI platforms that use TI-RTOS). You just need to add a break point to empty.c:line 50:"         ErrCount++;" and press run and look at the value of "ret". It will be corrupted.

        if (ret >= 0.0f && ret <= ADC_VALUE_MAX)
        {
        	//ok
        }
        else
        {
        	ErrCount++;
            //assert(ret >= 0.0f && ret <= ADC_VALUE_MAX);
        }
        return (uint32_t)ret;

    Here's the project file.

    7450.context_msp432.zip

    cheers

    Chris

  • Hi Christopher,

    Thanks for the project, I am currently looking into it & will reply back shortly.
    -- Emmanuel
  • Hi Emmanuel,
    I've been looking in to this and I think I found the actually problem with TI-RTOS code. I've added my findings here

    e2e.ti.com/.../1840756

    cheers
    Chris
  • Hi Christopher,

    Thanks for submitting this post & project.  We have been able to reproduce the problem & have filed the SYSBIOS-208 bug to fix this in a future release.  

    Regards,

    -- Emmanuel

  • Hi Emmanuel,
    No problem. Will you post back here once its fixed?
    cheers
    Chris
  • Hi Chris,

    I have added a note to the bug to make sure we reply back to this post when it is fixed.

    -- Emmanuel