tests/periph_timer_timeout0: Regression test for timer callbacks setting new timers

[jnohlgard]

Contribution description

This test is designed to catch an implementation bug where a timer
callback is called directly from inside timer_set if the given
timeout=0, leading to a stack overflow if timer_set is called from
within the callback of the same timer.

The bug is present on the current revision of the Kinetis LPTMR periph
driver. A bug fix is provided in #10020.

Testing procedure

build and flash tests/periph_timer_timeout0, run make test

Issues/PRs references

#10020 for the bug fix

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[MrKevinWeiss]

This is useful just needs some review time.

[MrKevinWeiss]

I rebased and reran but it seems like some things are not so happy

[Teufelchen1]

Rebased and moved in the new test folder. Test passed on my nrf52dk.

[riot-ci]

Murdock results

❌ FAILED

8f00189 tests: Integrate zero timeout test into timer test

Success	Failures	Total	Runtime
57	1	59	01m:48s

Test failures (1)

Application	Target	Toolchain	Runtime (s)	Worker
tests/periph/timer	samr21-xpro	gnu	24.15	pi-ef3229ad

Artifacts

[Teufelchen1]

The newly introduced tests fails on the samr21-xpro. I think the timer on that board might have a bug.

[maribu]

I have that board at hands. I do like the test, but I dislike that it creates a new app rather than extending the existing tests/periph/timer app with a new test case. The app isn't that large and will still fit RAM and ROM of all relevant boards.

Consolidating the number of apps a bit reduces CI time and increase the life of boards used for testing by reducing the number of flash cycles per full test run.

[Teufelchen1]

@maribu like this? (And still fails on the samr21xpro)

[Teufelchen1]

There have been some recent CI failures for the tests/sys/shell. I think that is related as the failure occurs on the samr21-xpro when compiled using LLVM inside a periodic timer test.

E.g. see this.

-- running on worker pi-68cf63c4 thread 1, build number 3102.
-- executing tests for tests/sys/shell on samr21-xpro (compiled with llvm toolchain):
- executing hook run_test_pre
- resetting USB power...
- waiting for tty to re-attach...
- hook run_test_pre finished
make: Entering directory '/tmp/dwq.0.8417650337034919/b0edffdfccc3b6b961cda4d7e8c9893f/tests/sys/shell'
/bin/sh: 1: arm-none-eabi-gcc: not found
/tmp/dwq.0.8417650337034919/b0edffdfccc3b6b961cda4d7e8c9893f/dist/tools/edbg/edbg.sh flash /tmp/dwq.0.8417650337034919/b0edffdfccc3b6b961cda4d7e8c9893f/build/tests_shell.bin
### Flashing Target ###
Debugger: ATMEL EDBG CMSIS-DAP ATML2127031800002288 02.01.0157 (S)
Clock frequency: 16.0 MHz
Target: SAM R21G18 (Rev B)
Verification...... done.
Done flashing
make: Nothing to be done for 'termdeps'.
make: Leaving directory '/tmp/dwq.0.8417650337034919/b0edffdfccc3b6b961cda4d7e8c9893f/tests/sys/shell'
make: Entering directory '/tmp/dwq.0.8417650337034919/b0edffdfccc3b6b961cda4d7e8c9893f/tests/sys/shell'
/bin/sh: 1: arm-none-eabi-gcc: not found


/bin/sh: 1: arm-none-eabi-gcc: not found
socat - open:/dev/ttyACM0,b115200,echo=0,raw,cs8,parenb=0,cstopb=0 


> 

> bufsize
bufsize

60
> ____________________________________________________verylong
____________________________________________________verylong

shell: maximum line length exceeded
> garbage1234��
garbage1234

> 

> ��
shell exited
> 

> ��
periodic 5
> 

> periodic 5

> test
Timeout in expect script at "child.expect_exact('test')" (tests/sys/shell/tests/01-run.py:214)

make: *** [/tmp/dwq.0.8417650337034919/b0edffdfccc3b6b961cda4d7e8c9893f/makefiles/tests/tests.inc.mk:26: test] Error 1
make: Leaving directory '/tmp/dwq.0.8417650337034919/b0edffdfccc3b6b961cda4d7e8c9893f/tests/sys/shell'