cpu/stm32/gpio_f1: fix IRQ handler

[jue89]

Contribution description

This is a follow-up for #16272 for the STM32F1 family. The same description applies. I was able to reproduce the described problem with a STM32F103RC. Compared to #16272 it's pretty hard to trigger that race. It took me hours of patience. Reducing the system clock to 8MHz seems to raise the probability of running into the described race condition

To verify the described race condition you can checkout the Reference Manual page 207 Figure 20.

Testing procedure

I wrote a poor-man's frequency counter, measuring a NE555 multi-vibrator running at 33kHz (i.e. 33.000 IRQs per second) I had laying around:

#include <stdio.h>
#include <stdatomic.h>
#include "periph/gpio.h"
#include "ztimer.h"
#include "fmt.h"

static void _irq (void * arg) {
    uint32_t *cnt = (uint32_t*) arg;
    (*cnt)++;
}

#define GPIO_PULSE GPIO_PIN(PORT_B, 10)

int main(void)
{
    uint32_t cnt = 0;

    gpio_init_int(GPIO_PULSE, GPIO_IN_PD, GPIO_RISING, _irq, (void*) &cnt);
    gpio_irq_disable(GPIO_PULSE);

    while (true) {
        cnt = 0;
        gpio_irq_enable(GPIO_PULSE);
        ztimer_sleep(ZTIMER_USEC, 1000000);
        gpio_irq_disable(GPIO_PULSE);
        print_u32_dec(cnt);
        print_str("\n");
    }

    return 0;
}

Without this patch, the program stalls after a few hours. With this patch it runs for days (and is still running).

Issues/PRs references

#16272

[fjmolinas]

ACK, I don't have the hardware to reproduce but I'm trusting @jue89 and the test procedure provided. More important I've gone through the datasheet and the fix is sensible.

[jue89]

Thank you for reviewing and merging!