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.
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
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
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.
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