Cortex-M4 interrupts behaviour when same interrupt vector has multiple interrupts

Excellent question.

This is how I understand what happens (simplified slightly):

1: A "pending bit" will be set for your interrupt.

2: When the priority level is lower than your interrupt's priority level, the priority level is set to the one that matches your interrupt; your interrupt will be invoked.

3: You interrupt reads the pending bits; eg. those bits that caused the interrupt, perhaps a new pending bit will be set just after you've read the bits.

4: Clear the pending bits that you've just read. The one that's set just after you read the bits will not be cleared.

5: Process the bits you have in your variable you've read.

6: Return. The priority level is now restored.

7: Because there's now a pending bit, your interrupt will be invoked again.

Here's an example...

void TIMER0_IRQHandler(void)

{

    uint32_t pendingBits;

    pendingBits = INTERRUPT_REGISTER;

    INTERRUPT_REGISTER = pendingBits;  /* this clears the bits that are set in the variable 'pendingBits'. */

    if(pendingBits & (1 << 0))

    {

        /* handle interrupt for bit 0 */

    }

    if(pendingBits & (1 << 1))

    {

      /* handle interrupt for bit 1 */

    }

    /* ... */

    if(pendingBits & (1 << 31))

    {

      /* handle interrupt for bit 31 */

    }

}

... As I am not aware what your interrupt register is named, I've made up a name for it. It should work the same on all Cortex-M as far as I understand.

So if you follow the above mentioned model, you should never 'miss' an interrupt, not even if a pending bit is set right after you've read the value into the pendingBits, and before you're writing the bit-mask to clear.

Also, you should avoid using 'else if', so you'll process all the pending bits, otherwise you'll only process one.

jyiu - please correct me if I'm wrong.

Correction: I just learned something new, so I renamed the above interrupt routine, in order to be a more correct example; by not featuring the EXTI*_IRQHandler interrupts.

I think this method should work for other kinds of interrupts, where you get multiple pending bits per interrupt vector. That could be timer-interrupts, for instance.

Please refer to Joseph's answer, which should clarify the EXTI* interrupts.

Excellent question.

This is how I understand what happens (simplified slightly):

1: A "pending bit" will be set for your interrupt.

2: When the priority level is lower than your interrupt's priority level, the priority level is set to the one that matches your interrupt; your interrupt will be invoked.

3: You interrupt reads the pending bits; eg. those bits that caused the interrupt, perhaps a new pending bit will be set just after you've read the bits.

4: Clear the pending bits that you've just read. The one that's set just after you read the bits will not be cleared.

5: Process the bits you have in your variable you've read.

6: Return. The priority level is now restored.

7: Because there's now a pending bit, your interrupt will be invoked again.

Here's an example...

void TIMER0_IRQHandler(void)

{

    uint32_t pendingBits;

    pendingBits = INTERRUPT_REGISTER;

    INTERRUPT_REGISTER = pendingBits;  /* this clears the bits that are set in the variable 'pendingBits'. */

    if(pendingBits & (1 << 0))

    {

        /* handle interrupt for bit 0 */

    }

    if(pendingBits & (1 << 1))

    {

      /* handle interrupt for bit 1 */

    }

    /* ... */

    if(pendingBits & (1 << 31))

    {

      /* handle interrupt for bit 31 */

    }

}

... As I am not aware what your interrupt register is named, I've made up a name for it. It should work the same on all Cortex-M as far as I understand.

So if you follow the above mentioned model, you should never 'miss' an interrupt, not even if a pending bit is set right after you've read the value into the pendingBits, and before you're writing the bit-mask to clear.

Also, you should avoid using 'else if', so you'll process all the pending bits, otherwise you'll only process one.

jyiu - please correct me if I'm wrong.

Correction: I just learned something new, so I renamed the above interrupt routine, in order to be a more correct example; by not featuring the EXTI*_IRQHandler interrupts.

I think this method should work for other kinds of interrupts, where you get multiple pending bits per interrupt vector. That could be timer-interrupts, for instance.

Please refer to Joseph's answer, which should clarify the EXTI* interrupts.

The STM32's External Interrupt/Event Controller (EXTI) module should be designed to general interrupt request in form of level (rather than pulse). Also, the EXTI module have its own interrupt pending status register for each of the pin. The interrupt requests are merged using an OR function before connecting to the NVIC. (Note: this is specific to STM32 design).

Each of the interrupt service (for each EXTI channel) need to clear their own pending status in the EXTI using EXTI_PR (pending register) to deassert the interrupt to NVIC. If another EXTI is pending, the clearing of the pending status in EXTI is not going to deassert the interrupt line, so the same IRQ will be triggered again and get serviced when the first ISR exited.

Both coding styles should work. But the first one works better (lower overhead) when multiple EXTI interrupts arrive at the same time because it can service multiple EXTI requests in the same ISR execution. The second coding style means it need to exit the ISR, then get back to it again and service the another EXTI request.

regards,

Joseph