Port the implementation that does radio event abort due to
ISR latencies. The implementation measures if the ISR could
not meet the hard real time deadline and closes the event
early.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
Added interface to get Advertiser and Scanner instance
handle for use in Lower Link Layer module.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
The code in shell_history_put() adds padding to new entries so they
are pointer aligned. The whole buffer has to be so aligned too.
Signed-off-by: Nicolas Pitre <npitre@baylibre.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
The --jobs default was recently changed in commit 9f4f57eed3, update
its help message.
Add the hopefully last missing verbose("Spawning...") statement.
Fix comment updated in commit 095b82a301.
Replace two tags with whitespace.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
The current version is 32-bit specific, so move it to ia32/
and add a layer of indirection via an arch-level header file.
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
Refactoring 32- and 64-bit subarchitectures, so this file is moved
to ia32/ and a new "redirector" header file is introduced.
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
This data is subarchitecture-specific, so move it to ia32/
and add a layer of indirection at the architecture level.
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
Some of this is 32-bit specific, some applies to all subarchitectures.
A preliminary attempt is made to refactor and place 32-bit-specific
portions in ia32/kernel_arch_data.h.
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
This file merely declares external functions referenced only
by ia32/cache.c, so the declarations are inlined instead.
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
This file was used to generate offsets for host tools that are no
longer in use, so it's removed and the offsets are no longer generated.
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
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>
sanitycheck is opening an insane number of file descriptors
simultaneously as it opens up communication pipes with
every test that supports emulation, on every emulated
board target.
Increase the resource limit on open files until this code
can be properly refactored.
Workaround for: #17239
Signed-off-by: Andrew Boie <andrew.p.boie@intel.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>
OpenThread did not verify if the interface provided in the net_mgmt
handler is actually an OpenThread interface. In result, when multiple
network interfaces were used, different interfaces were processed by the
OpenThread handler, ending up in a crash.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
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>
These empty functions needed to be declared static inline
or we get build errors if the header is included by more
than one C file.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Make sure the IPv4 and IPv6 socket addresses are initialized before
copying them. This avoids uninitialized memory access.
Coverity-CID: 199436
Fixes#17202
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
The network interface events should be in L2 layer so there
is no one that would emit L1 events so no need for it.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Ensure that xcc is at parity with gcc and clang by inferring missing
definitions based on those that it already provides.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
The zephyr_stdint.h file enforces Zephyr specific policies on the
compilation environment. Let's give compilers a chance to provide
definitions of their own via TOOLCHAIN_C_FLAGS prior the inclusion
of zephyr_stdint.h.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Commit f57ba2d30c ("cmake: toolchain_cc_imacros: don't use space
separated arguments") moved toolchain_cc_imacros() to using the long
argument format in order to avoid spaces that CMake uses to delimitate
and deduplicate arguments.
It seems that xcc doesn't support the --imacros=foo form. However
it does support the short "combined" -imacrosfoo form (without space).
So let's use that instead and document the caviat.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
If user has set CONFIG_NET_CONTEXT_TIMESTAMP then enable
network packet throughput collection for UDP packets.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
This can be used to activate the network packet statistics
collection. Note that we do not have resources to calculate
each network packet transit times but we collect average times
instead.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Finalize the CONFIG_NET_CONTEXT_TIMESTAMP support that was started
earlier but never properly finished. We collect network statistics for
TX packet network stack throughput time from when the net_context_send
is called and when the net_pkt was sent out successfully by the network
device driver.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.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 --gcov-tool argument now has a reasonable default
if the Zephyr SDK is in use.
- --coverage-platform, if unspecified, defaults to what
was passed to --platform
- --coverage implies --enable-slow, so that tests with
the 'slow' tag are built and run.
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 scheduler API has always allowed setting a zero slice size as a
way to disable timeslicing. But the workaround introduced for
CONFIG_SWAP_NONATOMIC forgot that convention, and was calling
reset_time_slice() with that zero value (i.e. requesting an immediate
interrupt) in circumstances where z_swap() had been interrupted
nonatomically.
In practice, this never happened. And if it did, it was a single
spurious no-op interrupt that no one cared about. Until it did,
anyway...
Now that ticks on nRF devices are at full 32 kHz speed, we can get
into a situation where the rapidly triggering timeslice interrupts are
interrupting z_swap() calls, and the process feeds back on itself and
becomes self-sustaining.
Put that test into the time slice code itself to prevent this kind of
mistake in the future.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The default tick rate is now 10 kHz, but that driver was demanding
that it be exactly 1 kHz instead of at least that rate. I checked the
source, and the driver isn't actually extracting "ticks" from the
kernel illegally, it just needs fine-grained timers that work with the
existing millisecond API. Let it build, this is fine.
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>