Unit test project for bt_id_add().
This part of subsys/bluetooth/host/id.c unit testing.
Signed-off-by: Ahmed Moheb <ahmed.moheb@nordicsemi.no>
# Conflicts:
# tests/bluetooth/host/id/CMakeLists.txt
Unit test project for bt_id_adv_random_addr_check().
This part of subsys/bluetooth/host/id.c unit testing.
Signed-off-by: Ahmed Moheb <ahmed.moheb@nordicsemi.no>
Unit test project for bt_id_scan_random_addr_check().
This part of subsys/bluetooth/host/id.c unit testing.
Signed-off-by: Ahmed Moheb <ahmed.moheb@nordicsemi.no>
# Conflicts:
# tests/bluetooth/host/id/CMakeLists.txt
Unit test project for bt_id_set_adv_random_addr().
This part of subsys/bluetooth/host/id.c unit testing.
Signed-off-by: Ahmed Moheb <ahmed.moheb@nordicsemi.no>
Unit test project for bt_id_set_adv_private_addr().
This part of subsys/bluetooth/host/id.c unit testing.
Signed-off-by: Ahmed Moheb <ahmed.moheb@nordicsemi.no>
# Conflicts:
# tests/bluetooth/host/id/mocks/adv.c
# tests/bluetooth/host/id/mocks/adv.h
Unit test project for bt_id_set_private_addr().
This part of subsys/bluetooth/host/id.c unit testing.
Signed-off-by: Ahmed Moheb <ahmed.moheb@nordicsemi.no>
# Conflicts:
# tests/bluetooth/host/id/CMakeLists.txt
Unit test project for bt_lookup_id_addr().
This part of subsys/bluetooth/host/id.c unit testing.
Signed-off-by: Ahmed Moheb <ahmed.moheb@nordicsemi.no>
# Conflicts:
# tests/bluetooth/host/id/CMakeLists.txt
Unit test project for bt_setup_random_id_addr().
This part of subsys/bluetooth/host/id.c unit testing.
Signed-off-by: Ahmed Moheb <ahmed.moheb@nordicsemi.no>
Unit test project for bt_setup_public_id_addr().
This part of subsys/bluetooth/host/id.c unit testing.
Signed-off-by: Ahmed Moheb <ahmed.moheb@nordicsemi.no>
Unit test project for bt_keys_update_usage().
This part of subsys/bluetooth/host/keys.c unit testing.
Signed-off-by: Ahmed Moheb <ahmed.moheb@nordicsemi.no>
This sets the RNG node that will be used by the Nordic
devices which support TF-M (nRF5340/nRF9160) to use the
defined scheme with psa_generate_random.
Signed-off-by: Georgios Vasilakis <georgios.vasilakis@nordicsemi.no>
Zephyr's default settings usually enable the only minimum of peripherals,
and rpi_pico already has `i2c0` enabled.
Remove the `i2c1` node configuration.
Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@fujitsu.com>
Fixes an issue with the documentation whereby the wrong hash/sha
sections were described, also adds a link to upstream MCUboot
documentation for further information.
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
A follow up to commit 1d7a077e11 - apparently the PPP interface should
not be brought entirely down internally, as this can break further
communication with the host. Because of that, reintroduce functionality
that used to be covered by net_if_carrier_down() (which basically
skips the L2 enable(false) call), but limited to PPP scope only.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Fixes#53786
The variable slot_plus_us is assumed to be a number in us unit.
To assign the maximum possible CTE length to this variable,
BT_HCI_LE_CTE_LEN_MAX has been used while this parameter is defined
in a 8us units (it's 0x14=20 that corresponds to 160us).
To convert this number to us, it's needed to be multiplied by 8.
Signed-off-by: Saleh Mehdikhani <saleh.mehdikhani@unikie.com>
This is important for applications which are chain-loaded by a broken
bootloader which doesn't reset the peripheral before handing over control.
Signed-off-by: Armin Brauns <armin.brauns@embedded-solutions.at>
The documentation for the fixed-partitions binding is missing critical
information and is vague in other important respects. This is an
important binding that deserves to be crystal clear. Fix it.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
The build system currently links the toolchain-provided C++ standard
library even when the C++ support (`CONFIG_CPP`) is not enabled.
This commit updates the build system to link the toolchain-provided C++
standard library when the C++ support is enabled and a C++ library
implementation other than the Zephyr minimal C++ library is selected.
Signed-off-by: Stephanos Ioannidis <stephanos.ioannidis@nordicsemi.no>
The bt_has_register_param's preset_sync_support and independent_presets
make sense only if CONFIG_BT_HAS_PRESET_COUNT is non-zero meaning the
CONFIG_BT_HAS_PRESET_SUPPORT is enabled.
Otherwise, those parameters shall be skipped.
Signed-off-by: Mariusz Skamra <mariusz.skamra@codecoup.pl>
Add command to perform the Periodic Advertising Set
Info Transfer procedure, which transfers information
about a periodic advertising set to a connected device.
In essence this is just PAST but from the advertiser
instead of a 3rd device.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
In ascs.c we had a case where we assigned stream->conn
without taking the ref.
In bt_audio_stream_attach we did not check if stream->conn
was NULL before taking a reference, causing multiple calls
to ase_config to take multiple references.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The same board can be used to test multiple regulators, so let's
explicitely set overlays and fixture name.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Regulator voltage needs to be within allowed range before enabling. It
could happen that regulator default voltage is out of the allowed range,
so the regulator could be enabled at boot time producing a not-allowed
voltage.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The existing linear_range API did not allow values or windows outside of
the linear range (returned -EINVAL). With this change values are allowed
outside of the range, being adjusted to the edge values (min/max)
instead. In the case of windows, it is allowed to have partial
intersection. In both cases, the API assigns a valid index (nearest) and
returns -ERANGE. This change is useful because the main client of the
linear range API, regulators, needs such behavior. For example, If an
application specifies a voltage range from 1.0V to 1.5V and the
regulator supports from 1.2V to 2.7V, the regulator can configure a
voltage that satisfies the condition: 1.2V. With the current API, the
input would be refused because 1.0V lies outside of the 1.2V-2.7V range.
Also, for constant ranges, the minimum index is returned.
Tests have been updated/extended accordingly.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Update the Readme file of the large mtu sample because the orginal PR
(https://github.com/zephyrproject-rtos/zephyr/pull/53593) has been merged
before the last comment could be addressed.
Signed-off-by: Théo Battrel <theo.battrel@nordicsemi.no>
The purpose of this commit is to facilitate future improvements to the
LPN and friendship feature. By being able to identify friendship related
messages on the advertising layer, it will be possible to treat these in
a specific manner so that message exchange between LPN and friend
devices can be conducted in a more power efficient manner.
This commit adds the following:
- A separate tag for friendship related messages
- A optional separate advertising set for friend related messages
Signed-off-by: Anders Storrø <anders.storro@nordicsemi.no>
Adds Kconfig option to enable tuning the Friend receive delay window.
Friend poll events can be made more efficient by compensating for the
time the non-ideal advertising latency otherwise would add to the receive
delay.
Signed-off-by: Anders Storrø <anders.storro@nordicsemi.no>
Add nrf5340_audio_dk_nrf5340_cpunet to the platform_allow
as having it only in integration_platforms causes issues
with the CI system.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
In order to clean up clock related code, replace static build time
clock configuration code by a runtime check.
Since I'm not able to guarantee this check will provide a correct
verdict in 100% of the cases (I'm thinking to ULPI or exotic configurations
like F7 OTG-HS), add a config option to disable it if needed.
It also doesn't apply on F1/F3 series. Keep the build time check for now.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
This change doesn't consider STM32F1 series.
There are 5 categories of STM32 regarding USB domain clock:
A] USB domain clocks directly driven by CK48 clocks
B] USB domain clocks which can select either CK48 or an alternative clock
C] USB domain clocks which can select between MSI or PLL
D] USB domain clocks relying statically on a PLL output
E] USB domain clocks which can be set on 2 different PLL ouputs
For case A], there is nothing to be done. Clk48 was already configured
in a previous change (51c7643295b02ba26ddcd0fd915484114db7101c).
For case B] and C] USB domain clocks will need to be configured in
each board.
For case D] and E] relying on existing dts configuration. Though
there is no easy build time chekc that can be done.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
STM32F7 allow to run at significantly higher speed that the one configured
on these boards.
Configure clocks to make benefit of full potential.
Additionally, configure PLL_Q output to provide USB compatible 48MHz freq.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
For boards configuring USB device, enable or configure matching domain
clock when not done already.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Describe USB default domain clock on all USB devices.
When available select HSI48.
On some series, a default clock my be set by default at start up.
On those series, in order to be able to compute USB clock at runtime,
clock_control driver needs to be aware of configuration and then this
default config has to be described explicitly too.
Default clocks are not enabled though. It is up to board configuration
to provide correct clock configuration (and we should not enabled by
default clocks that would not be required by board configuration).
Note: This change doesn't consider STM32F1/F3 devices, which
have a specific USB clock configuration.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
