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 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>
Correct a bunch of precision/analysis errors in this test:
* Test items weren't consistent about tick alignment and resetting of
the timestamp, so put these steps into init_timer_data() and call
that immediately before k_timer_start().
* Many items would calculate the initial timestamp AFTER
k_timer_start(), leading to an extra (third!) point where the timer
computation could alias by an extra tick. Always do this
consistently before the timer is started (via init_timer-data()).
* Tickless systems with high tick rates can easily advance the system
uptime while the timer ISR is running, so the system can't expect
perfect accuracy even there (this test was originally written for
ticked systmes where the ISR was by definition happening "at the
same time").
(Unfortunately our most popular high tick rate tickless system,
nRF5, also has a clock that doesn't divide milliseconds exactly, so
it had a special path through all these precision comparisons and
avoided the bugs. We finally found it on a x86 HPET system with 10
kHz ticks.)
* The interval validation was placing a minimum bound on the interval
time but not a maximum (this mistake was what had hidden the failure
to reset the timestamp mentioned above).
Longer term, the millisecond precision math in these tests is at this
point an out of control complexity explosion. We should look at
reworking the core OS tests of k_timer to use tick precision (which is
by definition exact) pervasively and leave the millisecond stuff to a
separate layer testing the alternative/legacy APIs.
Fixes#31964 (probably -- that was reported against up_squared, on
which I had trouble reproducing, but it was a common failure on
ehl_crb).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This reverts commit b98058ecd0.
With icount finally working in QEMU for ARC these tests start to
pass reliably, so no need to exclude them any longer.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Add some error condition or testing cases to verify whether the
robustness of API. Such as give a NULL to some API and check
the response if get result that we were expacted.
Signed-off-by: Jian Kang <jianx.kang@intel.com>
- Remove SYS_ prefix
- shorten POWER_MANAGEMENT to just PM
- DEVICE_POWER_MANAGEMENT -> PM_DEVICE
and use PM_ as the prefix for all PM related Kconfigs
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Add a k_usleep() in test_timer_duration_period test to align ticks
before starting the timer. This fixes some rare off-by-1 failures.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Move init_timer_data() out of k_usleep() tick alignment.
Compute rem_ticks just after busy_wait_ms() to avoid slew
due to 'now' and 'rem_ms' computations.
With slow CPU 32MHz: -2 Ticks.
Signed-off-by: Alexandre Bourdiol <alexandre.bourdiol@st.com>
Insert k_usleep(1) just before k_timer_start()
to guaranty tick alignment for step "test_timer_k_define"
Signed-off-by: Alexandre Bourdiol <alexandre.bourdiol@st.com>
Add new test cases for timer to improve testing infrastructure.
Add different waiting time in existing cases. For new test cases,
restart timer and check for status of timer.
Signed-off-by: Jian Kang <jianx.kang@intel.com>
Several of the values passed to the conversion failure diagnostic are
unsigned and/or 32-bit values, while all format specifiers are for
signed 64-bit integers. Make the specifiers consistent with the
argument.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Unit tests were failing to build because random header was included by
kernel_includes.h. The problem is that rand32.h includes a generated
file that is either not generated or not included when building unit
tests. Also, it is better to limit the scope of this file to where it is
used.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Add timer label for this test suite, so it is included
in sanity check runs with -t timer.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
After the Qemu Cortex-M0 timer driver rework, we may
enable the test-suite that had been (always) excluded
from running on this platform.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
The converted target value for remaining ticks was increased by one to
match original code, which used a one-sided test. The current test is
two-sided, so that increment is already present in the allowed 1 tick
error for boards with no slew, and incorporating it into the absolute
error can cause the test to fail.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
When millisecond/tick conversion is not exact tick delta's are
dependent on the initial tick value. In those cases exact comparisons
need to also allow an adjacent value.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
When HFCLK has a slew making it faster than LFCLK the busy wait can
expire before the timer fires.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Reduce the duration of the timer test so that it will fire before the
busywait elapses even in the worst case of slew between the tick and
busy-wait clocks.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
This test sets a timer using one clock, waits using a second clock,
then sees whether the remaining time is the expected value. When the
two clocks are skewed the comparison requires a threshold. Provide a
means to estimate the maximum expected error.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Adjusting the input value to allow round to nearest can cause an
overflow which invalidates the expectation that the 32-bit result is
the low 32 bits of the 64-bit result. If the adjustment overflows do
the full-precision conversion and truncate in the caller.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
... because it is (required).
This makes a difference when building with CMake and forgetting
ZEPHYR_BASE or not registering Zephyr in the CMake package registry.
In this particular case, REQUIRED turns this harmless looking log
statement:
-- Could NOT find Zephyr (missing: Zephyr_DIR)
-- The C compiler identification is GNU 9.3.0
-- The CXX compiler identification is GNU 9.3.0
-- Check for working C compiler: /usr/bin/cc
-- ...
-- ...
-- ...
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at CMakeLists.txt:8 (target_sources):
Cannot specify sources for target "app" which is not built by
this project.
... into this louder, clearer, faster and (last but not least) final
error:
CMake Error at CMakeLists.txt:5 (find_package):
Could not find a package configuration file provided by "Zephyr" with
any of the following names:
ZephyrConfig.cmake
zephyr-config.cmake
Add the installation prefix of "Zephyr" to CMAKE_PREFIX_PATH or set
"Zephyr_DIR" to a directory containing one of the above files. If
"Zephyr" provides a separate development package or SDK, be sure it
has been installed.
-- Configuring incomplete, errors occurred!
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
When the timer frequency is not a multiple of 1000 converting between
ticks and milliseconds introduces error. Avoid propagating the error
by converting divided values rather than dividing converted values.
Also compensate for observed rate differences between the busywait
clock and the timeout clock.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
A fast timer clock can advance before or after the remaining time
until an event is captured. Verify the expected relationship between
current and remaining time holds for at least one captured current
time.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
When one millisecond is not an integral number of ticks measuring
durations between tick events will sometimes be less than expected to
correct for error that was accumulated between other events. Allow
for that in the duration and period comparisons.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
This commit fixes the assertion in test_timer_remaining() that checks
whether the remaining ticks on a timer is less than or equal to half of
the timer duration after a busy wait of that time. If the timer
duration corresponds to an odd number of ticks, 1 should be added to
the upper bound given k_timer_remaining_ticks() returns
<ticks til next deadline> - <elapsed ticks>,
and <elapsed ticks> is truncated to closest integer tick count.
For example, if
dur_ticks = 3277
<ticks til next deadline> = 3277
<elapsed ticks> = 1638.5 rounded to 1638
rem_ticks would be 1639, which is 1 greater than dur_ticks/2.
Fixes#25331
Signed-off-by: Vincent Wan <vincent.wan@linaro.org>
The test of the absolute timeout feature was a simple whitebox test
that inspected the generated ticks field of different constructors for
identity. But it wasn't simple enough, because it was doing a
ticks->ms->ticks conversion (at compile time, sigh) on the input data,
which is obviously lossy on platforms where ticks are shorter than
milliseconds by non-integral factors.
Fix to do the conversion in just one direction.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This test sets a timer, busy waits for half the duration, and then
checks the remaining time is correct. And it correctly does all its
math in tick precision and aligns to a timer interrupt to eliminate
aliasing due to the tick stride.
But it's waiting using k_busy_wait(), not a timer: "half the duration"
in MICROSECONDS (for k_busy_wait()) is not necessarily representable
as an integer number of TICKS on all platforms. Because k_busy_wait()
always rounds up, we need one extra tick of buffer on those platforms.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Add support for "absolute" timeouts, which are expressed relative to
system uptime instead of deltas from current time. These allow for
more race-resistant code to be written by allowing application code to
do a single timeout computation, once, and then reuse the timeout
value even if the thread wakes up and needs to suspend again later.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Kernel timeouts have always been a 32 bit integer despite the
existence of generation macros, and existing code has been
inconsistent about using them. Upcoming commits are going to make the
timeout arguments opaque, so fix things up to be rigorously correct.
Changes include:
+ Adding a K_TIMEOUT_EQ() macro for code that needs to compare timeout
values for equality (e.g. with K_FOREVER or K_NO_WAIT).
+ Adding a k_msleep() synonym for k_sleep() which can continue to take
integral arguments as k_sleep() moves away to timeout arguments.
+ Pervasively using the K_MSEC(), K_SECONDS(), et. al. macros to
generate timeout arguments.
+ Removing the usage of K_NO_WAIT as the final argument to
K_THREAD_DEFINE(). This is just a count of milliseconds and we need
to use a zero.
This patch include no logic changes and should not affect generated
code at all.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Using find_package to locate Zephyr.
Old behavior was to use $ENV{ZEPHYR_BASE} for inclusion of boiler plate
code.
Whenever an automatic run of CMake happend by the build system / IDE
then it was required that ZEPHYR_BASE was defined.
Using ZEPHYR_BASE only to locate the Zephyr package allows CMake to
cache the base variable and thus allowing subsequent invocation even
if ZEPHYR_BASE is not set in the environment.
It also removes the risk of strange build results if a user switchs
between different Zephyr based project folders and forgetting to reset
ZEPHYR_BASE before running ninja / make.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
'build_only' directive may not be justified here and
prevent to see issue when running the test.
Similarly to non tickless version exclude qemu_x86_coverage
and qemu_cortex_m0 platforms.
It was actually tested failed on qemu_cortex_m0, no error
reported on qemu_x86_coverage, but removed to be safe on that side
as well.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
timer_api requires TEST_USERSPACE activation which is missing
in tickless configuration of the test.
Enable flag in prj_tickless.cnf
Fixes#20904
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Mark the old time conversion APIs deprecated, leave compatibility
macros in place, and replace all usage with the new API.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The new conversion API has a ton of generated utilities. Test it via
enumerating each one of them and throwing a selection of both
hand-picked and random numbers at it. Works by using slightly
different math to compute the expected result and assuming that we
don't have symmetric bugs in both.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Use the int_literal_to_timeout Coccinelle script to convert literal
integer arguments for kernel API timeout parameters to the standard
timeout value representations.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Remove duplicate "tdata.timestamp" update in duration_expire; this
value is already updated by k_uptime_delta.
Besides simply removing duplicate value update, this commit also
addresses the intermittent assertion failure that is caused by
updating "tdata.timestamp" at a later time than the actual execution
of the k_uptime_delta function.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
We filter out the following kernel tests
- tickless_concept
- timer_api
from the set of tests running on QEMU Cortex-M0 platform,
as the tests consistently fail on QEMU. In addition, we
add a workaround for kernel/interrupt test, so it can
successfully execute on QEMU Cortex-M0.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
