cpu/stm32/gpio: fix IRQ handler

[jue89]

Contribution description

I've found a race condition in the GPIO IRQ handling. Without this patch, there is a small probability to get caught in an endless loop since the related Pending Request bit is never cleared.

What happend:

1. The GPIO's related IMR bit is enabled
2. The condition of the interrupt is met (like the GPIO went from HIGH to LOW) and the corresponding PR bit is set
3. The IMR bit is cleared by the program
4. The program gets interrupted and isr_exti() is called
5. isr_exti() reads the PR bits and masks out the bit that caused its execution. Thus, the PR bit is never cleared and isr_exti() is called again after cortexm_isr_end().

Testing procedure

The DOSE driver uses the GPIO IRQ to detect start bits of Ethernet frames. This IRQ is then disabled during transmission and enabled after the whole frame has been received. Without this patch I was able to trigger the race condition within a few hours by creating some heavy bus traffic. After applying this patch, I was able to run this driver for days (tests are still ongoing).

To verify the mechanics (i.e. the PR bit must be cleared even if the corresponding IMR bit is unset) please see RM0360 Page 173 Figure 21

Issues/PRs references

none

[benpicco]

Make sense.

[fjmolinas]

@jue89 was this recently introduced or has this bug been forever present?

[fjmolinas]

@jue89 was this recently introduced or has this bug been forever present?

In any case I think this should be backported no?

[jue89]

Thanks for your review and responses!

@jue89 was this recently introduced or has this bug been forever present?

In any case I think this should be backported no?

I've used the STM32F103RCT (which doesn't seem to be affected by this race condition even though the same pattern is used in the gpio_f1.c implementation) before I switched to the STM32F030CCT. So this seems to be a bug that has been introduced in 2016: df99604

So which releases should receive a backport?

Nevertheless - can this PR be merged? Is one ACK enough?

[fjmolinas]

Nevertheless - can this PR be merged? Is one ACK enough?

Yes one ACK is enough.

[fjmolinas]

I've used the STM32F103RCT (which doesn't seem to be affected by this race condition even though the same pattern is used in the gpio_f1.c implementation) before I switched to the STM32F030CCT. So this seems to be a bug that has been introduced in 2016: df99604

Hmm @jia200x what do you think?

[jue89]

Thanks for merging!

I came to the conclusion that we should port this patch to the gpio_f1.c implementation as well as the implementation for the STM32G0, STM32L5 and STM32MP1. The datasheet implies that the race condition could happen there as well. Or what do you think?