Countermeasure of hardware noise for software interrupt GPIO-EXTI line

[Sen10]

I'm a beginner at STM processor, and I'm trying programming software interrupt using GPIO port as EXTI line at STM32L4R5QI(STM32L4+ series) processor.

Then, I was wondering when I was reading the reference manual of STM32L4+ series.  It seems that the EXTI interrupt is OR condition between the hardware interrupt signal and software interrupt signal as below:

In addition, for using EXTI line, I configured the GPIO port as EXTI and configured GPIO mode at STM32CubeMX as below:

In other words, I concern that the software interrupt might be occurred by unintentional hardware signal(ex. noise) at configured GPIO-EXTI pin.

Therefore, I want to take a countermeasure to my concern.  In detail, I think I have to become disable the "Falling trigger selection register"(EXTI_FTSR) and the "Rising trigger selection register"(EXTI_RTSR) manually, but I don't know my idea is correct because there is no configuration at STM32CubeMX.  ("manually" means setting those register "disable" in my program code.)

Is my idea correct?  Or, is there any another idea?

I would appreciate if you could give me some advice.

[Uwe Bonnes · Accepted solution]

Set up the right way, EXTI is quite robust. If your EXTI signal is noise, try to clean up. If your program runs amok, fix it. If you need features you do not find in HAL, talk direct to the hardware. Reading and understanding the reference manual is always a good idea.

[Pavel A.]

Welcome!

>   It seems that the EXTI interrupt is OR condition between the hardware interrupt signal and software interrupt signal 

Correct. EXTI interrupts can be triggered by software (good for testing).

One thing that you should know about STM32 interrupts is that clearing the interrupt indication in EXTI and other modules can be delayed for a few clocks, so you can receive "false" interrupts. See the yellow pages for details (thanks to Jan) . This is a common issue not specific to EXTI.

If your interrupt input is noisy, try to filter/debounce by software. If the noise is too bad so that software debouncing does not perform well - fix this in hardware, as @Uwe Bonnes advices.

In the ST "HAL" library, EXTI has two drivers: one is combined with GPIO (similar to Linux "GPIO interrupts"). Another one (hal_exti....) manages advanced things. The EXTI module in STM32 serves also for connection of various internal interrupt and event sources of the SoC, this can be confusing, just ignore all that for beginning.

[Sen10]

Hi @Uwe Bonnes , and @Pavel A. 

Thank you for your replying.  

@Pavel A., thank you for your additional information.

I'm so sorry for being late for your reply because I'm not good at English.

I understood that the unintended action by noise didn't rarely happen if my setting was correct because the EXTI is robust at noise.  And It seems good to filter or debounce the noise in my program if I try to take measure.

In my post, I concerned the risk of noise and I wanted to remove it by my program.  In actual, the EXTI line in my board is not signaled and my software IRQ handler is not called.

Fortunately, I found the other pin which is pull-downed and unused in my board (In other words, I found more safety pin in my board).  I will change the pin assign because it seems more easier.

I apologize for my lack of confirmation.  I really appreciate your kind advice despite my unskillful post.

Best Regards.