Description

It turned out that some periph_timer implementations just masked IRQs on timer_clear(). If the interrupt condition then occurred later on, the IRQ flag was set but (due to being masked) not executed. However, the next call to timer_set_absolute() unmasked the IRQ, which resulted in the pending flag to directly cause the timer to fire.

Expected results

timer_set_absolute() doesn't fire directly on setting (if the target is in the future), so that tests/periph_timer from #18963 passes.

Actual results

timer_set_absolute() occasionally fires right away at least on some implementations and #18963 fails.

Tracking

• ATXmega: fails the test early on and is in need of fixing
• ATmega: cpu/atmega_common/periph_timer: fix spurious IRQs #18978
• CC2538: ?
• CC26xx / CC13xx: Not affected (but the test fails due to a different issue)
• EFM32: Not affected
• ESP32: Not affected
• ESP8266: Not affected
• FE310: cpu/riscv_common/periph_timer: Fix timer_clear() #19112
• GD32V: ?
• Kinetis: ?
• LPC1768: ?
• LPC23xx: Not affected
• MSP430: ?
• Native: ?
• QN908x: Not affected, unrelated timer bug fixed in cpu/qn908x: use bitarithm_test_and_clear() & fix cb #18989
• RP2040: Not affected
• SAM0: Not affected
• SAM3: Not affected
• STM32: cpu/stm32/periph_timer: fix spurious IRQs and race conditions #18969
• nRF5x: cpu/nrf5x_common/periph_timer: fix spurious IRQs #18970

Versions

Current master, 2022.10-branch