TMS570LC4357: VIM/Arm Core interaction (phantom IRQ) with Micrium OS III

TMS570LC4357: VIM/Arm Core interaction (phantom IRQ) with Micrium OS III

Home Forums Real-Time Kernels TMS570LC4357: VIM/Arm Core interaction (phantom IRQ) with Micrium OS III

This topic contains 4 replies, has 2 voices, and was last updated by  Arun Prakash 9 months, 1 week ago.

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #26231

    Arun Prakash
    Participant

    We are using Micrium uCos III with a TMS570LC4357 and we are trying to debug a phantom interrupt issue.
    In our current configuration there are many interrupts enabled, SCI4 Rx interrupt, EQEP Interrupt, ECAP interrupt, EPWM interrupt and DCQAN interrupt.
    FIQ is not used. All interrupts are made to use the IRQ vector and we assume uC OS III ‘manages’ the interrupts by masking all lower priority interrupts
    when servicing a particular request.

    Whenever the multiple interrupts occur at the same time, phantom interrupt is called and then after it is stuck there only.
    We would like to know whether the interrupt IRQ race condition has been tested and working with uC OS III version 3.04.05.
    Also We would like to know if this is the bug identified in this OS version and it is fixed in the later versions. If this is the case, we
    would prefer to purchase the newer uC OS III version.

    Regards
    -Arun

    #26237

    Farukh Chaudhry
    Participant

    Hello,

    When you say “phantom” interrupt, do you mean spurious interrupts? Please explain what is happening on the IRQ pins.
    The user application has to mask out lower priority interrupts.

    Regards
    FC

    #26238

    Arun Prakash
    Participant

    Hi Farukh Chaudhry

    In our application, we are generating and feeding the PWM signal to one of the ECAP pin to determine the period and the dutycycle of the PWM signal.
    The frequency of the PWM signal is set to 20kHz. The ECAP module is configured in continuous mode to generate the IRQ interrupts after capturing the signal.
    Also the controller is configured to receive the serial bytes through SCI4 using the receive IRQ interrupt at 9600 baudrate. When the ECAP interrupt and the
    SCI4 receive interrupt occurs at the same time then the phantom ISR is called by the controller.
    We have also observed that whenever the incoming serial bytes are blocked then the controller operates as expected, TMS570 Controller will not call the phantom interrupt ISR.

    Regards
    -Arun

    #26242

    Farukh Chaudhry
    Participant

    Hello,

    Can you provide more information what the “phantom ISR” is? Are the SC14 and IRQ interrupts at the same priority level?

    Regards,
    FC

    #26248

    Arun Prakash
    Participant

    We have observed that there is no error in the function OS_CPU_ExceptHndlr (CPU_INT32U src_id). Whenever we get the IRQ interrupt, src_id passed to this function is 6.
    That implies this case is called. case OS_CPU_ARM_EXCEPT_IRQ:
    BSP_IntHandlerSrc((CPU_INT16U)src_id);
    break;

    In this switch statement the controller is never stuck in the infinite loop of default case.

    We have identify the reason for calling the phantom interrupt. This is happening in the function BSP_IntHandlerSrc((CPU_INT16U)src_id).

    This function declaration is given as below.

    void BSP_IntHandlerSrc (CPU_INT16U src_id)
    {
    CPU_FNCT_VOID isr_fnct;
    CPU_REG32 *p_vim_tbl;
    CPU_INT32U ch_ix;
    CPU_INT32U pend_reg_0;
    CPU_INT32U pend_reg_1;
    CPU_INT32U pend_reg_2;
    CPU_INT32U pend_reg_3;
    CPU_INT32U pend_mask;

    switch (src_id) {
    case OS_CPU_ARM_EXCEPT_IRQ:
    ch_ix = (CPU_INT32U )BSP_INT_REG_IRQ_INDEX;
    p_vim_tbl = (CPU_REG32 *)BSP_INT_ADDR_INT_TBL;
    isr_fnct = (CPU_FNCT_VOID )p_vim_tbl[ch_ix];

    if (isr_fnct != (CPU_FNCT_VOID)0) {
    pend_reg_0 = BSP_INT_REG_REQENACLR0; // Store interrupt state
    pend_reg_1 = BSP_INT_REG_REQENACLR1;
    pend_reg_2 = BSP_INT_REG_REQENACLR2;
    pend_reg_3 = BSP_INT_REG_REQENACLR3;
    ch_ix–;
    if (ch_ix <= 31) { //Dis. all interrupts of lower priority than current
    pend_mask = 0xFFFFFFFF << ch_ix;
    BSP_INT_REG_REQENACLR0 = pend_mask;
    BSP_INT_REG_REQENACLR1 = 0xFFFFFFFF;
    BSP_INT_REG_REQENACLR2 = 0xFFFFFFFF;
    BSP_INT_REG_REQENACLR3 = 0xFFFFFFFF;
    } else if (ch_ix <= 63) {
    pend_mask = 0xFFFFFFFF << (ch_ix – 32);
    BSP_INT_REG_REQENACLR1 = pend_mask;
    BSP_INT_REG_REQENACLR2 = 0xFFFFFFFF;
    BSP_INT_REG_REQENACLR3 = 0xFFFFFFFF;
    } else if (ch_ix <= 95) {
    pend_mask = 0xFFFFFFFF << (ch_ix – 64);
    BSP_INT_REG_REQENACLR2 = pend_mask;
    BSP_INT_REG_REQENACLR3 = 0xFFFFFFFF;
    } else {
    pend_mask = 0xFFFFFFFF << (ch_ix – 96);
    BSP_INT_REG_REQENACLR3 = pend_mask;
    }
    CPU_IntEn(); // Enable high-priority interrupts
    (*isr_fnct)(); // Invoke ISR
    CPU_IntDis(); // Disable interrupts
    BSP_INT_REG_REQENASET0 = pend_reg_0; // Restore original interrupt state
    BSP_INT_REG_REQENASET1 = pend_reg_1;
    BSP_INT_REG_REQENASET2 = pend_reg_2;
    BSP_INT_REG_REQENASET3 = pend_reg_3;
    }
    break;

    case OS_CPU_ARM_EXCEPT_FIQ: // See Note #1.
    default:
    break;
    }
    }

    Here in this function when the variable ch_ix becomes zero, the the micro-controller is calling the Phantom interrupt function and there after it is stuck.

    could you please let us know the cases, In which this variable is cleared?

    Also, please let us know your solution for this issue.

Viewing 5 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.

View the complete site map

x
Loading...