• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 79 subscribers
  • Views 142 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.

MSP430F5438A: Interrupt Flag not set

Anburaja A
Intellectual 325 points

Part Number: MSP430F5438A

Hi,

I am currently working with the MSP430F5438A. I am able to read the GPIO pin state (for example, P2IN & BIT0) correctly inside a while loop. However, when I configure the same pin as an interrupt source using the configuration shown below, the behavior differs:

P2DIR &= ~BIT0;  
P2IE  |= BIT0;  
P2IES &= ~BIT0;  
P2IFG &= ~BIT0;

Observations:

  • When two pulses (high–low transitions) occur with a short time interval, the controller detects only one interrupt instead of both.

  • If the time interval between two pulse detections is less than 700 ms, only a single interrupt is generated.

  • When the interval is greater than 700 ms, both pulses are detected correctly.

  • This behavior suggests that after the first interrupt occurs, the interrupt flag is not reasserted for approximately 700 ms.

  • In some cases, even with an interval shorter than 700 ms, both interrupts are detected correctly. However, most of the time, only one interrupt is generated.

  • During these missed interrupts, the pin state still transitions correctly between high and low when observed through polling.

Concern:

The root cause of this behavior is not clearly understood. We would like to understand why this issue occurs with the current interrupt configuration and what specifically causes the apparent delay in re-triggering the interrupt.

Thanks,
ANBU.

  • 0
    Guru 25755 points

    First, enable the pin interrupt after clearing the flag register. Otherwise you can get an interrupt.

    Unstated here is what happens when an interrupt occurs. Is there an interrupt service routine? Is it short and does it clear the interrupt? Are there other ISRs that take a long time to complete?

  • 0 in reply to David Schultz
    Intellectual 325 points

    Hi Devid,

    Thank you for your response.

    Yes, an interrupt service routine (ISR) is implemented for this GPIO interrupt. The ISR is intentionally kept short and is used only to validate the interrupt condition, invoke the required read function, and clear the interrupt flag.

    The relevant interrupt-handling logic is shown below:

    #pragma vector=PORT2_VECTOR
    __interrupt void port_2_ISR(void)
    {
    if (P2IFG & BIT0)
    {
    delay_ms(30);

    if (P2IES & BIT0)
    {
    if (case_1 || case_2 || case_3 || case_4 || case_5 || case_6)
    {
    read_function();
    }
    }
    else if (P2IN & BIT0)
    {
    read_function();
    }

    P2IFG &= ~BIT0; // Clear interrupt flag
    }
    }

    Inside the ISR:

    • A short delay (delay_ms(30)) is used for signal stabilization.

    • The interrupt edge selection (P2IES) and pin state (P2IN) are checked to validate the event.

    • read_function() is called only when the required conditions are met, execution time is approximately 90 ms.

    • The interrupt flag (P2IFG) is explicitly cleared before exiting.

    There are no long loops or blocking operations apart from the short delay mentioned above. Other ISRs exist in the system, but they are short and do not intentionally block or disable global interrupts for extended durations.

    Despite this implementation, when two pulses occur within a short interval (less than ~700 ms), the second interrupt is sometimes not generated, even though the GPIO pin state correctly toggles when monitored in the main loop.

    The root cause of this behavior is currently unclear. Any analysis or recommendations to help identify and resolve the issue would be helpful.

    Thanks,
    ANBU

  • 0 in reply to Anburaja A
    Guru 25755 points

    30ms is a long delay in an interrupt routine.

    GIE is cleared when an interrupt is serviced so every ISR is blocking.

    P2IV is a better way to check for the interrupt source than P2IFG. It also clears the interrupt source. Eliminating the long delay you currently have between servicing the pin interrupt and being ready for another.

**Attention** This is a public forum