Description

The periph_timer supports operating the hardware timer at different frequencies. It is expected that when timer_init() for a given frequency doesn't report an error, that the timer works as advertised.

Steps to reproduce the issue

make TIMER_SPEED=216000000 BOARD=nucleo-f767zi -C tests/periph_timer flash test

Expected results

Either failing timer initialization (which indicates an unsupported frequency was chosen), or fully functioning timer.

Actual results

READY
s
START
main(): This is RIOT! (Version: 2020.10-devel-1520-gf15a9-ptp-clock)

Test for peripheral TIMERs

Available timers: 1

Testing TIMER_0:
TIMER_0: initialization successful
TIMER_0: stopped
TIMER_0: set channel 0 to 5000
TIMER_0: set channel 1 to 10000
TIMER_0: set channel 2 to 15000
TIMER_0: set channel 3 to 20000
TIMER_0: starting
Timeout in expect script at "child.expect('TEST SUCCEEDED')" (tests/periph_timer/tests/01-run.py:21)

make: *** [/home/maribu/Repos/software/RIOT/tests/periph_timer/../../Makefile.include:761: test] Error 1
make: Leaving directory '/home/maribu/Repos/software/RIOT/tests/periph_timer'

Versions

Current master

Remarks

I think the fundamential issue here is missing test coverage. IMO the test should iterate over all available combinations of timers and supported frequencies. However, there currently is now way to efficiently query supported frequencies. An API extension for that seems to be reasonable.

With that in place, automatic tests would cause bugs and regressions for timer frequencies different from the one xtimer uses.