• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 80 subscribers
  • Views 2112 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.

MSP430 Interrupt Characteristics-- intermittent missed interrupt

RLund
Prodigy 235 points
Other Parts Discussed in Thread: MSP430F1612

I am working with an MSP430F1612 with the latest version of IAR's development environment.

I am working on verifying operation when multiple interrupts occur close to or at the same time.

What is happening is that if I am servicing a higher priority interrupt at the time a lower priority one is triggered, the flag for the lower priority one isn't always being set.

Both interrupts are being generated on some of the general purpose port pins.  One is on port1, the other on port 2.

Breakpoints have verified that the input level on the pin of the lower priority interrupt is changing as expected.  I see the port2 pin register as low at one point, then high later (its set up as a rising edge interrupt), but the associated interrupt flag isn't always set.

I have triple checked the code, and nothing in the first routine is affecting any of the flag or enable settings associated with the lower priority interrupt.

What I am wondering is, what are the characteristics for an interrupt that is detectable by the MSP430?  I can't find this in any of the data sheets.  Maybe I'm on the edge of a rising edge that is too fast.  The device creating the interrupt is a TI DSP, a 5510.  It won't lower the line for triggering the interrupt until it gets a response from the MSP430.

Any thoughts would be appreciated.

Thanks,

Becky

  • 0
    Guru 227245 points

    Hmm, sounds strange.
    There is a known issue withe the port interrupts on the 1x series. It applies, however, only to multiple interrupts on the same port.

    When an interurpt is triggered and you read the interrupt flag register the very moment a second interrupt happens on the same port, this interrupt is lost as the hardware cannot write to the IFG register or the write is negated by the update of the IFG register. That's known, so at the end of my ISR, I check the the port/the IFG register whether I may detect anotehr interrupt and handle it directly. It won't, however, help if the lost interrupt was cause by a short signal. In this case, the CCRx units of any timer can be used for catching the signal instead of the port ISR (only one port pin per port used for interrupts, others on CCRx inputs).

    It shouldn't be a problem for interrupts on port 1 and port 2.

    Rebecca Lund said:
    Maybe I'm on the edge of a rising edge that is too fast

    As long as the line isn't lowered, the raise time shouldn't be an issue.

    A look into your code could be useful (sometimes one simply doesn't see what's wrong, no matter how often one checks)
    The ISR(s) and the init code would be enough.

  • 0
    Guru 58965 points

    I am very puzzled by what you stated in your posting.

    (a) About interrupt priority: For MSP430, the interrupt priority is only relevant when the chip tries to decide which interrupt (amongst all the currently pending interrupts) to grant. Once granted, GIE is cleared and the corresponding ISR starts. Before that ISR returns, or deliberately set GIE, MSP430 will not grant another interrupt, even if the pending interrupt has a higher interrupt priority.

    (b) About P1IFG and P2IFG: These bits can be set by hardware if the corresponding PxDIR, PxSEL are configured as digital input pin and that pin sensed a rising/falling edge that matches the PxIES setting at that time. The PxIFG can only be cleared by system reset or CPU instructions that deliberately clears them. This is independent of interrupts, ISRs, or any other activities of MSP430.

     

**Attention** This is a public forum