This commit moves the BLE GATT Battery service
from /samples/bluetooth/gatt to /subsys/bluetooth/services and
adds a Kconfig entry to enable and configure the service;
when enabled, it will register itself automatically.
Signed-off-by: Emanuele Di Santo <emdi@nordicsemi.no>
Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
This fixes the following error:
passing argument 5 of ‘fsutil_read_file’ from incompatible pointer type
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
This commit contributes the basic testing for
k_float_disable() API, for ARM and x86 ARCHes.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Make fp_sharing a 'parent' test suite directory, and
rename the original fp_sharing test into
tests/kernel/fp_sharing/generic. In this
way more FP-related tests can be grouped
together in the same test directory.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Noticed this error print when running in mps2_an385 platform.
<err> net_if: There is no network interface to work with!
Adding CONFIG_NET_LOOPBACK=y removes this error. After this
the CONFIG_NET_IPV6_MLD=n needed to be added in order to avoid
crashes when IPv6 MLD is done which is not needed for this test.
Removed also the whitelisting as that is not really needed and
we want to run these in as many platforms as possible.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Flags in alarm configuration structure will allow further extention
without breaking API. Initially, existing absolute flag was added
as the only flag.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
The special 'unittest' target has largely been supersesed by
native_posix, and converting this to a regular test will allow
us to see code coverage for the CRC functions in our coverage
reports.
Fixes: #16943
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Forced attempt to set the device address is unpredictable
and also should not be done during testing.
Signed-off-by: Johann Fischer <j.fischer@phytec.de>
We need to increase the stack sizes if user enables CONFIG_COVERAGE
option. You can test this by this command
sanitycheck --coverage -p qemu_x86 -T tests/net/udp \
-T tests/net/mgmt -T tests/net/mld
This is partial fix for issues described in #17323
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
If the socket descriptor is invalid (fd < 0), there is no
need to try to close it.
Coverity-CID: 198949
Fixes#16785
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
This is testing size_mul_overflow() in z_impl_k_msgq_alloc_init() so
make sure OVERFLOW_SIZE_MSG is large enough even on 64-bit targets.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
... because this test does use userspace, as seen in the source or
demonstrated by the failure of this command:
sanitycheck --extra-args=CONFIG_TEST_USERSPACE=n
See commit message of 4afcc0f8af for the long story.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
sizeof(value) returns the size of the pointer, not the pointed string.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
tests/bluetooth/gatt/src/main.c
Over time, this has been reduced to a few functions dealing solely
with floating-point support, referenced only from core/ia32/float.c.
Thus they are moved into that file and the header is eliminated.
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
The accounting data stored at the beginning of a memory block used by
malloc must push the returned memory address to a word boundary. This
is already the case on 32-bit systems, but not on 64-bit systems where
e.g. struct k_mem_block_id still has a size of 4.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Add support to STM LSM6DSO 6-axis IMU sensor driver.
This driver supports communication with device though both
I2C and SPI bus and both polling and drdy trigger mode.
This driver supports also the sensorhub mode with the possibility
to connect a maximum of two external devices, typically a
magnetometer and an environmental sensor, currently selected among
following devices: lis2mdl magnetometer, lps22hh or lps22hb
pressure and temperature sensors, HTS221 humidity sensor.
Signed-off-by: Armando Visconti <armando.visconti@st.com>
Add support to STM LPS22HH pressure and temperature sensor.
The driver support I2C and SPI bus communication and both
polling and drdy trigger mode.
Signed-off-by: Armando Visconti <armando.visconti@st.com>
This was dumping coverage before the test code even ran.
Ideally, this gets re-written to use ztest, but meanwhile
place a dummy main thread which sleeps forever, and dump
coverage once the test succeeds.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Adds coverage for the uncovered json_calc_encoded_len()
and covers a bunch more error cases.
This gets us up to 90.1% line coverage and 100% function
coverage.
Fixes: #16944
Partial fix for: #16011
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
The current CMSIS v2 implementation is clearly assuming that timeout
arguments being passed to e.g. osDelay() are in units of Zephyr ticks,
not milliseconds as specified by ARM or (inconsistently) assumed by
our test code.
Most tests work with the ~100 Hz default tick rate, but they tend to
fail on precision issues at higher tick rates. Force the CMSIS v2
applications to be 1000 Hz for now as a workaround, and detect the
mismatch as a build failure.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This test was written to assume that k_busy_wait() and CMSIS
osKernelSysTick() (which is just k_cycle_get_32()) were perfectly
synchronized. On nRF, they aren't (one is the 32 kHz RTC timer, the
other is a calibrated spin loop using the CPU frequency).
When ticks were being reported at 100 Hz granularity, there wasn't
enough precision to detect the mismatch. Now there is. Rework the
test to require that the clocks match to within 1%.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This test seems a little confused. It does a POSIX usleep() for 90ms,
then checks the time taken, and verifies that it was no less
than... 91ms!
On existing platforms, tick alignment makes sure that we always take a
little longer, so this passes. But on high tick rate configurations we
get it exactly right. And fail.
Adjust the calibration to allow (exactly) 90ms sleeps. Also fixed a
comment that described the wrong units.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This test was written to properly align its millisecond-measured wait
time and assumed that there would be no other overhead. In fact on
fast tick rate systems (or even ones where the alignment computation
doesn't provide the needed padding as "slop") that's not quite enough
time to complete the full test. There are cycles between the sleep
calls that need to be accounted for, and aren't.
Just give it one extra work item of time before failing. We aren't
testing work queue timing precision here, just evaluation semantics.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
"50" ticks is fine with 100 Hz timer precision but way too short to
survive the conversion to milliseconds on fast, non-decimal tick
rates. Make it half a second, which was the original intent.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This test was written to assume ~100 Hz ticks in ways that are
difficult to fix. It wants to sleep for periods on the order of the
TICKLESS_IDLE_THRESH kconfig, which is extremely small on high tick
rate systems and (on nRF in particular) does not have a cleanly
divisible representation in milliseconds.
Fixing precision issues by cranking the idle threshold up on a
per-system basis seems like an abuse, as that is what we want to be
testing in the first place. Just let the test run at the tick rate it
has always expected.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The logic about minimal sleep sizes due to "tick" aliasing was
correct, but drivers also have similar behavior with "cycle" aliasing
too. When cycles are 3-4 orders of magnitude faster than ticks, it's
undetectable noise. But now on nRF they're exactly the same and we
need to correct for that, essentially doubling the number of ticks a
usleep() might wait for.
The logic here was simply too strict, basically. Fast tick rates
can't guarantee what the test promised.
Note that this relaxes the test bounds on the other side of the
equation too: it's no longer an error to usleep() for only one tick
(i.e. an improved sleep/timeout implementation no longer gets detected
as a test failure).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The sleep test was checking that the sleep took no longer than "2
ticks" longer than requested. But "2 ticks" for fast tick rate
configurations can be "zero ms", and for aliasing reasons it's always
possible to delay for 1 unit more than requested (becuase you can
cross a millisecond/tick/whatever boundary in your own code on either
side of the sleep). So that "slop" value needs to be no less than
1ms.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The test for the k_uptime_delta utilities was calling it in a loop and
waiting for the uptime to advance. But the code was specifically
wanting it to advance 5ms or more at one go, which clearly isn't going
to work for a tick rate above 200 Hz.
The weird thing is that the test knew this and even commented about
the limitation. Which seems silly: it's perfectly fine for the clock
to advance just a single millisecond. That's correct behavior too.
Let's test for that, and it will work everywhere.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
When ticks are sub-millisecond, the math produces minimum and maximum
values for the slice duration test that are equal. But because of
aliasing across tick boundaries, it's always possible (for any time
period, nothing specific to time slicing here) to measure one tick
more than an intended duration. So make sure there's always at least
a range of 1ms.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Tick rate is becoming a platform tunable in the tickless world. Some
apps were setting it due to requirements of drivers or subsystems (or
sometimes for reasons that don't make much sense), but the dependency
goes the other way around now: board/soc/arch level code is
responsible for setting tick rates that work with their devices.
A few tests still use hard-configured tick rates, as they have
baked-in assumptions (like e.g. "a tick will be longer than a
millisecond") that need to be addressed first.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This code was clearly written to assume that the timeout argument to
k_mem_pool_alloc() was in ticks and not ms. Adjust to what appears to
have been the intent. It was working as intended (i.e waiting one or
1/10th of a second) only on systems where the default tick rate was
100 Hz.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
If maxsize is smaller than _MPOOL_MINBLK, then Z_MPOOL_LVLS() will be 0.
That means the loop in z_sys_mem_pool_base_init() that initializes the
block free list for the nonexistent level 0 will corrupt whatever memory
at the location the zero-sized struct sys_mem_pool_lvl array was
located. And the corruption happens to be done with a perfectly legit
memory pool block address which makes for really nasty bugs to solve.
This is more likely on 64-bit systems due to _MPOOL_MINBLK being twice
the size of 32-bit systems.
Let's prevent that with a build-time assertion on maxsize when defining
a memory pool, and adjust the affected test accordingly.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
This header is currently IA32-specific, so move it into the subarch
directory and update references to it.
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
Making room for the Intel64 subarch in this tree. This header is
32-bit specific and so it's relocated, and references rewritten
to find it in its new location.
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
This file is 32-bit specific, so it is moved into the ia32/ directory
and references to it are updated accordingly.
Also, SP_ARG* definitions are no longer used, so they are removed.
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
