• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 1733 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Example SWPrioritizedDefaultIsr IER setting for INTx >= 13

Roger Périat
Expert 2040 points
Other Parts Discussed in Thread: C2000WARE

Hi all

I'm wondering if the delivered example code in SWPrioritizedDefaultIsr.c is correct. (Taken from C2000ware, V1.00.04.00).

As example I take TIMER1_ISR:

#if (INT13PL != 0)
__interrupt void TIMER1_ISR(void)     // INT13 or CPU-Timer1
{
     IER |= MINT13;                 // Set "global" priority
     EINT;

    //
    // Insert ISR Code here.......
    //

  // Next two lines for debug only to halt the processor here
  // Remove after inserting ISR Code
    __asm ("      ESTOP0");
     for(;;);
}
#endif

Setting the global priority with IER |=MINT13 does not clear any previous set bit of possible lower priority interrupt.

For lower INT we see (example ADCA1_ISR).

    IER |= M_INT1;
    IER    &= MINT1;

Is there a reason why in  INT13, INT14, (INT15, INT16) the example code is not the same (with OR and AND).

Examples are same for 'device_support' 2833x, 2837xD, 2837xS, 2807x.

Thank you for clarification!

Best regards

Roger

  • 0
    TI__Guru 54195 points
    The IER | =M_INT1 line reenables the current interrupt's group (note the difference between M_INT1 and MINT1). Since interrupts >=13 aren't tied to the PIE, there aren't any other interrupts that could be triggered for that group and therefore no need for it.

    I do agree that it doesn't make much sense to do an OR instead of an AND on the second line though. I see no reason why you wouldn't want to disable the lower priority interrupts. I've done a few quick tests and it seems like a bug to me, but I'm going to check with some colleagues to confirm.

    Thanks,
    Whitney
  • 0 in reply to Whitney Dewey
    TI__Guru 54195 points
    I've decided it is a bug. I'll file the bug reports to get it changed to IER &= MINT13 in a future C2000Ware release.

    Whitney
  • 0 in reply to Whitney Dewey
    Expert 2040 points

    Hi Whitney

    Thank you for your answers. I found some more time to investigate deeper now...

    I do agree with you, it seems to be a bug, but the correction should be done like this I think:

    In the INT13 - INT16 ISRs the IER should be handled like this:

    Example with INT13:

    IER |= MINT13; // set bits of interrupts with higher user priority

    IER &= MINT13; // clear bits of interrupts with lower user priority

    (the OR and AND is faster than the = as seen in Viveks post here: )

    Example with INTPL13 = 2 and INTPL14 =1, rest all zero -> means that INT14 has higher priority than INT13.

    This results in MINT13 = 0x3000, MINT14 = 0

    If INT13 arises, the isr will set IER bits of INT13 and INT14. This seems ok.

    Note that this is also done in todays code. For the case that INT13 has lowest user priority in the system it behaves correctly

    If INT14 arises it would:

    with today's code: do a IER |= 0 -> no effect on IER bits. Bits 13 and 14 are still set, if the interrupt arises 'nested'. Bit 13 set, bit 14 cleared, if interrupt arises not nested (IER bit 14 cleared by HW). Wrong behavior in both cases.

    Corrected code: IER |= 0; IER &= 0 which clears all IER bits. This seems to be ok, because INT14 has highest user priority in my example.

    Roger