GPIO interrupt problem

Denis Gottardello · ‎2017-01-04

Posted on January 04, 2017 at 19:52

Hi everybody.

I have to implement a Wiegand reader on a STM32 demo board.

Using CubeMX I have defined 2 gpios as GPIO_EXTI and now the HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) is triggered.

The problem is that the callback is triggered more than the right number of times!!!

The right number is 34 but the callback can be triggered 50, 40, 60 times!!!

Is there a way to have a right Wiegand event?

Tesla DeLorean · ‎2017-01-04

Posted on January 04, 2017 at 21:04

Suggest you differentiate and record the GPIO pin states at the events. Are the edges noisy?

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Denis Gottardello · ‎2017-01-04

Posted on January 04, 2017 at 21:24

Absolutely not.

In the origin the firmware was written using mbed. With it the wiegand implementation is perfect. The callback on falling is called exactly 34 times without eny error.

The same demo board with a firmware written using CubeMX - Hal has this very strange behaviour.

Is the HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)

the right approach or is there another way?

David Bathurst · ‎2017-01-04

Posted on January 05, 2017 at 02:43

HAL_GPIO_EXTI_Callback() seems to work as expected for me. One obvious thing to check is that your edge and pull-up/pull-down settings got correctly carried over from mbed to CubeMX. Do your two /IRQ signals share the same EXTI signal or have you managed to arrange things such that they each have their own unique line? I've only got 3 /IRQ signals in my applications and my cpu variant has 3 EXTI lines (0-1, 2-3, 4-15) so I've managed to arrange things so that each is unique.

Seb · ‎2017-01-04

Posted on January 05, 2017 at 05:00

Just in case, if using the same interrupt for both exti, you must make sure that your code checking for the triggered pin is like this:

If then

If.then

And not

If then else if then else

Nor a switch case situation.

The interrupt will trigger again is one of the pending signals remains at the end of the callback.

You can also put a breakpoint to look at the exti register.

Also, if exti is configured to trigger on both edges in the hal flavours more.events will trigger.

To debug this, i would toggle 2 gpio in the callback, one for each exti source and monitor all 4 channels on a scope.

Good luck!

Denis Gottardello · ‎2017-01-05

Posted on January 05, 2017 at 10:20

Sorry. The problem is that my personal wiegand reader is broken.