False EXTI12 Interrupt Falling Edge Triggering

[danielbathtub]

Hi, 

I have an application that should trigger an interrupt on a falling level signal. 

For argument sake, let's say that I expect it to trigger about once a second. 

Now, when I run my code, it triggers(the EXTI12 ISR) more like 30 times per second. 

I have measured the level signal, and it is flat but the ISR for some reason still triggers. 

Attached is the scope plot of my level signal. I have a Debug IO PIN toggling plot as well. 

you can see, I ran this over 3s and my scope had 3 captures, from my analogy this means the level signal cannot be the cause ?. 

This is my code in the ISR(I have a bunch of other ISR's in here)

Continued: 

then I exit: 

Detail: I do trigger another ISR using Software I don't know if this can have an effect .

The code for this is below: 

 

My ISR subroutine consists of multiple IF statements for me to run specific code when other Level Signals go Low/High. 

Here is a debug IO Pin toggling, Which is how I know the ISR is triggering multiple times, beyond other issues. 

@waclawek.jan  

@Tesla DeLorean 

 

 

[TDK]

Consider using a stronger pulldown on that line. Looks like it's getting a ton of crosstalk from something. Or ideally a low-pass filter like an RC filter.

There's 4 potential triggers in 400us of your scope capture.

[danielbathtub]

I disable the EXTI12 ISR immediately upon entry.  (If you look at the code you'll see this)

I then set a Timer(Timer 14) to trigger an ISR 2 ms later, I then Enable the EXTI12 ISR. 

In the Timer 14 interrupt. So those level signals you see cannot be the cause of the problem. 

[TDK]

Isn't it possible there are edges 2ms after the event as well? Especially given the amount of noise that appears on those signals in the waveform period that you shared. It would be good to see a plot the EXTI pin and the debug pin on the same plot, over the same period.

The chances of there being false triggers on EXTI are nearly nil. It's a hardware Schmitt trigger directly feeding the hardware state machine. There could be "unwanted" triggers but they are certainly present at the signal level otherwise the triggers would not be happening (barring code bugs). Code doesn't appear to have bugs.

[danielbathtub]

Also if you investigate the DEBUG LED toggling signal I sent, You'll see that this toggle occurs every 2mS or So. (After I enable the EXTI12 ISR again)

[LCE]

What's connected to that pin?

In case of a mechanical switch / push button, how is it debounced? There should be at least 10nF, or even an RC filter as TDK proposed.

[danielbathtub]

- In case of a mechanical switch / push button

This is not a hobby project where I am reading a push button. 

- how is it debounced? 

It doesn't need any debouncing, I posted the scope plots, go and see for yourself. 

Beyond that, for this application I cannot heavily filter the signal with hardware at all. 

Also I need the ISR for this application as it is a critical event that  MUST  be asynchronous. 

[LCE]

Okay, keep cool... believe it or not, there are still non-hobby projects out there using push-buttons. And in case of missing information we have to rule out such causes. We don't know anything about the hardware / schematics and the input signal.

 

> Detail: I do trigger another ISR using Software I don't know if this can have an effect .

The IO toggling looks nice and clean with the same timing, could it be that you build yourself something recursive into the ISR? Do you see the timer's timing in the IO toggling?

I'd throw everything out of the EXTI's ISR, except clearing the pending bit and toggling an IO.
Then check the EXTI's input / trigger signal and the toggling IO on the scope.

[danielbathtub]

So I found the solution. 

I was using the ETR as a clearing source to clear the Timer 1. 

The ETR of Timer 1 is mapped to the IO Pin PA12 which is mapped to the EXTI12 Interrupt. 

Thus, when my trigger input goes from high to low, the EXTI12 Falsely triggers, regardless of the IO PIN used.