Is calling EXTI_GetITStatus() sometimes unnecessary?

[sima2]

Posted on February 13, 2018 at 16:02

I wonder if I can delete the call to EXTI_GetITStatus() in the following example code?

TheEXTI0_IRQHandler is not used for any other external interrupts. So thecall to

EXTI_GetITStatus() seems unnecessary?

/**
 * @brief ISR for EXTI0 detects a rising edge.
 *
 * This ISR is run when PE0 receives an rising edge. It will increment the counter variable.
 */
void EXTI0_IRQHandler(void)
{
 if (EXTI_GetITStatus(EXTI_Line0) != RESET) // Make sure it is an External interrupt line 0 interrupt 
 {
 counter++;
 EXTI_ClearITPendingBit(EXTI_Line0); // Clear the pending bit
 }
}�?�?�?�?�?�?�?�?�?�?�?�?�?

#stm32

[Tesla DeLorean · Accepted solution]

Posted on February 13, 2018 at 17:38

I would not delete it, and I'd move the counter++ the other side of the clearing code.

The CM3/4 have a pipeline/tail-chaining/write-buffer issue with clearing interrupt sources on off-core buses, due to extended latency of this completing. The interrupt can remain pending as you exit the IRQ handler, and then briefly re-enter, validation allows you to ignore this spurious entry. This is a long described hazard.

[sima2]

Posted on February 14, 2018 at 10:11

Just for curiosity. Do you have more information about this, some reference?

[Tesla DeLorean]

Posted on February 14, 2018 at 16:20

https://community.st.com/0D50X00009XkiGqSAJ

 

https://community.st.com/0D50X00009XkYyUSAV

 

https://community.st.com/0D50X00009XkZ4PSAV

 

[Tesla DeLorean]

Posted on February 14, 2018 at 16:31

http://www.keil.com/support/docs/3928.htm

 

The issue on the STM32 is it takes time for a write to propagate through the peripheral's synchronous logic and physically clear the bit feeding back to the NVIC. The bit will clear, but the core has already decided to tail chain back into the handler.