Change the stdev tolerance stdev from 10 to 33 when npcx timer is used.
This is because the clock source of npcx event timer, which is used to
generate the timeout interrupt, is running at 32.768 KHz.
(i.e. 1 count = ~30.5 us.) The conversion from the absolute system timer
to the event timer count might have -30.5 ~ 30.5 deviation.
The tolerance setting is under the assumption that test sampes are
evenly located at 1030.5 and 969.5 for the worst case.
Fixes#59594
Signed-off-by: Jun Lin <CHLin56@nuvoton.com>
This patch adds a way to simplify using an external tool to measure
timer behaviour on Zephyr. It modifies the timer behaviour
jitter_drift.c tests to toggle a GPIO pin (defined via a new DTS
compatible, "test-kernel-timer-behavior-external") that can be connected
to an external tool, such as a logic analyzer, to measure timer
behaviour.
This GPIO pin toggle is behind a new CONFIG_TIMER_EXTERNAL_TEST Kconfig.
A new pytest test is added so that it can collect the statistics from
the external tool and assert some measurements. To collect statistics
from the external tool, one needs to provide a Python module which
provides a `run(seconds, config)` method, that will perform the test and
return the statistics. Check the README file for more information about
this interface.
Finally, this on twister, this new test is behind a new fixture,
"gpio-timerout".
Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
Use 13% instead of the default 10% when the nRF RTC timer is used
so that the allowed drift is at least one tick long (~122 us in
this case).
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Nordic targets use 24-bit RTC peripheral for system clock. Nordic system
clock timeout implementation relies on RTC CC (capture compare) when
the timeout is in future. Nordic system clock driver allows setting
alarm only to 3 or more counts from current counter value due to silicon
limitation (to ensure that CC event triggers before counter overflow).
RTC CC limitation does not have much impact on normal applications where
there is no need to schedule such short timeouts, but is problematic in
a timer test that expects being able to repeatedly schedule timeouts on
subsequent ticks.
Reduce system tick rate to 8192 on nRF targets to allow setting CC to
the very next tick. With system tick rate being 4 times less than the
hardware tick rate, it is always possible to schedule timeout to happen
in the next tick because ticks are 4 counts apart, i.e. current timer
value + 3 never runs past the next tick.
Fixes: #54211
Signed-off-by: Tomasz Moń <tomasz.mon@nordicsemi.no>
In the default configuration of the test, with 10000 timer samples,
the `periodic_data` array is too big to fit in SRAM on many targets.
Use lower counts of samples for those, depending on their SRAM size,
leaving at least 8 kB for other variables, buffers, stacks etc.
Exclude the test for targets with less than 16 kB.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Zephyr timer is based on system ticks, there usually exists some time drift
due to round up/down errors between cycles, ticks and time delay, we
need to add those expected time drift into the bound calculation for
running this test.
Add a new config TIMER_TEST_PERIOD_MAX_DRIFT_PERCENT for users to set
expected maximum drift percentage for the timer period.
Signed-off-by: Chen Peng1 <peng1.chen@intel.com>
Test and validate the behavior of a timer driver.
Takes a number of absolute timer cycle samples of a periodic timer then
calculates statistical mean, variance, stddev along with total drift over
the entire test time. Ensures standard deviation and drift are within
a given configurable bound.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
