The requirement of being able to spend only 10% of processing time
on execution of timer handlers that are scheduled on every tick is
not really possible to fulfill on platforms like the nRF ones where
the tick period is quite short (~30 us in this case). Relax this
requirement and accept if at least one-third of the processing time
is available for other work while handling the timer tick train.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
The test in its default configuration needs 3600 seconds to complete,
so use such timeout value in testcase.yaml so that twister called with
--enable-slow option can successfully execute it.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
For tests that set CONFIG_MP_NUM_CPUS, switch to using
CONFIG_MP_MAX_NUM_CPUS instead as we work to phase out
CONFIG_MP_NUM_CPUS.
Signed-off-by: Kumar Gala <kumar.gala@intel.com>
Test timers with a train of one tick timers to test that
a configured SYS_CLOCK_TICKS_PER_SEC is sensible. If the TICKS_PER_SEC
is too high the timer train will take longer than expected to reach
the station. Worse, if the timer driver has too short of a minimum
delay for its processing power and the tick rate is too high its
possible the device will get caught in an interrupt loop
preventing any threads from running while processing timers.
This test validates that the tick rate configured is actually able to be
processed without delays while also having work done in threads ensuring
that no thread scheduling delays occur either from delayed timers or an
interrupt loop from preventing threads from running.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
Adds a custom test_main and renames the test suite for jitter_drift.
Runs the jitter_drift test suite.
The order of these tests matter on hardware as the counter is often
reset on loading the test program. This is useful as its far less likely
to encounter a clock counter rollover. On arm this is especially useful.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
Move the main.c timer behavior test code to jitter_drift.c
so that other tests may be added to the suite.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
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>
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>.
This patch proposes to then include <zephyr/kernel.h> instead of
<zephyr/zephyr.h> since it is more clear that you are including the
Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a
catch-all header that may be confusing. Most applications need to
include a bunch of other things to compile, e.g. driver headers or
subsystem headers like BT, logging, etc.
The idea of a catch-all header in Zephyr is probably not feasible
anyway. Reason is that Zephyr is not a library, like it could be for
example `libpython`. Zephyr provides many utilities nowadays: a kernel,
drivers, subsystems, etc and things will likely grow. A catch-all header
would be massive, difficult to keep up-to-date. It is also likely that
an application will only build a small subset. Note that subsystem-level
headers may use a catch-all approach to make things easier, though.
NOTE: This patch is **NOT** removing the header, just removing its usage
in-tree. I'd advocate for its deprecation (add a #warning on it), but I
understand many people will have concerns.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
SYS_CLOCK_TICKS_PER_SEC of it8xxx2 is 4096 (244us).
Running test_sleep_abs item on it8xxx2 and we get
k_us_to_ticks_ceil32(250) = 2 and late = 2, so it failed.
After we enable the CONFIG_PM, it needs more time to resume
from low power mode, so I modify the logic to <= for passing
the test.
fixes#49605
Signed-off-by: Ruibin Chang <Ruibin.Chang@ite.com.tw>
The test will always fail on emulated/simulated environments. Exclude
this one which was failing.
Signed-off-by: Tom Burdick <thomas.burdick@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>
Add a bunch of missing "zephyr/" prefixes to #include statements in
various test and test framework files.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Subtracting with a uint64_t operand yields a uint64_t result, for which
the absolute value is not terribly interesting. Cast the operand to
int64_t.
Use llabs instead of abs as abs takes an int parameter and not an
int64_t. This appears to work even with the minimal C library.
Signed-off-by: Keith Packard <keithp@keithp.com>
ehl_crb supports HPET timer by default. Add test suite to test APIC
timer's TSC deadline mode on ehl_crb.
Signed-off-by: Yinfang Wang <yinfang.wang@intel.com>
This commit adds the `volatile` qualifier to the timing variables, in
order to ensure that the compiler does not try to optimise the test in
a way that can affect the execution time measurements.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
In order to bring consistency in-tree, migrate all tests to the new
prefix <zephyr/...>. Note that the conversion has been scripted, refer
to #45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
This commit excludes the kernel monotonic timer test for the
`qemu_arc_hs` platform because this test may fail with the ARC QEMU
6.2 on certain host systems.
Refer to the following issues for more details:
* foss-for-synopsys-dwc-arc-processors/qemu#67
* zephyrproject-rtos/zephyr#44862
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
Previously cycle64 was under `samples/`. It's been moved to
`tests/` and has been marked with `slow: True` so that it
will not disrupt CI by adding excessive delays.
Fixes#40367
Signed-off-by: Christopher Friedt <chrisfriedt@gmail.com>
The test identifier of timer error case in testcase.yaml is
exactly the same as timer api's test identifier.
So I fix this.
Signed-off-by: Lixin Guo <lixinx.guo@intel.com>
This patch is testing the test_sleep_abs with a longer
real time slot value. The reason is that for platforms
like stm32wb55rg with PM, the real time slot must be adjusted
because of the LPTIM ticker.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
This commit adds an additional test case for several kernel test suites
to ensure that the linker script generator is working correctly for a
subset of the Zephyr test suites.
The ensures that the basic functionality of the linker script generator
is working while still keep the performance impact on CI at a minimal
level.
Using the kernel tests is a trade-off between testing coverage of the
linker script generator and the time it takes to complete CI.
The kernel tests is considered to have the broadest coverage of various
features important for the generated linker script.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Move to CMake 3.20.0.
At the Toolchain WG it was decided to move to CMake 3.20.0.
The main reason for increasing CMake version is better toolchain
support.
Better toolchain support is added in the following CMake versions:
- armclang, CMake 3.15
- Intel oneAPI, CMake 3.20
- IAR, CMake 3.15 and 3.20
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This board was added to test coverage feature when coverage was
introduced. This is now being testing with other boards and
configurations on a regular basis, so no need for this extra overhead in
CI.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Extended test to validate that timer API is working as expected
when CONFIG_MULTITHREADING=n.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
The clock/timer APIs are not application facing APIs, however, similar
to arch_ and a few other APIs they are available to implement drivers
and add support for new hardware and are documented and available to be
used outside of the clock/kernel subsystems.
Remove the leading z_ and provide them as clock_* APIs for someone
writing a new timer driver to use.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The test_timeout_abs case had baked in similar mistakes to the
off-by-one in the absolute timer implementation. FOR THE RECORD:
If you have an absolute timeout expiration set for a tick value "N",
and the current time returned by k_uptime_ticks() is "T", then the
time returned (at the same moment) by any of the *_remaining_ticks()
APIs must ALWAYS AND FOREVER BE EXACTLY "N - T" (also: "N - T > 0"
always, until the moment the kernel ISR hands off control to the first
timeout handler expiring at that tick).
The tick math is exact. No slop is needed on any systems, no matter
whether their clocks divide by milliseconds or not.
The only gotcha is that we need to be sure that the calls don't
interleave with a real time tick advance, which we do here with a
simple retry loop.
But, about slop... This patch also includes a related fix for the
test_sleep_abs(). On an intel_adsp (which has 50 kHz ticks, a
comparatively slow idle resume and interrupt entry, and even has two
CPUs to mess with latency measurements) I would occasionally see the
k_sleep() take more than a tick to wake up from the interrupt handler
until the return to application code. Add some real time slop there
(just 100us) to handle systems like this.
Fixes#32572
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Absolute timeouts were covered, but nothing was testing their actual
expiration time and there was an off-by-one.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
