2

I am new to stm32f427 board and I am digging a bit deeper. I think that on the internet, especially StackOverflow, people sort of agreed on this, just an example:

void EXTI9_5_IRQHandler(void) {

/* Make sure that interrupt flag is set */
if (EXTI_GetITStatus(EXTI_Line5) != RESET) {
    /* Do your stuff when PB5 is changed */
    

    /* Clear interrupt flag */
    EXTI_ClearITPendingBit(EXTI_Line5);
}
}

This handler, as everyone explained, needs to do whatever you need inside and must clear the pending flag when exiting the interrupt, and people claim that the pending bit is the interrupt flag.

However, in my case and many cases like here, they clear this bit first but many people claim that doing this will kill your interrupt functionality since you will be clearing the bit as soon as you get it. However, this is not the case, and moreover, it's totally the opposite. If I don't do it clearly first, my code would never work.

I want to figure out the reason behind it. Could someone kindly explain?

tanjavaner
  • 40
  • 6
user3431800
  • 191
  • 2
  • 17
  • what you clear in what order is system dependent. I highly recommend you start by polling your way toward the cpu then eventually enable the interrupt into the core itself (cpsie something). specifically so you can see what is going on in a slow and controlled manner. What does the peripheral do, what does it take to clear the peripheral. is there an interrupt controller, repeat, is there anything deeper in the core you have to mess with? – old_timer Apr 30 '18 at 19:41
  • or in the core you use to detect, with a cortex-m there are separate vectors per interrupt so you ask the peripheral, but for other architectures or cores you have to ask in the isr who caused it then spread out to find the peripheral. – old_timer Apr 30 '18 at 19:41
  • generally you want to clear from the peripheral toward the cpu, whether you do it first thing or last thing is a bit of a software design thing to some extent, can the architecture re-interrupt you once in? if so do you want it to if you take too long (for that interrupt or others at that priority). – old_timer Apr 30 '18 at 19:43
  • 1
    even with all the documentation you have available you should still do some testing/hacking whatever word you like, specific tests that are geared toward understanding what is going on and how to react. intentionally dont return for example, does it interrupt you again? if you clear it or not? the uart is very helpful for all of this, bad idea normally to print in an isr, but for this kind of thing print then go into an infinite loop to see what you see on entry into the isr. – old_timer Apr 30 '18 at 19:43
  • Thank you for commenting, old_timer. I did my interrupt thing in debugging mode so i see there is a exti_pr register, and all clear pending bit does is to set/reset this bit based on your exti line. software might be an issue, if for sure, i am happy as long as i know that's the issue. I see the software clear that bit first when it jump to the break point and toggle my LEDs, so it is definitely executing clearing first. So it confuses how the pr bit works, per the documentation. – user3431800 Apr 30 '18 at 21:17
  • @old_timer those are helpful tips in getting a feel for what the interrupts are doing, I appreciate it. Getting the interrupts working properly and reliably seems to take some experimentation. – mrbean Jul 18 '22 at 17:18

2 Answers2

2

The flag should be cleared at the beginning . The clear operation needs some time to propagate across the bus. If you clear it just before exit from the handler you need to use the barrier instruction, read back the flag (it does not work in some cases) or leave enough time for the operation to propagate. Otherwise you may get the "ghost" interrupts.

0___________
  • 60,014
  • 4
  • 34
  • 74
  • I experienced "ghost" interrupts when working with the USART for LIN protocol and line break detection. I'm not going to lie it was a pain in the a#$ trying to figure out what was going on. I'm still not 100% sure I know. I'll have to look into the barrier instruction. I noticed that if I read back the flag it wasn't working sometimes and would re-enter the ISR. I had to clear the flag and then read the ISR register in order clear the bits to get things working properly. Took a fair bit of experimentation to figure it out. I'll have to try the barrier instruction. – mrbean Jul 18 '22 at 17:40
2

As mentioned before clearing the interrupt flag is not executed immediately. In other words the command needs a few clock cycles to reach the interrupt controller before the interrupt flag is finally cleared. In the meanwhile the CPU continues to execute the code of your interrupt handler in parallel. So, if you exit your ISR immediately after calling EXTI_ClearITPendingBit(…) the ISR is left before the interrupt flag is actually cleared. Unfortunately the result is that the interrupt handler will immediately be called again since the interrupt flag was not cleared, yet. As a matter of fact the interrupt handler will exactly be called twice, because the interrupt flag will for sure be cleared after the second call. I had the same problem a few years ago and it took me some time to figure out the reason. As a best practice I can recommend to clear the interrupt flag at the beginning of your ISR. It is not true that you are killing your interrupt functionality by doing this on an STM32x device (explicitly: this is not a general recommendation). The CORTEX-M core "knows" that it is in an ISR and does not "forget" it once you clear the interrupt flag. Explaining this in detail would go beyond the scope of this answer. But you can be absolutely sure your ISR is executed correctly if you do so. To let you know, I am (continuously) working with STM32 controllers for about 15 years now.

Tim Wensky
  • 134
  • 7
  • you have just repated my answer. BTW Cortex does not have the `EXTI_ClearITPendingBit(…)` instruction. Using the high level library function in the processor level answer is wrong. What if the author of the library will add the readback or barrier instruction. Then your answer will be 100% wrong – 0___________ Jul 08 '18 at 10:30
  • I did not repeat your answer. I just explained it a lot more detailed. My answer is 100% correct. I am not discussing 'What if' scenarios. – Tim Wensky Jul 08 '18 at 17:02
  • I would be interested in understanding the details of how the Cortex-M core knows that it is in an ISR. This operation led to a lot of confusion for me. – mrbean Jul 18 '22 at 17:35
  • The CORTEX-M core writes a special value into the LINK register. Abstract from "The Cortex-M3 processor" PM0056 by ST chapter 2.3.7 "Exception return": "EXC_RETURN is the value loaded into the LR on exception entry. The exception mechanism relies on this value to detect when the processor has completed an exception handler" – Tim Wensky Jul 19 '22 at 06:52