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>
When CONFIG_POLL was set, it was historically true that the queue
could (if a higher priority thread "stole" an insert) return a
spurious NULL instead of continuing to wait on a timeout.
This deliberately exercises that race.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The k_queue data structure, when CONFIG_POLL was enabled, would
inexplicably use k_poll() as its blocking mechanism instead of the
original wait_q/pend() code. This was actually racy, see commit
b173e4353f. The code was structured as a condition variable: using
a spinlock around the queue data before deciding to block. But unlike
pend_current_thread(), k_poll() cannot atomically release a lock.
A workaround had been in place for this, and then accidentally
reverted (both by me!) because the code looked "wrong".
This is just fragile, there's no reason to have two implementations of
k_queue_get(). Remove.
Note that this also removes a test case in the work_queue test where
(when CONFIG_POLL was enabled, but not otherwise) it was checking for
the ability to immediately cancel a delayed work item that was
submitted with a timeout of K_NO_WAIT (i.e. "queue it immediately").
This DOES NOT work with the origina/non-poll queue backend, and has
never been a documented behavior of k_delayed_work_submit_to_queue()
under any circumstances. I don't know why we were testing this.
Fixes#25904
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The tests normally verify that pin configuration succeeded by checking
the return value. That's not necessary on the cleanup path, so
expressly ignore the result.
Also lift the common code to before the exit branching.
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>
Add test cases that verify various bits and pieces of the legacy
devicetree macros match the new APIs.
Writing these test cases without giving rise to deprecated macro
warnings which might break people's CI if they build with -Werror
requires turning off the __WARN() generation in
devicetree_legacy_unfixed.h. The entire file is deprecated at this
point and must be explicitly enabled with an opt-in Kconfig option, so
there isn't any harm in doing this.
Nevertheless, take a minimally invasive approach to avoiding __WARN()
generation in gen_legacy_defines.py, to avoid the possibility of
breakage. This code is basically frozen anyway, so hacks like this
won't cause maintainability problems since it isn't being actively
maintained.
Use the new tests as fodder for a migration guide from the old API in
the documentation.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This is preparation for an additional test suite specifically for the
legacy API which will be added next.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
At some point, "child-binding:" apparently only worked up to 2 levels
deep. That's not the case anymore, but add a regression test to make
sure that doesn't break. 3 levels deep ought to be enough for anyone.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Added configuration which allows to run test-suite
on nrf52840dk_nrf52840 and nrf52dk_rf52832 boards.
fixes#25701
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
Increase the main thread stack size for this test
to 2048; this increase prevents stacking errors in
the main thread, in several Cortex-M platforms.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
On nucleo_f429zi and nucleo_f207zg boards,
0xFFFFFFF0 is not a faulty address.
Instead we can use 0x0FFFFFFFF.
Signed-off-by: Alexandre Bourdiol <alexandre.bourdiol@st.com>
The cell paramater should have been last to match both the
DT_*_CELL_BY_NAME macros as well as how DT_PHA_BY_IDX works. We fix the
DT_INST_*_CELL_BY_NAME macros as well.
The dma macro's implemented the behavior correctly, but got the argument
names in correct. We fix that to make everything consistent.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Enhance the sample console output of the arm_interrupt
test, to reflect recent changes in test context as well
as kernel fault handling log output format.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
We add a test case to verify that the Cortex-M fault
handling is able to catch stacking errors explicitly
due to exception entry frame stacking (that is, when
the Cortex-M MCU does not report Data Access Violation
MemManage fault with a valid MMFAR value, but only a
Stacking MemManage fault). We update the README file
accordingly.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
A quick test on a dummy device that:
- opens a socket (success)
- sends data (success)
- suspends (success)
- suspends (failure)
- sends data (failure)
- resumes (success)
- resumes (failure)
- sends data (success)
This permits to show that PM states are properly handled in network
stack.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Because the sleep instruction issue for nsim_hs_smp, idle
loop is used to simulate behavior of sleep, so arch_cpu_idle will
forever loop. This causes cpu idle test loop, then the whole
context test timeouts.
as a fix, skip the cpu_idle test for nsim_hs_smp now.
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
Added test for check proper service of flush-write when buffer
contains unaligned amount of data.
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
Add a new test with clean output and warn the user that the version
without clean output will output garbled text.
Fixes#23799
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
For success cases, the net_pkt is handled by the IP stack
so no need to free the net_pkt. The double free is not causing
any issues as the net_pkt code will just ignore the request but
we should avoid doing it because of error prints that are printed.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Signed-off-by: Oleg Zhurakivskyy <oleg.zhurakivskyy@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 test depends on additional hardware being connected to the board,
add a fixture and cleanup whitelist.
Fixes#25177
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The dummy driver never implemented device power management, so the
fact the not-implemented stub returned success was a false negative.
Verify the expected behavior now, leaving the test code in place for
when somebody provides a non-trivial PM control function.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Configures the adc api test to use the arduino header A2 pin on the
frdm_k82f board. This follows frdm_k64f and frdm_kw41z boards, which
also use the arduino header A2 pin for the test.
Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
arc emsdp's console will use irq 108/107 which will
conflict with irqs used in tests (emsdp has 112 irqs),
so add a workaround for emsdp.
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
For x86, TSC is being used to gather timing information. However,
CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC is not the same as TSC
frequency when HPET (or other) timer is used. So use the system
clock to calibrate the TSC frequency so we can use it to
calculate timing information.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Kernel objects were being directly accessed without previously
calling k_thread_access_grant().
This change allows each test that requires an asynchronous
event to send it to a common work queue with correct
permissions.
Signed-off-by: Christopher Friedt <chrisfriedt@gmail.com>
On some STM32 boards : nucleo_wb55rg, nucleo_l152re
the test lasts longer than defaut 60sec timeout.
Increase timeout to 120 sec.
Signed-off-by: Alexandre Bourdiol <alexandre.bourdiol@st.com>
This makes the up_squared board default to x86_64.
This also adds a new board, up_squared_32, for when 32-bit
is desired.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This test works by starting a bunch of poll events, dropping the test
thread priority, calling k_poll(), and assuming that all the timeouts
that fired woke up high priority threads and thus ran before k_poll()
could return. But that isn't true if you have another CPU that can
run the low priority thread while the last high priority thread
finishes up!
This just isn't SMP-correct. Mark 1cpu.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Most boards run with 10 kHz ticks producing a period of 5 ms for 50
tick interval used in the timer periodic test. On Nordic 50 ticks
corresponds to 1.5 ms which is too short to complete the TC_PRINT()
call within the handler, causing the periodic timer to starve the
osDelay that would turn off the timer.
Adjust the period to be at least 5 ms or 50 ticks to avoid this
problem while not breaking other platform with slower tick rates.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Cortex-M has 24bit systick.
But this test by default set 1 TICK per seconds, which is
achievable only if frequency is below 0x00FFFFFF (around 16MHz).
20 Ticks per secondes allows a frequency up to 335544300Hz (335MHz)
Signed-off-by: Alexandre Bourdiol <alexandre.bourdiol@st.com>
The existing uart driver ns16550 did not have ISR locking that
effected IO APIC working in fixed delivery mode in SMP system
x86_64. This commit adds ISR locking mechanism using spinlock
for the interrupt related services.
The CONFIG_IPM_CONSOLE_STACK_SIZE is increased to lift
limitation of stack size experienced in IPM driver test with
this spinlock impelentation.
Fixes#23026
Signed-off-by: Jennifer Williams <jennifer.m.williams@intel.com>
Since introduction of #24374 this test fails on STM32 boards.
Due to 1Hz frequency of RTC used, the 'diff' could be 0.
But then 'counter_us_to_ticks(dev, processing_limit_us)' is also 0.
We should allow the equality in the assert.
Signed-off-by: Alexandre Bourdiol <alexandre.bourdiol@st.com>
When switching from rising edge to falling edge of test:
test_gpio_deprecated(),
because exti callback is already configured (from rising edge test),
the pin configuration abort for EBUSY reason.
It is necessary to disable interrupt,
so that next test will start with clean configuration.
Signed-off-by: Alexandre Bourdiol <alexandre.bourdiol@st.com>
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>
GPIO 050/051 are being used for tachometer sensor as
CONFIG_TACH_XEC is enabled by default. So for the gpio_basic_api
test, another set of GPIOs are needed. GPIO 156/157 are chosen
as they are (more or less) dedicated for two LEDs on board and
not being used for other functions (pinmux-wise).
Fixes#25272
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
In Qemu icount mode, busy wait will cause lots of wall time and it's
very easy to get sanitycheck timeout(this case will be successful if
given enough timeout value for sanitycheck), so reduce test interval
to save execution time.
Signed-off-by: Wentong Wu <wentong.wu@intel.com>
This CPU-bound test on qemu_riscv32 platform is very slow when
QEMU icount mode enabled, taking upwards of several minutes.
There's little value here, this is a unit test of library code
and we have coverage of the RISC-V 32 bit arch via hifive1.
Signed-off-by: Wentong Wu <wentong.wu@intel.com>
Peter Bigot