diff --git a/mpsl/Architecture_With_RTOS.svg b/mpsl/Architecture_With_RTOS.svg
new file mode 100644
index 0000000000..a2f5b195d1
--- /dev/null
+++ b/mpsl/Architecture_With_RTOS.svg
@@ -0,0 +1,256 @@
+
+
+
+
diff --git a/mpsl/Architecture_With_RTOS.vsdx b/mpsl/Architecture_With_RTOS.vsdx
new file mode 100644
index 0000000000..24eadd2221
Binary files /dev/null and b/mpsl/Architecture_With_RTOS.vsdx differ
diff --git a/mpsl/Architecture_Without_RTOS.svg b/mpsl/Architecture_Without_RTOS.svg
new file mode 100644
index 0000000000..1f79bcf999
--- /dev/null
+++ b/mpsl/Architecture_Without_RTOS.svg
@@ -0,0 +1,145 @@
+
+
+
+
diff --git a/mpsl/Architecture_Without_RTOS.vsdx b/mpsl/Architecture_Without_RTOS.vsdx
new file mode 100644
index 0000000000..e67d3c0b13
Binary files /dev/null and b/mpsl/Architecture_Without_RTOS.vsdx differ
diff --git a/mpsl/CHANGELOG.rst b/mpsl/CHANGELOG.rst
index 69112a540b..5d129fb864 100644
--- a/mpsl/CHANGELOG.rst
+++ b/mpsl/CHANGELOG.rst
@@ -7,34 +7,9 @@ Changelog
:local:
:depth: 2
-Main Branch
+Main branch
***********
-
-Changes
-=======
-
-* The MPSL radio notification API has been removed. (DRGN-20447)
-
-nRF Connect SDK v2.5.0
-**********************
-
-All the notable changes included in the |NCS| v2.5.0 release are documented in this section.
-
-Changes
-=======
-
-* FEM-related firmware is now built and deployed into separate libraries, one for each FEM implementation (such as ``simple_gpio``).
-* The :c:func:`mpsl_calibration_timer_handle` function must now be called when calibrating.
-
-Added
-=====
-* Added :c:func:`mpsl_tx_power_dbm_to_radio_register_convert` to convert supported power in dBm to a register code for RADIO. (KRKNWK-17367)
-* Added :c:func:`mpsl_clock_task_trigger_on_rtc_start_set` to trigger a PPI/DPPI task when the RTC starts. (DRGN-20396)
-
-nRF Connect SDK v2.4.0
-**********************
-
-All the notable changes included in the |NCS| v2.4.0 release are documented in this section.
+All the notable changes included in the main branch are documented in this section.
Changes
=======
diff --git a/mpsl/FEM_sequence_nRF21540.svg b/mpsl/FEM_sequence_nRF21540.svg
new file mode 100644
index 0000000000..04fc8d3368
--- /dev/null
+++ b/mpsl/FEM_sequence_nRF21540.svg
@@ -0,0 +1,297 @@
+
+
+
+
diff --git a/mpsl/FEM_sequence_nRF21540.vsdx b/mpsl/FEM_sequence_nRF21540.vsdx
new file mode 100644
index 0000000000..ec500d088c
Binary files /dev/null and b/mpsl/FEM_sequence_nRF21540.vsdx differ
diff --git a/mpsl/FEM_sequence_simple.svg b/mpsl/FEM_sequence_simple.svg
new file mode 100644
index 0000000000..84d7cb808d
--- /dev/null
+++ b/mpsl/FEM_sequence_simple.svg
@@ -0,0 +1,229 @@
+
+
+
+
diff --git a/mpsl/FEM_sequence_simple.vsdx b/mpsl/FEM_sequence_simple.vsdx
new file mode 100644
index 0000000000..1b7fa1cff4
Binary files /dev/null and b/mpsl/FEM_sequence_simple.vsdx differ
diff --git a/mpsl/FEM_timing_nRF21540.svg b/mpsl/FEM_timing_nRF21540.svg
new file mode 100644
index 0000000000..cb90564fd7
--- /dev/null
+++ b/mpsl/FEM_timing_nRF21540.svg
@@ -0,0 +1,390 @@
+
+
+
+
diff --git a/mpsl/FEM_timing_nRF21540.vsdx b/mpsl/FEM_timing_nRF21540.vsdx
new file mode 100644
index 0000000000..21fb457082
Binary files /dev/null and b/mpsl/FEM_timing_nRF21540.vsdx differ
diff --git a/mpsl/FEM_timing_simple.svg b/mpsl/FEM_timing_simple.svg
new file mode 100644
index 0000000000..0316e24ed9
--- /dev/null
+++ b/mpsl/FEM_timing_simple.svg
@@ -0,0 +1,319 @@
+
+
+
+
diff --git a/mpsl/FEM_timing_simple.vsdx b/mpsl/FEM_timing_simple.vsdx
new file mode 100644
index 0000000000..87678acd96
Binary files /dev/null and b/mpsl/FEM_timing_simple.vsdx differ
diff --git a/mpsl/README.rst b/mpsl/README.rst
index 1ad3b9fe3d..07d4ef8114 100644
--- a/mpsl/README.rst
+++ b/mpsl/README.rst
@@ -3,20 +3,23 @@
Multiprotocol Service Layer
===========================
-The Multiprotocol Service Layer (MPSL) is a set of libraries that provide common services for single and multiprotocol implementations.
+The Multiprotocol Service Layer (MPSL) is a library of common services for single and multiprotocol implementations.
-The libraries are available as soft-float, softfp-float, and hard-float builds for the nRF52 Series and as a soft-float build for the nRF53 Series.
+The library is available as soft-float, softfp-float, and hard-float builds for the nRF52 Series and as soft-float build for the nRF53 Series.
-These libraries provide the following key features:
+This library provides the following key features:
* Timeslot.
It allows the application to schedule its own events concurrently with other protocols.
+* Radio notifications.
+ It provides a configurable interrupt, usable before and/or after radio activity.
* TX Power control.
It provides an API for setting the maximum TX power per channel.
* Clock control.
It provides an API for configuring and controlling the low and high-frequency clock.
* FEM.
It provides an API for controlling external Front-End Modules.
+ It supports only the nRF52 Series.
* SoC Temperature.
It provides an API for obtaining the temperature measured on the SoC.
* IEEE 802.15.4 External Radio Coexistence.
@@ -33,6 +36,7 @@ To enable MPSL in |NCS| applications, use the :kconfig:option:`CONFIG_MPSL` Kcon
doc/mpsl
doc/clock
doc/timeslot
+ doc/radio_notification
doc/tx_power_control
doc/fem
doc/cx
diff --git a/mpsl/api.rst b/mpsl/api.rst
new file mode 100644
index 0000000000..0dcfc9ff5a
--- /dev/null
+++ b/mpsl/api.rst
@@ -0,0 +1,141 @@
+.. _mpsl_api:
+
+API documentation
+#################
+
+.. contents::
+ :local:
+ :depth: 2
+
+Multiprotocol Service Layer interface
+*************************************
+
+.. doxygengroup:: mpsl
+ :project: nrfxlib
+ :members:
+
+.. _mpsl_api_clk:
+
+MPSL Clock
+**********
+
+.. doxygengroup:: mpsl_clock
+ :project: nrfxlib
+ :members:
+
+.. _mpsl_api_timeslot:
+
+MPSL Timeslot
+*************
+
+.. doxygengroup:: mpsl_timeslot
+ :project: nrfxlib
+ :members:
+
+.. _mpsl_api_rn:
+
+MPSL Radio Notification
+***********************
+
+.. doxygengroup:: mpsl_radio_notification
+ :project: nrfxlib
+ :members:
+
+.. _mpsl_api_txp:
+
+MPSL TX Power
+*************
+
+.. doxygengroup:: mpsl_tx_power
+ :project: nrfxlib
+ :members:
+
+.. _mpsl_api_fem:
+
+MPSL FEM
+********
+
+.. doxygengroup:: mpsl_fem
+ :project: nrfxlib
+ :members:
+
+.. _mpsl_api_fem_common:
+
+MPSL FEM common configuration
+*****************************
+
+.. doxygengroup:: mpsl_fem_config_common
+ :project: nrfxlib
+ :members:
+
+.. _mpsl_api_fem_21540_config:
+
+MPSL FEM common nRF21540 configuration
+**************************************
+
+.. doxygengroup:: mpsl_fem_nrf21540_common
+ :project: nrfxlib
+ :members:
+
+.. _mpsl_api_fem_21540_gpio:
+
+MPSL FEM nRF21540 GPIO
+**********************
+
+.. doxygengroup:: mpsl_fem_nrf21540_gpio
+ :project: nrfxlib
+ :members:
+
+.. _mpsl_api_fem_21540_gpiospi:
+
+MPSL FEM nRF21540 GPIO/SPI
+**************************
+
+.. doxygengroup:: mpsl_fem_nrf21540_gpio_spi
+ :project: nrfxlib
+ :members:
+
+.. _mpsl_api_fem_simple:
+
+MPSL FEM Simple GPIO
+********************
+
+.. doxygengroup:: mpsl_fem_simple_gpio
+ :project: nrfxlib
+ :members:
+
+.. _mpsl_api_fem_power:
+
+MPSL FEM power model
+********************
+
+.. doxygengroup:: mpsl_fem_power_model
+ :project: nrfxlib
+ :members:
+
+.. _mpsl_api_sr_cx:
+
+MPSL CX (Coexistence)
+*********************
+
+.. doxygengroup:: mpsl_cx
+ :project: nrfxlib
+ :members:
+
+.. _mpsl_api_temp:
+
+MPSL Temp
+*********
+
+.. doxygengroup:: mpsl_temp
+ :project: nrfxlib
+ :members:
+
+.. _mpsl_api_dppi:
+
+MPSL DPPI Protocol
+******************
+
+.. doxygengroup:: mpsl_dppi_protocol_api
+ :project: nrfxlib
+ :members:
diff --git a/mpsl/bluetooth_coex.rst b/mpsl/bluetooth_coex.rst
new file mode 100644
index 0000000000..fdaa2a52af
--- /dev/null
+++ b/mpsl/bluetooth_coex.rst
@@ -0,0 +1,73 @@
+.. _bluetooth_coex:
+
+Bluetooth-Only External Radio Coexistence
+#########################################
+
+.. contents::
+ :local:
+ :depth: 2
+
+The Bluetooth® coexistence feature can use the 1-wire LTE coexistence protocol.
+
+**Application Programming Interface:**
+
+You can find the details of the API in the :file:`nrfxlib/mpsl/include/mpsl_coex.h` file.
+
+
+.. NOTE::
+ This implementation is only supported on nRF52 devices.
+
+.. _mpsl_bluetooth_coex_1wire:
+
+1-Wire coexistence protocol
+---------------------------
+
+
+Interface
+**********
+
+The 1-wire protocol lets Bluetooth LE nRF chips coexist alongside an LTE device on a separate chip.
+It was specifically designed for the `coex interface of nRF9160`_.
+
+
+Hardware resources
+==================
+
+The 1-wire Coexistence protocol requires the following peripherals:
+
+.. table:: 1-wire coexistence protocol HW resources
+
+ =============== ===== ========================================================
+ Peripheral Count Description
+ =============== ===== ========================================================
+ GPIO pins 1 Pin selected for the 1-wire interface BLE_GRANT
+ GPIOTE channels 1 One GPIOTE channel for registering BLE_GRANT pin changes
+ PPI channels 1 Connecting the BLE_GRANT to Radio DISABLE task
+ =============== ===== ========================================================
+
+Interface signals
+=================
+
+The 1-wire interface is a single unidirectional input controlled by the LTE device:
+
+.. table:: 1-wire LTE coexistence protocol pin
+
+ ========= ========= =====================================
+ Pin Direction Description
+ ========= ========= =====================================
+ BLE_GRANT In Used by the LTE to grant radio access
+ ========= ========= =====================================
+
+The interface consists of a BLE_GRANT signal mapped to the GPIO pin by the application's interface configuration.
+The signal's active level (high or low) is programmable.
+Whenever the nRF SoC requires the use of the radio for any RF activity, it needs to test that the BLE_GRANT pin level is valid for Bluetooth LE radio use (such as 0 for the nRF9160).
+
+The figure below illustrates these timings with regard to the LTE and BLE_GRANT signal.
+
+.. figure:: pic/mpsl_coex_1wire_timing_grant.svg
+
+ 1-wire LTE Coexistence protocol timing
+
+When the BLE_GRANT is revoked (for example the pin de-asserts for the nRF9160), the Bluetooth LE radio immediately gets disabled with a maximum delay of 7us.
+
+When the coexistence interface is disabled, the associated GPIO pins are set to a high impedance state.
diff --git a/mpsl/clock.rst b/mpsl/clock.rst
new file mode 100644
index 0000000000..45369bccf9
--- /dev/null
+++ b/mpsl/clock.rst
@@ -0,0 +1,56 @@
+.. _mpsl_clock:
+
+MPSL Clock
+##########
+
+.. contents::
+ :local:
+ :depth: 2
+
+The MPSL clock module provides access to the low-frequency clock (LFCLK) configuration and allows the application to request the crystal oscillator source of the high-frequency clock (HFCLK).
+
+See the following `Low-frequency clock (LFCLK)`_ and `High-frequency clock (HFCLK)`_ sections for a description of the design.
+
+Low-frequency clock (LFCLK)
+***************************
+
+MPSL can use one of the following available low-frequency clock (LFCLK) sources:
+
+* 32.768 kHz internal RC oscillator (LFRC)
+* 32.768 kHz crystal oscillator (LFXO)
+
+When MPSL is enabled, the application must provide the selected LFCLK source, calibration configurations, and clock accuracy.
+The selected accuracy is meant to be forwarded only to the protocol stacks.
+
+The MPSL clock module configures the LFCLK source and keeps it calibrated when the RC oscillator is the selected clock source.
+
+Variations in temperature affect the RC oscillator frequency.
+As such, it requires additional calibration for temperature changes of more than 0.5°C.
+
+To ensure the required accuracy, the MPSL clock module must calibrate periodically the RC oscillator using the HFCLK crystal oscillator as a reference.
+See the relevant SoC product specification for more information.
+As the MPSL clock module runs the calibration automatically, the application must specify how often the clock module takes measurements to detect temperature changes.
+
+.. note::
+ You should consider how frequently significant temperature changes are expected to occur in the intended environment of the end product.
+ It is recommended to use a temperature polling interval of 4 seconds, and to force the clock calibration every second interval (``.rc_ctiv=16``, ``.rc_temp_ctiv=2``).
+
+High-frequency clock (HFCLK)
+****************************
+
+The high-frequency clock (HFCLK) controller supports the following HFCLK sources:
+
+* 64 MHz internal oscillator (HFINT)
+* 64 MHz crystal oscillator (HFXO)
+
+The HFXO must be running to use the ``RADIO`` peripheral.
+MPSL makes sure the HFXO is started in time for every scheduled ``RADIO`` activity.
+
+.. note::
+ For the correct operation of the ``RADIO`` peripheral, you must set the HFXO startup time to less than 1.5 ms.
+ As such, you must choose the external crystal oscillator and the other related components accordingly.
+ See the relevant SoC product specification for more information.
+
+The MPSL clock module API enables the application to safely request and release the HFXO while the protocol stacks are enabled.
+MPSL can continue to use the HFXO after it is released if it is requested by protocol stacks.
+HFXO is stopped when it is no longer needed.
diff --git a/mpsl/cx.rst b/mpsl/cx.rst
new file mode 100644
index 0000000000..de9a00cbd3
--- /dev/null
+++ b/mpsl/cx.rst
@@ -0,0 +1,55 @@
+.. _mpsl_cx:
+
+Short-Range Protocols External Radio Coexistence
+################################################
+
+.. contents::
+ :local:
+ :depth: 2
+
+The radio coexistence feature allows the application to interface with several types of packet traffic arbiters (PTAs).
+PTAs arbitrate the requested radio operations between all radios to avoid interference, providing better radio performance to devices using multiple interfering radios simultaneously, like a combination of IEEE 802.15.4, Bluetooth® Low Energy (LE), and Wi-Fi.
+The arbitration algorithm used can vary between PTAs.
+
+.. note::
+ The radio coexistence feature is not needed for the arbitration between |BLE| and IEEE 802.15.4 in dynamic multiprotocol applications, as the dynamic multiprotocol does not use PTA for the arbitration.
+
+Overview
+********
+
+The radio coexistence feature allows short-range protocol drivers (e.g. IEEE 802.15.4, Bluetooth LE) to communicate with the packet traffic arbiter (PTA) using :ref:`MPSL CX API `.
+The MPSL CX API is hardware-agnostic and separates the implementation of the protocol driver from an implementation specific to given PTA.
+To perform any radio operation, the protocol drivers must first request the appropriate access to the medium from the PTA.
+The request informs the PTA implementation about which radio operations it wants to perform at that moment or shortly after, and what is the priority of the operation.
+The radio operation can be executed only when the PTA grants it.
+When the PTA revokes access to the medium during an ongoing radio operation, the radio protocol must abort this operation immediately.
+When the radio operation is finished, the protocol driver must release the requested operation.
+
+The implementation of MPSL CX translates the request invoked by radio protocol to hardware signals compatible with the PTA available in the system.
+It also translates the hardware signals received from the PTA indicating which radio operations are allowed at that moment, and it passes this information to the radio protocol.
+
+.. note::
+ To learn more about the arbitration process during various transmission and reception modes for the IEEE 802.15.4 Radio Driver, see :ref:`Wi-Fi Coexistence module (PTA support) `
+
+Selecting CX Implementation
+***************************
+
+The :ref:`mpsl` itself does not provide any implementation of the CX interface.
+For details on the implementations present in the |NCS|, see :ref:`ug_radio_coex`.
+An application that needs to use CX must call :c:func:`mpsl_cx_interface_set()` during the system initialization.
+The initialization of any resource needed by the selected CX implementation is not in scope of :ref:`mpsl` and must also be done during the system initialization.
+
+.. note::
+ In the |NCS|, the selection of a CX implementation and its appropriate initialization is done automatically, using Kconfig and Device Tree configuration options.
+ Please refer to :ref:`ug_radio_coex`.
+
+Using CX API in a protocol driver
+*********************************
+
+To use the CX API in a protocol driver, you must follow the :ref:`MPSL CX API ` defined by :file:`nrfxlib/mpsl/include/protocol/mpsl_cx_protocol_api.h`.
+
+Implementing CX API
+*******************
+
+For details on the implementations of the MPSL CX API for certain PTAs already supported by the |NCS|, see :ref:`ug_radio_coex_mpsl_cx_based`.
+If your PTA is not supported yet, see :ref:`ug_radio_mpsl_cx_custom` for guidelines on how to add your own implementation.
diff --git a/mpsl/cx_3w_timing_param.svg b/mpsl/cx_3w_timing_param.svg
new file mode 100644
index 0000000000..e3d0bcc47e
--- /dev/null
+++ b/mpsl/cx_3w_timing_param.svg
@@ -0,0 +1,240 @@
+
+
+
+
diff --git a/mpsl/cx_3w_timing_param.vsdx b/mpsl/cx_3w_timing_param.vsdx
new file mode 100644
index 0000000000..10fb47d846
Binary files /dev/null and b/mpsl/cx_3w_timing_param.vsdx differ
diff --git a/mpsl/doc/api.rst b/mpsl/doc/api.rst
index 098564d7a5..0dcfc9ff5a 100644
--- a/mpsl/doc/api.rst
+++ b/mpsl/doc/api.rst
@@ -34,6 +34,15 @@ MPSL Timeslot
.. _mpsl_api_rn:
+MPSL Radio Notification
+***********************
+
+.. doxygengroup:: mpsl_radio_notification
+ :project: nrfxlib
+ :members:
+
+.. _mpsl_api_txp:
+
MPSL TX Power
*************
diff --git a/mpsl/doc/mpsl.rst b/mpsl/doc/mpsl.rst
index 397398eb8f..198e0bd99d 100644
--- a/mpsl/doc/mpsl.rst
+++ b/mpsl/doc/mpsl.rst
@@ -56,8 +56,6 @@ The following interrupts do not have real-time requirements:
When this interrupt is triggered, :c:func:`mpsl_low_priority_process` should be called as soon as possible (at least within a couple of ms).
The application should configure this interrupt priority lower than :c:macro:`MPSL_HIGH_IRQ_PRIORITY` level (namely, a higher numerical value).
The interrupt is enabled with :c:func:`mpsl_init` and disabled with :c:func:`mpsl_uninit` by MPSL.
- The interrupt is selected using the :kconfig:option:`CONFIG_MPSL_LOW_PRIO_IRQN` Kconfig option.
- This Kconfig option can be used to resolve conflicts with other software modules and should be left to the default value if possible.
Scheduling
==========
diff --git a/mpsl/doc/radio_notification.rst b/mpsl/doc/radio_notification.rst
new file mode 100644
index 0000000000..eca537a2fd
--- /dev/null
+++ b/mpsl/doc/radio_notification.rst
@@ -0,0 +1,38 @@
+.. _mpsl_radio_notification:
+
+Radio notifications
+###################
+
+The radio notification is a configurable feature that enables ACTIVE and INACTIVE (nACTIVE) signals from the MPSL to the application notifying it when timeslot events are active.
+The application can configure how much in advance the ACTIVE signal occurs.
+
+The radio notification signals are sent right before or at the end of an MPSL timeslot activity.
+The timeslot activity may be requested by the application or another user of MPSL.
+To ensure that the radio notification signals behave in a consistent way, the radio notification must always be configured when the MPSL is in an idle state with no active users.
+Therefore, it is recommended to configure the radio notification signals directly after the MPSL has been enabled.
+
+If it is enabled, the ACTIVE signal is sent before the timeslot events starts.
+Similarly, if the nACTIVE signal is enabled, it is sent at the end of the timeslot event.
+These signals can be used by the application developer to synchronize the application logic with the timeslot activity.
+For example, if the application is using the timeslot for radio activity, the ACTIVE signal can be used to switch off external devices to manage peak current drawn during periods when the radio is ON, or to trigger sensor data collection for transmission during the upcoming event.
+
+As both ACTIVE and nACTIVE use the same software interrupt, it is up to the application to manage them.
+If both ACTIVE and nACTIVE are configured ON by the application, there will always be an ACTIVE signal before an nACTIVE signal.
+
+When there is sufficient time between timeslot events, both the ACTIVE and nACTIVE notification signals will be present at each event.
+When there is not sufficient time between the events, the ACTIVE and nACTIVE notification signals will be skipped.
+There will still be an ACTIVE signal before the first event and an nACTIVE signal after the last event.
+
+The following image shows how the ACTIVE and nACTIVE notifications are raised for both when events are far enough apart.
+
+.. figure:: pic/radio_notification_two_events.svg
+ :alt: Notifications raised for ACTIVE and nACTIVE signals
+
+ Notifications raised for both ACTIVE and nACTIVE signals
+
+The following image shows how one pair of ACTIVE and nACTIVE notifications is suppressed when events are placed closer than the configured radio notification distance.
+
+.. figure:: pic/radio_notification_two_events_too_close.svg
+ :alt: Notifications skipped for ACTIVE and nACTIVE signals
+
+ Notifications skipped for ACTIVE and nACTIVE signals
diff --git a/mpsl/doc/timeslot.rst b/mpsl/doc/timeslot.rst
index 995eb0fd5e..4b73cdae5f 100644
--- a/mpsl/doc/timeslot.rst
+++ b/mpsl/doc/timeslot.rst
@@ -78,6 +78,11 @@ However, a timeslot that has already started cannot be interrupted or canceled.
If the timeslot is requested as earliest possible, it is scheduled at any available free time.
Therefore, there is less probability of collision with the earliest possible request.
+.. note::
+ Radio Notification signals behave the same way for timeslots requested through the timeslot interface as for other activities.
+ See :ref:`mpsl_radio_notification` for more information.
+ If radio notifications are enabled, timeslots will be notified.
+
High-frequency clock configuration
**********************************
The application can request the MPSL to guarantee that the HFCLK source is set to the external crystal and that it is ramped up and stable before the start of the timeslot.
diff --git a/mpsl/fem.rst b/mpsl/fem.rst
new file mode 100644
index 0000000000..2cf21861c8
--- /dev/null
+++ b/mpsl/fem.rst
@@ -0,0 +1,192 @@
+.. _mpsl_fem:
+
+Front-end module feature
+########################
+
+.. contents::
+ :local:
+ :depth: 2
+
+The front-end module feature allows the application to interface with several types of front-end modules (FEMs).
+This allows an increase of the transmitted power through a Power Amplifier (PA) or an increase of the sensitivity through a Low-Noise Amplifier (LNA).
+Any increase in power and sensitivity results in an increased communication range.
+The exact PA and LNA gains are dependent on the specific FEM used.
+
+Implementation
+**************
+
+Three FEM implementations are provided:
+
+nRF21540 GPIO
+ Compatible with the nRF21540 FEM and implements a 3-pin interface.
+ It can also optionally use the MODE pin for switching PA gain between two preconfigured values.
+
+nRF21540 GPIO SPI
+ Compatible with the nRF21540 FEM and implements a 3-pin interface to enable and disable the PA and LNA.
+ It also supports PA gain control using the SPI interface.
+
+Simple GPIO
+ A simplified version, made to be compatible with other front-end modules.
+ It implements a 2-pin interface.
+
+All currently supported implementations use the PA and LNA pins for controlling the FEM.
+Additionally, the nRF21540 implementations use the PDN pin for powering down the FEM internal circuits, to reduce energy consumption.
+
+TX power split
+**************
+
+When an application requests a given transmission power, it wants to achieve that power at the antenna.
+Usually, the application does not know all hardware components, such as RF front-end modules, on the radio signal path.
+To achieve a specific value of transmission power at the antenna, every FEM implementation provides a dedicated API that calculates the PA gain and SoC output power combination that results in the requested power at the antenna.
+It also calculates a private setting value applied to the FEM that is needed to achieve the calculated PA gain.
+The meaning of this private setting is specific to each FEM implementation.
+
+FEM implementations with multiple PA gains available (for example, nRF21540 with MODE pin support) choose which gain to use based on hardware limitations and the requested power value.
+Alternatively, an external model can be used to determine the gain.
+
+TX power split using models
+===========================
+
+You can achieve the TX power split using a model, to compensate, for example, for external conditions.
+The model can be either external (passed to MPSL) or built-in.
+
+A built-in model is currently provided only for the nRF21540 GPIO SPI FEM implementation and it is in an :ref:`experimental ` stage.
+The provided model allows for temperature, voltage, and frequency compensation.
+
+The model is passed to MPSL before the FEM configuration, and contains two callbacks: ``fetch`` and ``init``.
+After it completes the configuration, MPSL calls ``init`` to pass all the calibration and configuration data required by the specific FEM implementation to the model and to initialize the model.
+Each time a TX power split is needed, MPSL calls the ``fetch`` function and passes the frequency and the requested output power to the model.
+The model then decides how to split this power into components, and calculates both the private setting for the specific FEM implementation and the actually achieved output power.
+
+Configurable timings
+********************
+
+In both implementations, two timings can be configured:
+
+* ``LNA time gap``, the time between the LNA activation and the start of radio reception.
+* ``PA time gap``, the time between the PA activation and the start of radio transmission.
+
+For the nRF21540, two additional timings can also be configured:
+
+* ``TRX hold time``, the time interval for which the FEM is kept powered up after the PDN deactivation event occurs.
+* ``PDN settle time``, the time interval reserved for the FEM settle, before the PA or LNA activation.
+
+General usage
+*************
+
+The Power Amplifier and the Low-Noise Amplifier are responsible for, respectively, transmission and reception, and are configured and activated independently.
+The two functionalities cannot be configured and set to operate simultaneously, because they share some resources.
+As such, after operating with a Power Amplifier, the PA configuration must be cleared to be able to configure and use a Low-Noise Amplifier afterward, and vice versa.
+
+Both amplifiers are controlled through activation and deactivation events.
+Two types of events are supported:
+
+* A *timer event*.
+ It is the ``COMPARE`` event of a hardware timer and it can be used for both PA and LNA activation and deactivation.
+* A *generic event*.
+ It is any other event type and it can only be used for PA and LNA deactivation.
+
+To prepare a generic event, the application must provide the event register.
+To prepare a timer event, the application must provide the following:
+
+* The instance of the timer, which the protocol has to start by itself.
+* The *Compare Channels* mask, which tells the front-end module which Compare Channels of the provided Timer are free to use.
+* The Start time, at which the front-end module can start preparing the PA or LNA.
+* The End time, at which the front-end module must be ready for the RF procedure.
+
+Then, the module can configure the timer to activate or deactivate the FEM accordingly, taking also into account the FEM settle time.
+
+The following example activates the LNA for an RX operation, using the following parameters:
+
+* RX ramp-up time - 40 us
+* LNA settle time - 13 us
+* LNA deactivation event - ``rx_end``
+* LNA activation timer - ``TIMER0``
+
+The *RX ramp-up time* is the total time scheduled by the application.
+
+The steps needed to properly configure LNA in this example are the following:
+
+1. The application configures the LNA to be activated by the timer event, with the start time set to 0 us and the end time set to 40 us.
+#. The application provides the ``rx_end`` event as the LNA deactivation event.
+#. The FEM module reads the scheduled time and sets the ``TIMER0`` compare channel to 27 us, as a result of the RX ramp-up time (40 us) minus the LNA settle time (13 us).
+#. The application starts the RX operation.
+#. The application starts ``TIMER0``.
+
+The following picture illustrates the timings in this scenario:
+
+.. figure:: pic/FEM_timing_simple.svg
+ :alt: Timing of LNA pin for reception
+
+ Timing of the LNA pin for reception
+
+The following picture illustrates the calls between the application, the FEM module, and the hardware in this scenario:
+
+.. figure:: pic/FEM_sequence_simple.svg
+ :alt: Sequence diagram of LNA control for reception
+
+ Sequence diagram of LNA control for reception
+
+nRF21540 usage
+**************
+
+In the nRF21540 implementation, the PDN pin is used to power down the FEM internal circuits.
+The FEM can be powered down on an explicit application request.
+The FEM is powered back up automatically before PA or LNA are activated.
+
+The following example controls LNA and PDN during an RX operation, using the following parameters:
+
+* RX ramp-up time - 40 us
+* LNA settle time - 13 us
+* PDN settle time - 18 us
+* LNA deactivation event - ``rx_end``
+* PDN deactivation event - ``software``
+* LNA activation timer - ``TIMER1``
+
+The *RX ramp-up time* is the total time scheduled by the application.
+
+The steps needed to properly configure LNA and PDN in this example are the following:
+
+1. The application configures the power-down passing ``rx_end`` as the activation event.
+#. The application configures LNA to be activated by the timer event, with the start time set to 0 us and the end time set to 40 us.
+#. The application provides the ``rx_end`` event as the LNA deactivation event.
+#. The FEM module reads the scheduled time and sets ``TIMER1`` compare channels to 27 us (40-13) and 9 us (27-18).
+#. The application starts the RX operation.
+#. The application starts ``TIMER1``.
+
+The following picture illustrates the timing in this scenario:
+
+.. figure:: pic/FEM_timing_nRF21540.svg
+ :alt: Timing of the LNA and PDN pins for reception
+
+ Timing of the LNA and PDN pins for reception
+
+The following picture illustrates the calls between the application, the FEM module, and the hardware in this scenario:
+
+.. figure:: pic/FEM_sequence_nRF21540.svg
+ :alt: Sequence diagram of LNA and PDN control for reception
+
+ Sequence diagram of LNA and PDN control for reception
+
+PA gain control
+===============
+
+FEM implementations with multiple PA gains available can choose which gain to use.
+
+PA switched gain
+----------------
+
+Both nRF21540 implementations can control the FEM to select one of two available PA gains without the need to provide any model.
+To do so, the nRF21540 GPIO implementation uses MODE pin switching, while the nRF21540 GPIO SPI implementation performs the appropriate SPI transfers.
+
+To enable this feature for the nRF21540 GPIO implementation, the MODE pin must be enabled in the interface configuration that the application passes on initialization.
+To enable this feature for the nRF21540 GPIO SPI implementation, runtime gain control must be enabled in the interface configuration that the application passes on initialization.
+
+PA Gain control using a built-in compensation model
+---------------------------------------------------
+
+The nRF21540 GPIO SPI implementation can be used with the built-in model.
+Using this model allows for the compensation of external conditions like temperature, supply voltage and frequency.
+
+The model is currently in an :ref:`experimental ` stage.
+To use this model, MPSL's getter function must acquire the structure containing the model callbacks and then must pass it to MPSL just like all the other models.
diff --git a/mpsl/fem/CMakeLists.txt b/mpsl/fem/CMakeLists.txt
deleted file mode 100644
index c22475f6d0..0000000000
--- a/mpsl/fem/CMakeLists.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-# Copyright (c) 2023 Nordic Semiconductor
-#
-# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
-#
-
-function(mpsl_fem_append_lib fem_lib_name)
- nrfxlib_calculate_lib_path(LIB_DIR
- BASE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/${fem_lib_name}
- SOFT_FLOAT_FALLBACK
- )
-
- if(LIB_DIR)
- zephyr_include_directories(${fem_lib_name}/include)
- zephyr_link_libraries(${LIB_DIR}/libmpsl_fem_${fem_lib_name}.a)
- endif()
-endfunction()
-
-FILE(GLOB subdirlist RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} ${CMAKE_CURRENT_SOURCE_DIR}/*)
-
-# call mpsl_fem_append_lib for each subdirectory
-FOREACH(subdir ${subdirlist})
- IF(IS_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/${subdir})
- mpsl_fem_append_lib(${subdir})
- ENDIF()
-ENDFOREACH()
-
-zephyr_include_directories(include)
-zephyr_include_directories(include/protocol)
diff --git a/mpsl/fem/common/lib/cortex-m33+nodsp/soft-float/libmpsl_fem_common.a b/mpsl/fem/common/lib/cortex-m33+nodsp/soft-float/libmpsl_fem_common.a
deleted file mode 100644
index 2a6263f3ee..0000000000
Binary files a/mpsl/fem/common/lib/cortex-m33+nodsp/soft-float/libmpsl_fem_common.a and /dev/null differ
diff --git a/mpsl/fem/common/lib/cortex-m33+nodsp/soft-float/manifest.yaml b/mpsl/fem/common/lib/cortex-m33+nodsp/soft-float/manifest.yaml
deleted file mode 100644
index 028bc3e1a4..0000000000
--- a/mpsl/fem/common/lib/cortex-m33+nodsp/soft-float/manifest.yaml
+++ /dev/null
@@ -1,3 +0,0 @@
-description: MPSL Front-End Module common
-git_revision: 675065d227c03dc6af925a49aac8c224187e6339
-timestamp: '2023-12-22T08:07:58Z'
diff --git a/mpsl/fem/common/lib/cortex-m4/hard-float/libmpsl_fem_common.a b/mpsl/fem/common/lib/cortex-m4/hard-float/libmpsl_fem_common.a
deleted file mode 100644
index 6b4dc99403..0000000000
Binary files a/mpsl/fem/common/lib/cortex-m4/hard-float/libmpsl_fem_common.a and /dev/null differ
diff --git a/mpsl/fem/common/lib/cortex-m4/hard-float/manifest.yaml b/mpsl/fem/common/lib/cortex-m4/hard-float/manifest.yaml
deleted file mode 100644
index 65ab628646..0000000000
--- a/mpsl/fem/common/lib/cortex-m4/hard-float/manifest.yaml
+++ /dev/null
@@ -1,3 +0,0 @@
-description: MPSL Front-End Module common
-git_revision: 675065d227c03dc6af925a49aac8c224187e6339
-timestamp: '2023-12-22T08:02:30Z'
diff --git a/mpsl/fem/common/lib/cortex-m4/soft-float/libmpsl_fem_common.a b/mpsl/fem/common/lib/cortex-m4/soft-float/libmpsl_fem_common.a
deleted file mode 100644
index 9264c2423d..0000000000
Binary files a/mpsl/fem/common/lib/cortex-m4/soft-float/libmpsl_fem_common.a and /dev/null differ
diff --git a/mpsl/fem/common/lib/cortex-m4/soft-float/manifest.yaml b/mpsl/fem/common/lib/cortex-m4/soft-float/manifest.yaml
deleted file mode 100644
index 65ab628646..0000000000
--- a/mpsl/fem/common/lib/cortex-m4/soft-float/manifest.yaml
+++ /dev/null
@@ -1,3 +0,0 @@
-description: MPSL Front-End Module common
-git_revision: 675065d227c03dc6af925a49aac8c224187e6339
-timestamp: '2023-12-22T08:02:30Z'
diff --git a/mpsl/fem/common/lib/cortex-m4/softfp-float/libmpsl_fem_common.a b/mpsl/fem/common/lib/cortex-m4/softfp-float/libmpsl_fem_common.a
deleted file mode 100644
index a5984fafe8..0000000000
Binary files a/mpsl/fem/common/lib/cortex-m4/softfp-float/libmpsl_fem_common.a and /dev/null differ
diff --git a/mpsl/fem/common/lib/cortex-m4/softfp-float/manifest.yaml b/mpsl/fem/common/lib/cortex-m4/softfp-float/manifest.yaml
deleted file mode 100644
index 65ab628646..0000000000
--- a/mpsl/fem/common/lib/cortex-m4/softfp-float/manifest.yaml
+++ /dev/null
@@ -1,3 +0,0 @@
-description: MPSL Front-End Module common
-git_revision: 675065d227c03dc6af925a49aac8c224187e6339
-timestamp: '2023-12-22T08:02:30Z'
diff --git a/mpsl/fem/nrf21540_gpio/lib/cortex-m33+nodsp/soft-float/libmpsl_fem_nrf21540_gpio.a b/mpsl/fem/nrf21540_gpio/lib/cortex-m33+nodsp/soft-float/libmpsl_fem_nrf21540_gpio.a
deleted file mode 100644
index 2dfdc9e1f7..0000000000
Binary files a/mpsl/fem/nrf21540_gpio/lib/cortex-m33+nodsp/soft-float/libmpsl_fem_nrf21540_gpio.a and /dev/null differ
diff --git a/mpsl/fem/nrf21540_gpio/lib/cortex-m33+nodsp/soft-float/manifest.yaml b/mpsl/fem/nrf21540_gpio/lib/cortex-m33+nodsp/soft-float/manifest.yaml
deleted file mode 100644
index f3625b78d7..0000000000
--- a/mpsl/fem/nrf21540_gpio/lib/cortex-m33+nodsp/soft-float/manifest.yaml
+++ /dev/null
@@ -1,3 +0,0 @@
-description: MPSL Front-End Module nrf21540_gpio
-git_revision: 675065d227c03dc6af925a49aac8c224187e6339
-timestamp: '2023-12-22T08:07:58Z'
diff --git a/mpsl/fem/nrf21540_gpio/lib/cortex-m4/hard-float/libmpsl_fem_nrf21540_gpio.a b/mpsl/fem/nrf21540_gpio/lib/cortex-m4/hard-float/libmpsl_fem_nrf21540_gpio.a
deleted file mode 100644
index e9f4adfbcc..0000000000
Binary files a/mpsl/fem/nrf21540_gpio/lib/cortex-m4/hard-float/libmpsl_fem_nrf21540_gpio.a and /dev/null differ
diff --git a/mpsl/fem/nrf21540_gpio/lib/cortex-m4/hard-float/manifest.yaml b/mpsl/fem/nrf21540_gpio/lib/cortex-m4/hard-float/manifest.yaml
deleted file mode 100644
index 4cb54c19a1..0000000000
--- a/mpsl/fem/nrf21540_gpio/lib/cortex-m4/hard-float/manifest.yaml
+++ /dev/null
@@ -1,3 +0,0 @@
-description: MPSL Front-End Module nrf21540_gpio
-git_revision: 675065d227c03dc6af925a49aac8c224187e6339
-timestamp: '2023-12-22T08:02:30Z'
diff --git a/mpsl/fem/nrf21540_gpio/lib/cortex-m4/soft-float/libmpsl_fem_nrf21540_gpio.a b/mpsl/fem/nrf21540_gpio/lib/cortex-m4/soft-float/libmpsl_fem_nrf21540_gpio.a
deleted file mode 100644
index bbc73fa5f5..0000000000
Binary files a/mpsl/fem/nrf21540_gpio/lib/cortex-m4/soft-float/libmpsl_fem_nrf21540_gpio.a and /dev/null differ
diff --git a/mpsl/fem/nrf21540_gpio/lib/cortex-m4/soft-float/manifest.yaml b/mpsl/fem/nrf21540_gpio/lib/cortex-m4/soft-float/manifest.yaml
deleted file mode 100644
index 4cb54c19a1..0000000000
--- a/mpsl/fem/nrf21540_gpio/lib/cortex-m4/soft-float/manifest.yaml
+++ /dev/null
@@ -1,3 +0,0 @@
-description: MPSL Front-End Module nrf21540_gpio
-git_revision: 675065d227c03dc6af925a49aac8c224187e6339
-timestamp: '2023-12-22T08:02:30Z'
diff --git a/mpsl/fem/nrf21540_gpio/lib/cortex-m4/softfp-float/libmpsl_fem_nrf21540_gpio.a b/mpsl/fem/nrf21540_gpio/lib/cortex-m4/softfp-float/libmpsl_fem_nrf21540_gpio.a
deleted file mode 100644
index 80515fd2f4..0000000000
Binary files a/mpsl/fem/nrf21540_gpio/lib/cortex-m4/softfp-float/libmpsl_fem_nrf21540_gpio.a and /dev/null differ
diff --git a/mpsl/fem/nrf21540_gpio/lib/cortex-m4/softfp-float/manifest.yaml b/mpsl/fem/nrf21540_gpio/lib/cortex-m4/softfp-float/manifest.yaml
deleted file mode 100644
index 4cb54c19a1..0000000000
--- a/mpsl/fem/nrf21540_gpio/lib/cortex-m4/softfp-float/manifest.yaml
+++ /dev/null
@@ -1,3 +0,0 @@
-description: MPSL Front-End Module nrf21540_gpio
-git_revision: 675065d227c03dc6af925a49aac8c224187e6339
-timestamp: '2023-12-22T08:02:30Z'
diff --git a/mpsl/fem/nrf21540_gpio_spi/include/mpsl_fem_nrf21540_power_model_builtin.h b/mpsl/fem/nrf21540_gpio_spi/include/mpsl_fem_nrf21540_power_model_builtin.h
deleted file mode 100644
index b4eaa36a2a..0000000000
--- a/mpsl/fem/nrf21540_gpio_spi/include/mpsl_fem_nrf21540_power_model_builtin.h
+++ /dev/null
@@ -1,63 +0,0 @@
-/*
- * Copyright (c) Nordic Semiconductor ASA
- *
- * SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
- */
-
-/**
- * @file mpsl_fem_power_model.h
- *
- * The model describes how Front-End Module gain and SoC output power can be combined
- * to achieve requested output power on the antenna, given the current temperature,
- * voltage and operating frequency.
- *
- * @defgroup mpsl_fem_power_model MPSL Front-End Module power model APIs
- * @ingroup mpsl_fem
- *
- * @{
- */
-
-#ifndef MPSL_FEM_NRF21540_POWER_MODEL_BUILTIN_H__
-#define MPSL_FEM_NRF21540_POWER_MODEL_BUILTIN_H__
-
-#include "mpsl_fem_power_model.h"
-
-#ifdef __cplusplus
-extern "C" {
-#endif
-
-/**
- * @brief Update the built-in nRF21540 model using provided parameters.
- *
- * For given values of @p p_environment, this function populates the contents
- * of an internally stored, built-in MPSL nRF21540 power model.
- *
- * If the value of parameter passed to @ref mpsl_fem_power_model_set was different than the return
- * value of @ref mpsl_fem_nrf21540_power_model_builtin_get, this function does nothing.
- *
- * @note This function takes a significant amount of time to execute (approximately 5ms). Calling it
- * from high priority contexts might lead to degraded performance or starving
- * other contexts of the application.
- *
- * @param[in] p_environment Pointer to a structure that holds current external conditions
- * to recalculate the model for.
- */
-void mpsl_fem_nrf21540_power_model_builtin_update(const mpsl_fem_external_conditions_t * p_environment);
-
-/**
- * @brief Get the pointer to the built-in nRF21540 model.
- *
- * The pointer returned by this function can be used as a parameter to
- * @ref mpsl_fem_power_model_set that results in the built-in model being selected.
- *
- * @return Pointer to the internal, built-in nRF21540 model.
- */
-const mpsl_fem_power_model_t * mpsl_fem_nrf21540_power_model_builtin_get(void);
-
-#ifdef __cplusplus
-}
-#endif
-
-#endif // MPSL_FEM_POWER_MODEL_H__
-
-/**@} */
diff --git a/mpsl/fem/nrf21540_gpio_spi/lib/cortex-m33+nodsp/soft-float/libmpsl_fem_nrf21540_gpio_spi.a b/mpsl/fem/nrf21540_gpio_spi/lib/cortex-m33+nodsp/soft-float/libmpsl_fem_nrf21540_gpio_spi.a
deleted file mode 100644
index 076fd4eb32..0000000000
Binary files a/mpsl/fem/nrf21540_gpio_spi/lib/cortex-m33+nodsp/soft-float/libmpsl_fem_nrf21540_gpio_spi.a and /dev/null differ
diff --git a/mpsl/fem/nrf21540_gpio_spi/lib/cortex-m33+nodsp/soft-float/manifest.yaml b/mpsl/fem/nrf21540_gpio_spi/lib/cortex-m33+nodsp/soft-float/manifest.yaml
deleted file mode 100644
index e21360a675..0000000000
--- a/mpsl/fem/nrf21540_gpio_spi/lib/cortex-m33+nodsp/soft-float/manifest.yaml
+++ /dev/null
@@ -1,3 +0,0 @@
-description: MPSL Front-End Module nrf21540_gpio_spi
-git_revision: 675065d227c03dc6af925a49aac8c224187e6339
-timestamp: '2023-12-22T08:07:58Z'
diff --git a/mpsl/fem/nrf21540_gpio_spi/lib/cortex-m4/hard-float/libmpsl_fem_nrf21540_gpio_spi.a b/mpsl/fem/nrf21540_gpio_spi/lib/cortex-m4/hard-float/libmpsl_fem_nrf21540_gpio_spi.a
deleted file mode 100644
index bce969053e..0000000000
Binary files a/mpsl/fem/nrf21540_gpio_spi/lib/cortex-m4/hard-float/libmpsl_fem_nrf21540_gpio_spi.a and /dev/null differ
diff --git a/mpsl/fem/nrf21540_gpio_spi/lib/cortex-m4/hard-float/manifest.yaml b/mpsl/fem/nrf21540_gpio_spi/lib/cortex-m4/hard-float/manifest.yaml
deleted file mode 100644
index 2ffba30587..0000000000
--- a/mpsl/fem/nrf21540_gpio_spi/lib/cortex-m4/hard-float/manifest.yaml
+++ /dev/null
@@ -1,3 +0,0 @@
-description: MPSL Front-End Module nrf21540_gpio_spi
-git_revision: 675065d227c03dc6af925a49aac8c224187e6339
-timestamp: '2023-12-22T08:02:30Z'
diff --git a/mpsl/fem/nrf21540_gpio_spi/lib/cortex-m4/soft-float/libmpsl_fem_nrf21540_gpio_spi.a b/mpsl/fem/nrf21540_gpio_spi/lib/cortex-m4/soft-float/libmpsl_fem_nrf21540_gpio_spi.a
deleted file mode 100644
index ef37b0216e..0000000000
Binary files a/mpsl/fem/nrf21540_gpio_spi/lib/cortex-m4/soft-float/libmpsl_fem_nrf21540_gpio_spi.a and /dev/null differ
diff --git a/mpsl/fem/nrf21540_gpio_spi/lib/cortex-m4/soft-float/manifest.yaml b/mpsl/fem/nrf21540_gpio_spi/lib/cortex-m4/soft-float/manifest.yaml
deleted file mode 100644
index 2ffba30587..0000000000
--- a/mpsl/fem/nrf21540_gpio_spi/lib/cortex-m4/soft-float/manifest.yaml
+++ /dev/null
@@ -1,3 +0,0 @@
-description: MPSL Front-End Module nrf21540_gpio_spi
-git_revision: 675065d227c03dc6af925a49aac8c224187e6339
-timestamp: '2023-12-22T08:02:30Z'
diff --git a/mpsl/fem/nrf21540_gpio_spi/lib/cortex-m4/softfp-float/libmpsl_fem_nrf21540_gpio_spi.a b/mpsl/fem/nrf21540_gpio_spi/lib/cortex-m4/softfp-float/libmpsl_fem_nrf21540_gpio_spi.a
deleted file mode 100644
index 363cf3b342..0000000000
Binary files a/mpsl/fem/nrf21540_gpio_spi/lib/cortex-m4/softfp-float/libmpsl_fem_nrf21540_gpio_spi.a and /dev/null differ
diff --git a/mpsl/fem/nrf21540_gpio_spi/lib/cortex-m4/softfp-float/manifest.yaml b/mpsl/fem/nrf21540_gpio_spi/lib/cortex-m4/softfp-float/manifest.yaml
deleted file mode 100644
index 2ffba30587..0000000000
--- a/mpsl/fem/nrf21540_gpio_spi/lib/cortex-m4/softfp-float/manifest.yaml
+++ /dev/null
@@ -1,3 +0,0 @@
-description: MPSL Front-End Module nrf21540_gpio_spi
-git_revision: 675065d227c03dc6af925a49aac8c224187e6339
-timestamp: '2023-12-22T08:02:30Z'
diff --git a/mpsl/fem/simple_gpio/lib/cortex-m33+nodsp/soft-float/libmpsl_fem_simple_gpio.a b/mpsl/fem/simple_gpio/lib/cortex-m33+nodsp/soft-float/libmpsl_fem_simple_gpio.a
deleted file mode 100644
index f2df04e9c6..0000000000
Binary files a/mpsl/fem/simple_gpio/lib/cortex-m33+nodsp/soft-float/libmpsl_fem_simple_gpio.a and /dev/null differ
diff --git a/mpsl/fem/simple_gpio/lib/cortex-m33+nodsp/soft-float/manifest.yaml b/mpsl/fem/simple_gpio/lib/cortex-m33+nodsp/soft-float/manifest.yaml
deleted file mode 100644
index 887d193c9e..0000000000
--- a/mpsl/fem/simple_gpio/lib/cortex-m33+nodsp/soft-float/manifest.yaml
+++ /dev/null
@@ -1,3 +0,0 @@
-description: MPSL Front-End Module simple_gpio
-git_revision: 675065d227c03dc6af925a49aac8c224187e6339
-timestamp: '2023-12-22T08:07:58Z'
diff --git a/mpsl/fem/simple_gpio/lib/cortex-m4/hard-float/libmpsl_fem_simple_gpio.a b/mpsl/fem/simple_gpio/lib/cortex-m4/hard-float/libmpsl_fem_simple_gpio.a
deleted file mode 100644
index 51b35999bf..0000000000
Binary files a/mpsl/fem/simple_gpio/lib/cortex-m4/hard-float/libmpsl_fem_simple_gpio.a and /dev/null differ
diff --git a/mpsl/fem/simple_gpio/lib/cortex-m4/hard-float/manifest.yaml b/mpsl/fem/simple_gpio/lib/cortex-m4/hard-float/manifest.yaml
deleted file mode 100644
index d069abea5f..0000000000
--- a/mpsl/fem/simple_gpio/lib/cortex-m4/hard-float/manifest.yaml
+++ /dev/null
@@ -1,3 +0,0 @@
-description: MPSL Front-End Module simple_gpio
-git_revision: 675065d227c03dc6af925a49aac8c224187e6339
-timestamp: '2023-12-22T08:02:30Z'
diff --git a/mpsl/fem/simple_gpio/lib/cortex-m4/soft-float/libmpsl_fem_simple_gpio.a b/mpsl/fem/simple_gpio/lib/cortex-m4/soft-float/libmpsl_fem_simple_gpio.a
deleted file mode 100644
index bbcbf526f3..0000000000
Binary files a/mpsl/fem/simple_gpio/lib/cortex-m4/soft-float/libmpsl_fem_simple_gpio.a and /dev/null differ
diff --git a/mpsl/fem/simple_gpio/lib/cortex-m4/soft-float/manifest.yaml b/mpsl/fem/simple_gpio/lib/cortex-m4/soft-float/manifest.yaml
deleted file mode 100644
index d069abea5f..0000000000
--- a/mpsl/fem/simple_gpio/lib/cortex-m4/soft-float/manifest.yaml
+++ /dev/null
@@ -1,3 +0,0 @@
-description: MPSL Front-End Module simple_gpio
-git_revision: 675065d227c03dc6af925a49aac8c224187e6339
-timestamp: '2023-12-22T08:02:30Z'
diff --git a/mpsl/fem/simple_gpio/lib/cortex-m4/softfp-float/libmpsl_fem_simple_gpio.a b/mpsl/fem/simple_gpio/lib/cortex-m4/softfp-float/libmpsl_fem_simple_gpio.a
deleted file mode 100644
index 1378aec23a..0000000000
Binary files a/mpsl/fem/simple_gpio/lib/cortex-m4/softfp-float/libmpsl_fem_simple_gpio.a and /dev/null differ
diff --git a/mpsl/fem/simple_gpio/lib/cortex-m4/softfp-float/manifest.yaml b/mpsl/fem/simple_gpio/lib/cortex-m4/softfp-float/manifest.yaml
deleted file mode 100644
index d069abea5f..0000000000
--- a/mpsl/fem/simple_gpio/lib/cortex-m4/softfp-float/manifest.yaml
+++ /dev/null
@@ -1,3 +0,0 @@
-description: MPSL Front-End Module simple_gpio
-git_revision: 675065d227c03dc6af925a49aac8c224187e6339
-timestamp: '2023-12-22T08:02:30Z'
diff --git a/mpsl/include/mpsl.h b/mpsl/include/mpsl.h
index 6d3738e23e..c06812d6e7 100644
--- a/mpsl/include/mpsl.h
+++ b/mpsl/include/mpsl.h
@@ -40,8 +40,6 @@ extern "C" {
/** @brief Bitmask of (D)PPI channels reserved for MPSL. */
#if defined(PPI_PRESENT)
#define MPSL_RESERVED_PPI_CHANNELS ((1UL << 19) | (1UL << 30) | (1UL << 31))
-#elif defined(GRTC_PRESENT)
-#define MPSL_RESERVED_PPI_CHANNELS (1UL << 0)
#elif defined(DPPIC_PRESENT)
#define MPSL_RESERVED_PPI_CHANNELS ((1UL << 0) | (1UL << 1) | (1UL << 2))
#else
@@ -145,17 +143,6 @@ void MPSL_IRQ_CLOCK_Handler(void);
*/
void mpsl_low_priority_process(void);
-/** @brief Application needs to call this when calibration shall occur.
- *
- * In the nRF Connect SDK, it is designed to be called with a period of CONFIG_CLOCK_CONTROL_NRF_CALIBRATION_PERIOD
- */
-void mpsl_calibration_timer_handle(void);
-
-/** @brief RFU
- *
- * RFU
- */
-void mpsl_pan_rfu(void);
#ifdef __cplusplus
}
#endif
diff --git a/mpsl/include/mpsl_clock.h b/mpsl/include/mpsl_clock.h
index 6d1c2f1134..fe7ccb2958 100644
--- a/mpsl/include/mpsl_clock.h
+++ b/mpsl/include/mpsl_clock.h
@@ -136,10 +136,6 @@ typedef void (*mpsl_clock_hfclk_callback_t)(void);
* @see mpsl_clock_hfclk_is_running
* @see mpsl_clock_hfclk_release
*
- * @note Don't use this API if the integration layer of MPSL provides a driver that uses this function.
- * This is the case for applications in the nRF Connect SDK where there is a clock control driver
- * with a corresponding on/off manager.
- *
* @param[in] hfclk_started_callback Function to be called when the high frequency clock is started.
* The callback will be executed in the context as
* @ref mpsl_low_priority_process.
@@ -156,10 +152,6 @@ int32_t mpsl_clock_hfclk_request(mpsl_clock_hfclk_callback_t hfclk_started_callb
* @see mpsl_clock_hfclk_is_running
* @see mpsl_clock_hfclk_request
*
- * @note Don't use this API if the integration layer of MPSL provides a driver that uses this function.
- * This is the case for applications in the nRF Connect SDK where there is a clock control driver
- * with a corresponding on/off manager.
- *
* @retval 0 Success
*/
int32_t mpsl_clock_hfclk_release(void);
@@ -184,14 +176,6 @@ int32_t mpsl_clock_hfclk_is_running(uint32_t * p_is_running);
*/
int32_t mpsl_clock_hfclk_latency_set(mpsl_clock_hfclk_latency_config_t mpsl_clock_hfclk_latency_config);
-/** @brief Trigger a task upon start of the RTC.
- *
- * MPSL will trigger the task at the same time as the RTC is started.
- *
- * @param[in] task_address The task address to be triggered
- */
-void mpsl_clock_task_trigger_on_rtc_start_set(uint32_t task_address);
-
#ifdef __cplusplus
}
#endif
diff --git a/mpsl/fem/include/mpsl_fem_config_common.h b/mpsl/include/mpsl_fem_config_common.h
similarity index 100%
rename from mpsl/fem/include/mpsl_fem_config_common.h
rename to mpsl/include/mpsl_fem_config_common.h
diff --git a/mpsl/fem/include/mpsl_fem_config_nrf21540_common.h b/mpsl/include/mpsl_fem_config_nrf21540_common.h
similarity index 100%
rename from mpsl/fem/include/mpsl_fem_config_nrf21540_common.h
rename to mpsl/include/mpsl_fem_config_nrf21540_common.h
diff --git a/mpsl/fem/nrf21540_gpio/include/mpsl_fem_config_nrf21540_gpio.h b/mpsl/include/mpsl_fem_config_nrf21540_gpio.h
similarity index 100%
rename from mpsl/fem/nrf21540_gpio/include/mpsl_fem_config_nrf21540_gpio.h
rename to mpsl/include/mpsl_fem_config_nrf21540_gpio.h
diff --git a/mpsl/fem/nrf21540_gpio_spi/include/mpsl_fem_config_nrf21540_gpio_spi.h b/mpsl/include/mpsl_fem_config_nrf21540_gpio_spi.h
similarity index 100%
rename from mpsl/fem/nrf21540_gpio_spi/include/mpsl_fem_config_nrf21540_gpio_spi.h
rename to mpsl/include/mpsl_fem_config_nrf21540_gpio_spi.h
diff --git a/mpsl/fem/simple_gpio/include/mpsl_fem_config_simple_gpio.h b/mpsl/include/mpsl_fem_config_simple_gpio.h
similarity index 100%
rename from mpsl/fem/simple_gpio/include/mpsl_fem_config_simple_gpio.h
rename to mpsl/include/mpsl_fem_config_simple_gpio.h
diff --git a/mpsl/fem/include/mpsl_fem_init.h b/mpsl/include/mpsl_fem_init.h
similarity index 100%
rename from mpsl/fem/include/mpsl_fem_init.h
rename to mpsl/include/mpsl_fem_init.h
diff --git a/mpsl/fem/include/mpsl_fem_power_model.h b/mpsl/include/mpsl_fem_power_model.h
similarity index 81%
rename from mpsl/fem/include/mpsl_fem_power_model.h
rename to mpsl/include/mpsl_fem_power_model.h
index 826f4c48cc..609dcedd07 100644
--- a/mpsl/fem/include/mpsl_fem_power_model.h
+++ b/mpsl/include/mpsl_fem_power_model.h
@@ -135,6 +135,34 @@ typedef struct
*/
int32_t mpsl_fem_power_model_set(const mpsl_fem_power_model_t * p_model);
+/**
+ * @brief Updates the built-in nRF21540 model using provided parameters.
+ *
+ * For given values of @p p_environment, this function populates the contents
+ * of an internally stored, built-in MPSL nRF21540 power model.
+ *
+ * If the value of parameter passed to @ref mpsl_fem_power_model_set was different than the return
+ * value of @ref mpsl_fem_nrf21540_power_model_builtin_get, this function does nothing.
+ *
+ * @note This function takes a significant amount of time to execute (approximately 5ms). Calling it
+ * from high priority contexts might lead to degraded performance or starving
+ * other contexts of the application.
+ *
+ * @param[in] p_environment Pointer to a structure that holds current external conditions
+ * to recalculate the model for.
+ */
+void mpsl_fem_nrf21540_power_model_builtin_update(const mpsl_fem_external_conditions_t * p_environment);
+
+/**
+ * @brief Gets the pointer to the built-in nRF21540 model.
+ *
+ * The pointer returned by this function can be used as a parameter to
+ * @ref mpsl_fem_power_model_set that results in the built-in model being selected.
+ *
+ * @return Pointer to the internal, built-in nRF21540 model.
+ */
+const mpsl_fem_power_model_t * mpsl_fem_nrf21540_power_model_builtin_get(void);
+
#ifdef __cplusplus
}
#endif
diff --git a/mpsl/fem/include/mpsl_fem_types.h b/mpsl/include/mpsl_fem_types.h
similarity index 100%
rename from mpsl/fem/include/mpsl_fem_types.h
rename to mpsl/include/mpsl_fem_types.h
diff --git a/mpsl/include/mpsl_radio_notification.h b/mpsl/include/mpsl_radio_notification.h
new file mode 100644
index 0000000000..89b6367739
--- /dev/null
+++ b/mpsl/include/mpsl_radio_notification.h
@@ -0,0 +1,101 @@
+/*
+ * Copyright (c) Nordic Semiconductor ASA
+ *
+ * SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
+ */
+
+/**
+ * @file mpsl_radio_notification.h
+ *
+ * @defgroup mpsl_radio_notification MPSL Radio notification interface
+ * @ingroup mpsl
+ *
+ * The MPSL radio interface provides APIs for configuring radio notifications.
+ * When radio notifications are enabled, the application is notified when an
+ * MPSL timeslot starts or ends. By using radio notifications, the application is
+ * informed when a protocol uses the radio.
+ *
+ * @{
+ */
+
+#ifndef MPSL_RADIO_NOTIFICATION_H__
+#define MPSL_RADIO_NOTIFICATION_H__
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include
+#include
+#include "nrf.h"
+#include "nrf_errno.h"
+
+/** @brief Guaranteed time for application to process radio inactive notification. */
+#define MPSL_RADIO_NOTIFICATION_INACTIVE_GUARANTEED_TIME_US (62)
+
+/** @brief Radio notification distances. */
+enum MPSL_RADIO_NOTIFICATION_DISTANCES
+{
+ MPSL_RADIO_NOTIFICATION_DISTANCE_NONE = 0, /**< The event does not have a notification. */
+ MPSL_RADIO_NOTIFICATION_DISTANCE_200US, /**< The distance from the active notification to start of radio activity. */
+ MPSL_RADIO_NOTIFICATION_DISTANCE_420US, /**< The distance from the active notification to start of radio activity. */
+ MPSL_RADIO_NOTIFICATION_DISTANCE_800US, /**< The distance from the active notification to start of radio activity. */
+ MPSL_RADIO_NOTIFICATION_DISTANCE_1740US, /**< The distance from the active notification to start of radio activity. */
+ MPSL_RADIO_NOTIFICATION_DISTANCE_2680US, /**< The distance from the active notification to start of radio activity. */
+ MPSL_RADIO_NOTIFICATION_DISTANCE_3620US, /**< The distance from the active notification to start of radio activity. */
+ MPSL_RADIO_NOTIFICATION_DISTANCE_4560US, /**< The distance from the active notification to start of radio activity. */
+ MPSL_RADIO_NOTIFICATION_DISTANCE_5500US /**< The distance from the active notification to start of radio activity. */
+};
+
+/** @brief Radio notification types. */
+enum MPSL_RADIO_NOTIFICATION_TYPES
+{
+ MPSL_RADIO_NOTIFICATION_TYPE_NONE = 0, /**< The event does not have a radio notification signal. */
+ MPSL_RADIO_NOTIFICATION_TYPE_INT_ON_ACTIVE, /**< Using interrupt for notification when the radio will be enabled. */
+ MPSL_RADIO_NOTIFICATION_TYPE_INT_ON_INACTIVE, /**< Using interrupt for notification when the radio has been disabled. */
+ MPSL_RADIO_NOTIFICATION_TYPE_INT_ON_BOTH, /**< Using interrupt for notification both when the radio will be enabled and disabled. */
+};
+
+/** @brief Configures the Radio Notification signal.
+ *
+ * @note
+ * - The notification signal latency depends on the interrupt priority settings of IRQ used
+ * for notification signal.
+ * - To ensure that the radio notification signal behaves in a consistent way, the radio
+ * notifications must be configured when there is no protocol stack enabled.
+ * It is recommended that the radio notification signal is
+ * configured directly after the MPSL is enabled.
+ *
+ * @param[in] type Type of notification signal, see @ref MPSL_RADIO_NOTIFICATION_TYPES.
+ * @ref MPSL_RADIO_NOTIFICATION_TYPE_NONE shall be used to turn off radio
+ * notification. Using @ref MPSL_RADIO_NOTIFICATION_DISTANCE_NONE is
+ * recommended (but not required) to be used with
+ * @ref MPSL_RADIO_NOTIFICATION_TYPE_NONE.
+ *
+ * @param[in] distance Distance between the notification signal and start of radio activity,
+ * see @ref MPSL_RADIO_NOTIFICATION_DISTANCES.
+ * This parameter is ignored when @ref MPSL_RADIO_NOTIFICATION_TYPE_NONE or
+ * @ref MPSL_RADIO_NOTIFICATION_TYPE_INT_ON_INACTIVE is used.
+ *
+ * @param[in] irq IRQ to pend as the radio notification signal, e.g SWI1_IRQn.
+ * If the application uses IRQs that are already in use, e.g, RADIO_IRQn,
+ * TIMER0_IQRn or similar, the behavior is undefined.
+ * The interrupt priority level should be lower than priority level 0, that is,
+ * a higher numerical priority value. The application is responsible for
+ * setting the interrupt priority.
+ *
+ *
+ * @retval -NRF_EINVAL Invalid parameters supplied.
+ * @retval -NRF_EINPROGRESS A protocol stack or other SoftDevice is running. Stop all
+ * running activities and retry.
+ * @retval 0 Success
+ */
+int32_t mpsl_radio_notification_cfg_set(uint8_t type, uint8_t distance, IRQn_Type irq);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif // MPSL_RADIO_NOTIFICATION_H__
+
+/**@} */
diff --git a/mpsl/include/mpsl_timeslot.h b/mpsl/include/mpsl_timeslot.h
index fe21cc940a..fcd5f3785d 100644
--- a/mpsl/include/mpsl_timeslot.h
+++ b/mpsl/include/mpsl_timeslot.h
@@ -25,8 +25,6 @@ extern "C" {
#endif
#include
-#include "nrf.h"
-#include "nrf_peripherals.h"
#include "nrf_errno.h"
/** @brief The shortest allowed timeslot event in microseconds. */
@@ -43,11 +41,7 @@ extern "C" {
#define MPSL_TIMESLOT_EARLIEST_TIMEOUT_MAX_US (256000000UL - 1UL)
/** @brief The maximum jitter in @ref MPSL_TIMESLOT_SIGNAL_START relative to the requested start time. */
-#if defined(GRTC_PRESENT)
-#define MPSL_TIMESLOT_START_JITTER_US (0UL)
-#else
#define MPSL_TIMESLOT_START_JITTER_US (1UL)
-#endif
/** @brief The minimum allowed timeslot extension time. */
#define MPSL_TIMESLOT_EXTENSION_TIME_MIN_US (200UL)
diff --git a/mpsl/include/mpsl_tx_power.h b/mpsl/include/mpsl_tx_power.h
index 4cc0a42e06..f3f01a81fc 100644
--- a/mpsl/include/mpsl_tx_power.h
+++ b/mpsl/include/mpsl_tx_power.h
@@ -89,15 +89,6 @@ int32_t mpsl_tx_power_channel_map_set(const mpsl_tx_power_envelope_t *const p_en
*/
mpsl_tx_power_t mpsl_tx_power_radio_supported_power_adjust(mpsl_tx_power_t req_radio_power, int8_t tx_power_ceiling);
-/** @brief Converts radio power in dBm to RADIO.TXPOWER register code.
- *
- * @param[in] req_radio_power Requested TX power desired for RADIO peripheral.
- * The power value in dBm must be supported by the RADIO peripheral.
- *
- * @return RADIO.TXPOWER register code corrensponding to a radio power in dBm.
- */
-uint32_t mpsl_tx_power_dbm_to_radio_register_convert(mpsl_tx_power_t req_radio_power);
-
#ifdef __cplusplus
}
#endif
diff --git a/mpsl/fem/include/protocol/mpsl_fem_protocol_api.h b/mpsl/include/protocol/mpsl_fem_protocol_api.h
similarity index 100%
rename from mpsl/fem/include/protocol/mpsl_fem_protocol_api.h
rename to mpsl/include/protocol/mpsl_fem_protocol_api.h
diff --git a/mpsl/lib/cortex-m33+nodsp/soft-float/libmpsl.a b/mpsl/lib/cortex-m33+nodsp/soft-float/libmpsl.a
index 3b41cfaa4c..45b0909136 100644
Binary files a/mpsl/lib/cortex-m33+nodsp/soft-float/libmpsl.a and b/mpsl/lib/cortex-m33+nodsp/soft-float/libmpsl.a differ
diff --git a/mpsl/lib/cortex-m33+nodsp/soft-float/manifest.yaml b/mpsl/lib/cortex-m33+nodsp/soft-float/manifest.yaml
index a4c739481b..0b2fd09f80 100644
--- a/mpsl/lib/cortex-m33+nodsp/soft-float/manifest.yaml
+++ b/mpsl/lib/cortex-m33+nodsp/soft-float/manifest.yaml
@@ -1,3 +1,3 @@
description: Multi-Protocol Service Layer (MPSL)
-git_revision: 675065d227c03dc6af925a49aac8c224187e6339
-timestamp: '2023-12-22T08:07:59Z'
+git_revision: 04473a46b0a1502dc5cc8091b5903173bb5b6bd0
+timestamp: '2024-01-23T19:45:48Z'
diff --git a/mpsl/lib/cortex-m4/hard-float/libmpsl.a b/mpsl/lib/cortex-m4/hard-float/libmpsl.a
index a400e89e07..ea8321e9a6 100644
Binary files a/mpsl/lib/cortex-m4/hard-float/libmpsl.a and b/mpsl/lib/cortex-m4/hard-float/libmpsl.a differ
diff --git a/mpsl/lib/cortex-m4/hard-float/manifest.yaml b/mpsl/lib/cortex-m4/hard-float/manifest.yaml
index 9a550ba228..50afe3669b 100644
--- a/mpsl/lib/cortex-m4/hard-float/manifest.yaml
+++ b/mpsl/lib/cortex-m4/hard-float/manifest.yaml
@@ -1,3 +1,3 @@
description: Multi-Protocol Service Layer (MPSL)
-git_revision: 675065d227c03dc6af925a49aac8c224187e6339
-timestamp: '2023-12-22T08:02:30Z'
+git_revision: 04473a46b0a1502dc5cc8091b5903173bb5b6bd0
+timestamp: '2024-01-23T19:45:26Z'
diff --git a/mpsl/lib/cortex-m4/soft-float/libmpsl.a b/mpsl/lib/cortex-m4/soft-float/libmpsl.a
index cdc7f1cc63..a688c09472 100644
Binary files a/mpsl/lib/cortex-m4/soft-float/libmpsl.a and b/mpsl/lib/cortex-m4/soft-float/libmpsl.a differ
diff --git a/mpsl/lib/cortex-m4/soft-float/manifest.yaml b/mpsl/lib/cortex-m4/soft-float/manifest.yaml
index 9a550ba228..50afe3669b 100644
--- a/mpsl/lib/cortex-m4/soft-float/manifest.yaml
+++ b/mpsl/lib/cortex-m4/soft-float/manifest.yaml
@@ -1,3 +1,3 @@
description: Multi-Protocol Service Layer (MPSL)
-git_revision: 675065d227c03dc6af925a49aac8c224187e6339
-timestamp: '2023-12-22T08:02:30Z'
+git_revision: 04473a46b0a1502dc5cc8091b5903173bb5b6bd0
+timestamp: '2024-01-23T19:45:26Z'
diff --git a/mpsl/lib/cortex-m4/softfp-float/libmpsl.a b/mpsl/lib/cortex-m4/softfp-float/libmpsl.a
index 2743a74095..5ad908ccb7 100644
Binary files a/mpsl/lib/cortex-m4/softfp-float/libmpsl.a and b/mpsl/lib/cortex-m4/softfp-float/libmpsl.a differ
diff --git a/mpsl/lib/cortex-m4/softfp-float/manifest.yaml b/mpsl/lib/cortex-m4/softfp-float/manifest.yaml
index 9a550ba228..50afe3669b 100644
--- a/mpsl/lib/cortex-m4/softfp-float/manifest.yaml
+++ b/mpsl/lib/cortex-m4/softfp-float/manifest.yaml
@@ -1,3 +1,3 @@
description: Multi-Protocol Service Layer (MPSL)
-git_revision: 675065d227c03dc6af925a49aac8c224187e6339
-timestamp: '2023-12-22T08:02:30Z'
+git_revision: 04473a46b0a1502dc5cc8091b5903173bb5b6bd0
+timestamp: '2024-01-23T19:45:26Z'
diff --git a/mpsl/mpsl.rst b/mpsl/mpsl.rst
new file mode 100644
index 0000000000..198e0bd99d
--- /dev/null
+++ b/mpsl/mpsl.rst
@@ -0,0 +1,109 @@
+.. _mpsl_lib:
+
+Integration notes
+#################
+
+.. contents::
+ :local:
+ :depth: 2
+
+This page describes how to integrate the Multiprotocol Service Layer (MPSL) into an application.
+The descriptions are valid for both RTOS and RTOS-free environments.
+
+For the nRF53 Series, the requirements described are only relevant for applications running alongside the MPSL on the network processor.
+
+The following peripherals are owned by MPSL and must not be accessed directly by the application:
+
+ * ``RTC0``
+ * ``TIMER0``
+ * ``TIMER1`` (for the nRF53 Series)
+ * ``RADIO``
+ * ``CLOCK``
+ * ``TEMP``
+ * PPI channel: ``19``, ``30``, ``31`` (for the nRF52 Series)
+ * DPPI channels: ``0``, ``1``, ``2`` (for the nRF53 Series)
+
+.. note::
+ These peripherals can be used freely when MPSL is not initialized.
+ Additional peripheral requirements may be set by the protocol stacks in use.
+
+Limited access to these peripherals is provided through the MPSL Timeslot module and other MPSL APIs.
+
+Thread and interrupt safety
+***************************
+
+The MPSL library is not reentrant.
+For thread-safe operation, see the _ and _ sections below.
+
+Interrupt configuration
+=======================
+
+MPSL enables interrupts for ``RTC0``, ``TIMER0``, ``TIMER1`` (only on nRF53 Series), ``POWER_CLOCK``, and ``low_prio_irq``.
+The application must enable and configure all the other interrupts.
+If the Timeslot API is used for ``RADIO`` access, the application is responsible for enabling and disabling the interrupt for ``RADIO``.
+
+The application must configure interrupts for ``RTC0``, ``TIMER0``, and ``RADIO`` for priority level ``0`` ( :c:macro:`MPSL_HIGH_IRQ_PRIORITY` ).
+On the nRF53 Series, the application must additionally configure ``TIMER1`` for priority level ``0`` ( :c:macro:`MPSL_HIGH_IRQ_PRIORITY` ).
+
+The following interrupts do not have real-time requirements:
+
+ * ``POWER_CLOCK``
+ It is up to the application to forward any clock-related events to :c:func:`MPSL_IRQ_CLOCK_Handler` in lower priority.
+ Irrelevant events are ignored, so the application is free to forward all events for the ``POWER_CLOCK`` interrupt.
+
+ * ``low_prio_irq``
+ Low-priority work is signaled by MPSL by adding the IRQ specified in the ``low_prio_irq`` argument to :c:func:`mpsl_init`.
+ When this interrupt is triggered, :c:func:`mpsl_low_priority_process` should be called as soon as possible (at least within a couple of ms).
+ The application should configure this interrupt priority lower than :c:macro:`MPSL_HIGH_IRQ_PRIORITY` level (namely, a higher numerical value).
+ The interrupt is enabled with :c:func:`mpsl_init` and disabled with :c:func:`mpsl_uninit` by MPSL.
+
+Scheduling
+==========
+
+The interaction of the MPSL library with protocol stacks is designed to run at two interrupt priority levels: one for the high-priority handlers, and one for the low-priority handler.
+The interaction of the MPSL library with the application happens in the thread context and in the low-priority handler.
+
+High priority
+-------------
+
+The high-priority handlers are mostly used for timing-critical operations related to radio or scheduling.
+Interrupting or delaying these handlers leads to undefined behavior.
+
+Low priority
+------------
+
+Low priority is used for background tasks that are not directly tied to the radio or scheduling.
+These tasks are designed in such a way that they can be interrupted by high-priority code.
+The tasks are however not designed to be interrupted by other low-priority tasks.
+Therefore, make sure that only one MPSL API function is called from the application at any time.
+
+ * All protocol stacks using MPSL must be synchronized (namely, not called concurrently) to avoid concurrent calls to MPSL functions.
+ * Application must only call MPSL APIs from non-preemptible threads, or with interrupts disabled (namely, during initialization).
+ * The :c:func:`mpsl_low_priority_process` function should only be called from thread context, namely, not directly from the software interrupt handler.
+ * Alternatively, you can use synchronization primitives to ensure that no MPSL functions are called at the same time.
+
+Other priorities
+----------------
+
+MPSL initialization functions, like :c:func:`mpsl_init` and :c:func:`mpsl_uninit`, are not thread-safe.
+Do not call them while, for example, a protocol timeslot is in progress.
+This must be enforced by application and protocol stacks.
+
+MPSL should be initialized before any protocol stack is enabled, and uninitialized after all protocol stacks have been disabled.
+
+Architecture diagrams
+---------------------
+
+The following image shows how the MPSL integrates into an RTOS-free environment.
+
+.. figure:: pic/Architecture_Without_RTOS.svg
+ :alt: MPSL integration in an RTOS-free environment
+
+ MPSL integration into an RTOS-free environment
+
+The following image shows how the MPSL integrates into an RTOS.
+
+.. figure:: pic/Architecture_With_RTOS.svg
+ :alt: MPSL integration with an RTOS
+
+ MPSL integration into an RTOS
diff --git a/mpsl/mpsl_coex_1wire_timing_grant.png b/mpsl/mpsl_coex_1wire_timing_grant.png
new file mode 100644
index 0000000000..51f2a65650
Binary files /dev/null and b/mpsl/mpsl_coex_1wire_timing_grant.png differ
diff --git a/mpsl/mpsl_coex_1wire_timing_grant.svg b/mpsl/mpsl_coex_1wire_timing_grant.svg
new file mode 100644
index 0000000000..246418f71b
--- /dev/null
+++ b/mpsl/mpsl_coex_1wire_timing_grant.svg
@@ -0,0 +1,110 @@
+
+
+
+
diff --git a/mpsl/mpsl_coex_1wire_timing_grant.vsdx b/mpsl/mpsl_coex_1wire_timing_grant.vsdx
new file mode 100644
index 0000000000..43ed3acf13
Binary files /dev/null and b/mpsl/mpsl_coex_1wire_timing_grant.vsdx differ
diff --git a/mpsl/mpsl_coex_3wire_timings_delays.png b/mpsl/mpsl_coex_3wire_timings_delays.png
new file mode 100644
index 0000000000..6a0483520a
Binary files /dev/null and b/mpsl/mpsl_coex_3wire_timings_delays.png differ
diff --git a/mpsl/mpsl_coex_3wire_timings_delays.svg b/mpsl/mpsl_coex_3wire_timings_delays.svg
new file mode 100644
index 0000000000..380b224555
--- /dev/null
+++ b/mpsl/mpsl_coex_3wire_timings_delays.svg
@@ -0,0 +1,245 @@
+
+
+
+
diff --git a/mpsl/mpsl_coex_3wire_timings_delays.vsdx b/mpsl/mpsl_coex_3wire_timings_delays.vsdx
new file mode 100644
index 0000000000..5757f48738
Binary files /dev/null and b/mpsl/mpsl_coex_3wire_timings_delays.vsdx differ
diff --git a/mpsl/pic/Architecture_With_RTOS.svg b/mpsl/pic/Architecture_With_RTOS.svg
new file mode 100644
index 0000000000..a2f5b195d1
--- /dev/null
+++ b/mpsl/pic/Architecture_With_RTOS.svg
@@ -0,0 +1,256 @@
+
+
+
+
diff --git a/mpsl/pic/Architecture_With_RTOS.vsdx b/mpsl/pic/Architecture_With_RTOS.vsdx
new file mode 100644
index 0000000000..24eadd2221
Binary files /dev/null and b/mpsl/pic/Architecture_With_RTOS.vsdx differ
diff --git a/mpsl/pic/Architecture_Without_RTOS.svg b/mpsl/pic/Architecture_Without_RTOS.svg
new file mode 100644
index 0000000000..1f79bcf999
--- /dev/null
+++ b/mpsl/pic/Architecture_Without_RTOS.svg
@@ -0,0 +1,145 @@
+
+
+
+
diff --git a/mpsl/pic/Architecture_Without_RTOS.vsdx b/mpsl/pic/Architecture_Without_RTOS.vsdx
new file mode 100644
index 0000000000..e67d3c0b13
Binary files /dev/null and b/mpsl/pic/Architecture_Without_RTOS.vsdx differ
diff --git a/mpsl/pic/FEM_sequence_nRF21540.svg b/mpsl/pic/FEM_sequence_nRF21540.svg
new file mode 100644
index 0000000000..04fc8d3368
--- /dev/null
+++ b/mpsl/pic/FEM_sequence_nRF21540.svg
@@ -0,0 +1,297 @@
+
+
+
+
diff --git a/mpsl/pic/FEM_sequence_nRF21540.vsdx b/mpsl/pic/FEM_sequence_nRF21540.vsdx
new file mode 100644
index 0000000000..ec500d088c
Binary files /dev/null and b/mpsl/pic/FEM_sequence_nRF21540.vsdx differ
diff --git a/mpsl/pic/FEM_sequence_simple.svg b/mpsl/pic/FEM_sequence_simple.svg
new file mode 100644
index 0000000000..84d7cb808d
--- /dev/null
+++ b/mpsl/pic/FEM_sequence_simple.svg
@@ -0,0 +1,229 @@
+
+
+
+
diff --git a/mpsl/pic/FEM_sequence_simple.vsdx b/mpsl/pic/FEM_sequence_simple.vsdx
new file mode 100644
index 0000000000..1b7fa1cff4
Binary files /dev/null and b/mpsl/pic/FEM_sequence_simple.vsdx differ
diff --git a/mpsl/pic/FEM_timing_nRF21540.svg b/mpsl/pic/FEM_timing_nRF21540.svg
new file mode 100644
index 0000000000..cb90564fd7
--- /dev/null
+++ b/mpsl/pic/FEM_timing_nRF21540.svg
@@ -0,0 +1,390 @@
+
+
+
+
diff --git a/mpsl/pic/FEM_timing_nRF21540.vsdx b/mpsl/pic/FEM_timing_nRF21540.vsdx
new file mode 100644
index 0000000000..21fb457082
Binary files /dev/null and b/mpsl/pic/FEM_timing_nRF21540.vsdx differ
diff --git a/mpsl/pic/FEM_timing_simple.svg b/mpsl/pic/FEM_timing_simple.svg
new file mode 100644
index 0000000000..0316e24ed9
--- /dev/null
+++ b/mpsl/pic/FEM_timing_simple.svg
@@ -0,0 +1,319 @@
+
+
+
+
diff --git a/mpsl/pic/FEM_timing_simple.vsdx b/mpsl/pic/FEM_timing_simple.vsdx
new file mode 100644
index 0000000000..87678acd96
Binary files /dev/null and b/mpsl/pic/FEM_timing_simple.vsdx differ
diff --git a/mpsl/pic/cx_3w_timing_param.svg b/mpsl/pic/cx_3w_timing_param.svg
new file mode 100644
index 0000000000..e3d0bcc47e
--- /dev/null
+++ b/mpsl/pic/cx_3w_timing_param.svg
@@ -0,0 +1,240 @@
+
+
+
+
diff --git a/mpsl/pic/cx_3w_timing_param.vsdx b/mpsl/pic/cx_3w_timing_param.vsdx
new file mode 100644
index 0000000000..10fb47d846
Binary files /dev/null and b/mpsl/pic/cx_3w_timing_param.vsdx differ
diff --git a/mpsl/pic/mpsl_coex_1wire_timing_grant.png b/mpsl/pic/mpsl_coex_1wire_timing_grant.png
new file mode 100644
index 0000000000..51f2a65650
Binary files /dev/null and b/mpsl/pic/mpsl_coex_1wire_timing_grant.png differ
diff --git a/mpsl/pic/mpsl_coex_1wire_timing_grant.svg b/mpsl/pic/mpsl_coex_1wire_timing_grant.svg
new file mode 100644
index 0000000000..246418f71b
--- /dev/null
+++ b/mpsl/pic/mpsl_coex_1wire_timing_grant.svg
@@ -0,0 +1,110 @@
+
+
+
+
diff --git a/mpsl/pic/mpsl_coex_1wire_timing_grant.vsdx b/mpsl/pic/mpsl_coex_1wire_timing_grant.vsdx
new file mode 100644
index 0000000000..43ed3acf13
Binary files /dev/null and b/mpsl/pic/mpsl_coex_1wire_timing_grant.vsdx differ
diff --git a/mpsl/pic/mpsl_coex_3wire_timings_delays.png b/mpsl/pic/mpsl_coex_3wire_timings_delays.png
new file mode 100644
index 0000000000..6a0483520a
Binary files /dev/null and b/mpsl/pic/mpsl_coex_3wire_timings_delays.png differ
diff --git a/mpsl/pic/mpsl_coex_3wire_timings_delays.svg b/mpsl/pic/mpsl_coex_3wire_timings_delays.svg
new file mode 100644
index 0000000000..380b224555
--- /dev/null
+++ b/mpsl/pic/mpsl_coex_3wire_timings_delays.svg
@@ -0,0 +1,245 @@
+
+
+
+
diff --git a/mpsl/pic/mpsl_coex_3wire_timings_delays.vsdx b/mpsl/pic/mpsl_coex_3wire_timings_delays.vsdx
new file mode 100644
index 0000000000..5757f48738
Binary files /dev/null and b/mpsl/pic/mpsl_coex_3wire_timings_delays.vsdx differ
diff --git a/mpsl/pic/radio_notification_two_events.svg b/mpsl/pic/radio_notification_two_events.svg
new file mode 100644
index 0000000000..e68f6750b1
--- /dev/null
+++ b/mpsl/pic/radio_notification_two_events.svg
@@ -0,0 +1,108 @@
+
+
+
+
diff --git a/mpsl/pic/radio_notification_two_events.vsdx b/mpsl/pic/radio_notification_two_events.vsdx
new file mode 100644
index 0000000000..558a8000a5
Binary files /dev/null and b/mpsl/pic/radio_notification_two_events.vsdx differ
diff --git a/mpsl/pic/radio_notification_two_events_too_close.svg b/mpsl/pic/radio_notification_two_events_too_close.svg
new file mode 100644
index 0000000000..689c82bbd7
--- /dev/null
+++ b/mpsl/pic/radio_notification_two_events_too_close.svg
@@ -0,0 +1,90 @@
+
+
+
+
diff --git a/mpsl/pic/radio_notification_two_events_too_close.vsdx b/mpsl/pic/radio_notification_two_events_too_close.vsdx
new file mode 100644
index 0000000000..6c29443a14
Binary files /dev/null and b/mpsl/pic/radio_notification_two_events_too_close.vsdx differ
diff --git a/mpsl/pic/timeslot_blocked.svg b/mpsl/pic/timeslot_blocked.svg
new file mode 100644
index 0000000000..95d659cc0d
--- /dev/null
+++ b/mpsl/pic/timeslot_blocked.svg
@@ -0,0 +1,457 @@
+
+
+
+
diff --git a/mpsl/pic/timeslot_blocked.vsdx b/mpsl/pic/timeslot_blocked.vsdx
new file mode 100644
index 0000000000..bef1df22a0
Binary files /dev/null and b/mpsl/pic/timeslot_blocked.vsdx differ
diff --git a/mpsl/pic/timeslot_canceled.svg b/mpsl/pic/timeslot_canceled.svg
new file mode 100644
index 0000000000..ad8eb21838
--- /dev/null
+++ b/mpsl/pic/timeslot_canceled.svg
@@ -0,0 +1,571 @@
+
+
+
+
diff --git a/mpsl/pic/timeslot_canceled.vsdx b/mpsl/pic/timeslot_canceled.vsdx
new file mode 100644
index 0000000000..0715644908
Binary files /dev/null and b/mpsl/pic/timeslot_canceled.vsdx differ
diff --git a/mpsl/pic/timeslot_extend.svg b/mpsl/pic/timeslot_extend.svg
new file mode 100644
index 0000000000..6286ba8e3d
--- /dev/null
+++ b/mpsl/pic/timeslot_extend.svg
@@ -0,0 +1,348 @@
+
+
+
+
diff --git a/mpsl/pic/timeslot_extend.vsdx b/mpsl/pic/timeslot_extend.vsdx
new file mode 100644
index 0000000000..3df8717c24
Binary files /dev/null and b/mpsl/pic/timeslot_extend.vsdx differ
diff --git a/mpsl/pic/timeslot_normal.svg b/mpsl/pic/timeslot_normal.svg
new file mode 100644
index 0000000000..4e2a8ce455
--- /dev/null
+++ b/mpsl/pic/timeslot_normal.svg
@@ -0,0 +1,577 @@
+
+
+
+
diff --git a/mpsl/pic/timeslot_normal.vsdx b/mpsl/pic/timeslot_normal.vsdx
new file mode 100644
index 0000000000..d15c325ca4
Binary files /dev/null and b/mpsl/pic/timeslot_normal.vsdx differ
diff --git a/mpsl/radio_notification.rst b/mpsl/radio_notification.rst
new file mode 100644
index 0000000000..eca537a2fd
--- /dev/null
+++ b/mpsl/radio_notification.rst
@@ -0,0 +1,38 @@
+.. _mpsl_radio_notification:
+
+Radio notifications
+###################
+
+The radio notification is a configurable feature that enables ACTIVE and INACTIVE (nACTIVE) signals from the MPSL to the application notifying it when timeslot events are active.
+The application can configure how much in advance the ACTIVE signal occurs.
+
+The radio notification signals are sent right before or at the end of an MPSL timeslot activity.
+The timeslot activity may be requested by the application or another user of MPSL.
+To ensure that the radio notification signals behave in a consistent way, the radio notification must always be configured when the MPSL is in an idle state with no active users.
+Therefore, it is recommended to configure the radio notification signals directly after the MPSL has been enabled.
+
+If it is enabled, the ACTIVE signal is sent before the timeslot events starts.
+Similarly, if the nACTIVE signal is enabled, it is sent at the end of the timeslot event.
+These signals can be used by the application developer to synchronize the application logic with the timeslot activity.
+For example, if the application is using the timeslot for radio activity, the ACTIVE signal can be used to switch off external devices to manage peak current drawn during periods when the radio is ON, or to trigger sensor data collection for transmission during the upcoming event.
+
+As both ACTIVE and nACTIVE use the same software interrupt, it is up to the application to manage them.
+If both ACTIVE and nACTIVE are configured ON by the application, there will always be an ACTIVE signal before an nACTIVE signal.
+
+When there is sufficient time between timeslot events, both the ACTIVE and nACTIVE notification signals will be present at each event.
+When there is not sufficient time between the events, the ACTIVE and nACTIVE notification signals will be skipped.
+There will still be an ACTIVE signal before the first event and an nACTIVE signal after the last event.
+
+The following image shows how the ACTIVE and nACTIVE notifications are raised for both when events are far enough apart.
+
+.. figure:: pic/radio_notification_two_events.svg
+ :alt: Notifications raised for ACTIVE and nACTIVE signals
+
+ Notifications raised for both ACTIVE and nACTIVE signals
+
+The following image shows how one pair of ACTIVE and nACTIVE notifications is suppressed when events are placed closer than the configured radio notification distance.
+
+.. figure:: pic/radio_notification_two_events_too_close.svg
+ :alt: Notifications skipped for ACTIVE and nACTIVE signals
+
+ Notifications skipped for ACTIVE and nACTIVE signals
diff --git a/mpsl/radio_notification_two_events.svg b/mpsl/radio_notification_two_events.svg
new file mode 100644
index 0000000000..e68f6750b1
--- /dev/null
+++ b/mpsl/radio_notification_two_events.svg
@@ -0,0 +1,108 @@
+
+
+
+
diff --git a/mpsl/radio_notification_two_events.vsdx b/mpsl/radio_notification_two_events.vsdx
new file mode 100644
index 0000000000..558a8000a5
Binary files /dev/null and b/mpsl/radio_notification_two_events.vsdx differ
diff --git a/mpsl/radio_notification_two_events_too_close.svg b/mpsl/radio_notification_two_events_too_close.svg
new file mode 100644
index 0000000000..689c82bbd7
--- /dev/null
+++ b/mpsl/radio_notification_two_events_too_close.svg
@@ -0,0 +1,90 @@
+
+
+
+
diff --git a/mpsl/radio_notification_two_events_too_close.vsdx b/mpsl/radio_notification_two_events_too_close.vsdx
new file mode 100644
index 0000000000..6c29443a14
Binary files /dev/null and b/mpsl/radio_notification_two_events_too_close.vsdx differ
diff --git a/mpsl/timeslot.rst b/mpsl/timeslot.rst
new file mode 100644
index 0000000000..4b73cdae5f
--- /dev/null
+++ b/mpsl/timeslot.rst
@@ -0,0 +1,232 @@
+.. _mpsl_timeslot:
+
+Timeslot
+########
+
+.. contents::
+ :local:
+ :depth: 2
+
+The Timeslot interface allows developers to implement their own 2.4 GHz proprietary protocol that can be run concurrently with other protocols using the MPSL.
+The Timeslot feature gives the application access to the radio and other restricted peripherals during defined time intervals, denoted as timeslots.
+It can also be used to suppress radio activity and to reserve guaranteed time for application activities with hard timing requirements.
+
+The feature works by having the MPSL time-multiplex access to peripherals between the application and itself.
+MPSL exposes APIs to open a Timeslot session and request timeslots.
+When a Timeslot request is granted, the application has exclusive and real-time access to the following peripherals:
+
+ * TIMER0
+ * TIMER1 for the nRF53 Series
+ * RADIO
+ * TEMP
+ * PPI channel 19 for the nRF52 Series
+ * Other peripherals used by protocol stacks using the MPSL
+
+These peripherals can be used freely for the duration (length) of the timeslot.
+
+Request types
+*************
+There are two types of Timeslot requests, *earliest possible* and *normal* Timeslot requests.
+
+Timeslots may be requested as *earliest possible*, in which case the timeslot occurs at the first available opportunity.
+In the request, the application can limit how far into the future the start of the timeslot can be placed.
+
+.. note:: The first request in a session must always be *earliest possible* to create the timing reference point for later timeslots.
+
+Timeslots may also be requested at a given time (*normal*).
+In this case, the application specifies in the request when the timeslot starts and the time is measured from the start of the previous timeslot.
+
+The application may also request to extend an ongoing timeslot.
+Extension requests may be repeated, prolonging the timeslot even further.
+
+Timeslots requested as *earliest possible* are useful for single timeslots and for non-periodic or non-timed activity.
+Timeslots requested at a given time relative to the previous timeslot are useful for periodic and timed activities, for example, a periodic proprietary radio protocol.
+Timeslot extension can be used to secure as much continuous radio time as possible for the application, for example, running an "always on" radio listener.
+
+Request priorities
+******************
+Timeslots can be requested at either high or normal priority, indicating how important it is for the application to access the specified peripherals.
+A timeslot request can only be blocked or canceled due to an overlapping activity that has a higher scheduling priority.
+
+Timeslot length
+***************
+A timeslot is requested for a given length.
+Ongoing timeslots have the possibility to be extended.
+
+The length of the timeslot is specified by the application.
+Longer continuous timeslots can be achieved by requesting to extend the current timeslot.
+A timeslot can be extended multiple times.
+However, if there are other concurrent protocol activities, the extension might fail.
+The maximum timeslot length is 128 seconds.
+
+Scheduling
+**********
+The MPSL includes a scheduler that manages timeslots and priorities and sets up timers to grant timeslots.
+
+Whether a timeslot request is granted and access to the peripherals is given is determined by the following factors:
+
+* The time the request is made
+* The exact time in the future the timeslot is requested for
+* The desired priority level of the request
+* The length of the requested timeslot
+
+Timeslot API timing-activities are scheduled independently of any other timing activities.
+Therefore, they can collide with any other timing-activities of other protocols.
+If a later arriving timeslot of higher priority causes a collision, the request will be canceled.
+However, a timeslot that has already started cannot be interrupted or canceled.
+
+If the timeslot is requested as earliest possible, it is scheduled at any available free time.
+Therefore, there is less probability of collision with the earliest possible request.
+
+.. note::
+ Radio Notification signals behave the same way for timeslots requested through the timeslot interface as for other activities.
+ See :ref:`mpsl_radio_notification` for more information.
+ If radio notifications are enabled, timeslots will be notified.
+
+High-frequency clock configuration
+**********************************
+The application can request the MPSL to guarantee that the HFCLK source is set to the external crystal and that it is ramped up and stable before the start of the timeslot.
+If the application requests the MPSL to have the external high-frequency crystal ready by the start of the timeslot, the MPSL handles the enabling and disabling of the crystal.
+The application does not need to disable the crystal at the end of the timeslot.
+The MPSL disables the crystal after the end of the timeslot unless the MPSL needs to use it within a short period of time after the end of the timeslot.
+In such case, the MPSL leaves the crystal running.
+
+If the application does not request the MPSL to have the external high-frequency crystal ready by the start of the timeslot,
+then the high-frequency clock might or might not be running during the timeslot.
+
+Performance considerations
+**************************
+The Timeslot API shares core peripherals with the MPSL, and application-requested timeslots are scheduled along with other MPSL activities.
+Therefore, the use of the timeslot feature might influence the performance of other users of MPSL.
+Configurations of other MPSL users, like the :ref:`softdevice_controller`, should be considered when using the timeslot feature.
+
+All timeslot requests should use the lowest priority to minimize disturbances to other activities.
+The high priority should only be used when required, such as for running a radio protocol with certain timing requirements that are not met by using normal priority.
+By using the highest priority available to the Timeslot API, other non-critical radio protocol traffic might be affected.
+Other users of MPSL, like the |controller| might have access to higher priority levels than the application.
+These levels will be used for important radio activity, for instance when the device is about to lose a connection.
+
+Timeslots should be kept as short as possible in order to minimize the impact on the overall performance of the device.
+Requesting a short timeslot makes it easier for the scheduler to fit in between other scheduled activities.
+The timeslot can be later extended.
+This does not affect other sessions, as it is only possible to extend a timeslot if the extended time is unreserved.
+
+It is important to ensure that a timeslot has completed its outstanding operations before the time it is scheduled to end (based on its starting time and requested length).
+Otherwise, the MPSL behavior is undefined and might result in an unrecoverable fault.
+
+Ending a timeslot in time
+*************************
+The application is responsible for keeping track of timing within the timeslot and for ensuring that the application’s use of the peripherals does not last for longer than the granted timeslot length.
+
+For these purposes, the application is granted access to the TIMER0 peripheral for the length of the timeslot.
+This timer is started from zero at the start of the timeslot and is configured to run at 1 MHz.
+The recommended practice is to set up a timer interrupt that expires before the timeslot expires, with enough time left for the timeslot to do any clean-up actions before the timeslot ends.
+Such a timer interrupt can also be used to request an extension of the timeslot, but there must still be enough time to clean up if the extension is not granted.
+
+.. note::
+ The scheduler uses the LFCLK source for time calculations when scheduling events.
+ If the application uses a TIMER (sourced from the current HFCLK source) to calculate and signal the end of a timeslot, it must account for the possible clock drift between the HFCLK source and the LFCLK source.
+
+Signal handler considerations
+*****************************
+
+Depending on the signal type, a signal arrives at interrupt priority level 0, or at the interrupt priority of ``low_prio_irq``.
+Therefore, in order to invoke MPSL APIs inside the signal handler, thread safety must be taken into account.
+
+.. note::
+ Processing of high priority signals cannot exceed the granted time of the timeslot.
+ If it does, the behavior is undefined and the MPSL might malfunction.
+
+API usage scenarios
+===================
+
+In this section, several Timeslot API usage scenarios are provided with descriptions of the sequence of events within them.
+
+Complete session example
+************************
+
+The following figure shows a complete timeslot session.
+In this case, only timeslot requests from the application are being scheduled, and there is no other protocol activity.
+
+1. At start, the application opens a session and requests a first timeslot (which must be of type earliest possible).
+#. The MPSL schedules the timeslot.
+#. At the start of the timeslot, the MPSL calls the application signal handler with the :c:enumerator:`MPSL_TIMESLOT_SIGNAL_START` signal.
+ After this, the application is in control and has access to the peripherals.
+#. The application will then typically set up :c:enumerator:`MPSL_TIMESLOT_SIGNAL_TIMER0` to expire before the end of the timeslot to get a signal indicating that the timeslot is about to end.
+#. In the last signal in the timeslot, the application uses the signal handler return action to request a new timeslot 100 ms after the first.
+
+All subsequent timeslots are similar.
+The signal handler is called with the :c:enumerator:`MPSL_TIMESLOT_SIGNAL_START` signal at the start of the timeslot.
+The application then has control, but must arrange for a signal to come towards the end of the timeslot.
+As the return value for the last signal in the timeslot, the signal handler requests a new timeslot using the :c:enumerator:`MPSL_TIMESLOT_SIGNAL_ACTION_REQUEST` action.
+
+Eventually, the application does not require more timeslot events.
+Therefore, at the last signal in the last timeslot, the application returns END from the signal handler.
+The MPSL then sends an :c:enumerator:`MPSL_TIMESLOT_SIGNAL_SESSION_IDLE` signal to the application signal handler.
+The application calls :c:func:`mpsl_timeslot_session_close`, and the MPSL sends the :c:enumerator:`MPSL_TIMESLOT_SIGNAL_SESSION_CLOSED` signal. The session has now ended.
+
+.. figure:: pic/timeslot_normal.svg
+ :alt: Complete timeslot session
+
+ Complete timeslot session
+
+Blocked scenario
+****************
+
+Timeslot requests might be blocked due to an overlap with activities already scheduled by the MPSL.
+
+.. note::
+ It is possible to issue a timeslot request when getting blocked.
+ However, it is likely that the new request will get blocked as well.
+ This may cause the CPU to become less available for other processing.
+
+The following figure shows a situation in the middle of a session where a requested timeslot cannot be scheduled.
+
+1. At the end of the first timeslot illustrated here, the application signal handler returns a :c:enumerator:`MPSL_TIMESLOT_SIGNAL_ACTION_REQUEST` action to request a new timeslot.
+#. The new timeslot cannot be scheduled as requested because of a collision with an already scheduled activity.
+#. The application is notified about this by an :c:enumerator:`MPSL_TIMESLOT_SIGNAL_BLOCKED` signal to the application signal handler.
+#. The application then makes a new request for a later point in time.
+#. This request succeeds (it does not collide with anything), and a new timeslot is eventually scheduled.
+
+.. figure:: pic/timeslot_blocked.svg
+ :alt: Blocked timeslot example
+
+ Blocked timeslot example
+
+Canceled scenario
+*****************
+
+In certain situations, a requested and scheduled application timeslot might be revoked in the middle of a session.
+
+The following figure shows a situation where a requested and scheduled application timeslot is being revoked.
+
+1. The upper part of the figure shows that the application has ended a timeslot by returning the :c:enumerator:`MPSL_TIMESLOT_SIGNAL_ACTION_REQUEST` action, and that the new timeslot has been scheduled.
+#. The new scheduled timeslot has not started yet, as its starting time is in the future.
+ The lower part of the figure shows the situation some time later.
+#. In the meantime, another higher priority activity has requested time that overlaps with the scheduled application timeslot.
+#. To accommodate the higher priority request, the application timeslot is removed from the schedule and, instead, the higher priority activity is scheduled.
+#. The application is notified about this by an :c:enumerator:`MPSL_TIMESLOT_SIGNAL_CANCELLED` event to the application signal handler.
+#. The application then makes a new request at a later point in time.
+#. That request succeeds (it does not collide with anything), and a new timeslot is eventually scheduled.
+
+.. figure:: pic/timeslot_canceled.svg
+ :alt: Revoked timeslot example
+
+ Revoked timeslot example
+
+Extension example
+*****************
+
+An application can use timeslot extension to create long continuous timeslots that give the application as much time as possible while disturbing other activities as little as possible.
+
+1. In the following figure, the application uses the signal handler return action to request an extension of the timeslot.
+#. The extension is granted, and the timeslot is seamlessly prolonged.
+#. The second attempt to extend the timeslot fails, as a further extension would cause a collision with another scheduled activity.
+#. Therefore, the application makes a new earliest possible request.
+#. This results in a new timeslot being scheduled immediately after the other activity.
+ This new timeslot can be extended a number of times.
+
+.. figure:: pic/timeslot_extend.svg
+ :alt: Extended timeslot example
+
+ Extended timeslot example
diff --git a/mpsl/timeslot_blocked.svg b/mpsl/timeslot_blocked.svg
new file mode 100644
index 0000000000..95d659cc0d
--- /dev/null
+++ b/mpsl/timeslot_blocked.svg
@@ -0,0 +1,457 @@
+
+
+
+
diff --git a/mpsl/timeslot_blocked.vsdx b/mpsl/timeslot_blocked.vsdx
new file mode 100644
index 0000000000..bef1df22a0
Binary files /dev/null and b/mpsl/timeslot_blocked.vsdx differ
diff --git a/mpsl/timeslot_canceled.svg b/mpsl/timeslot_canceled.svg
new file mode 100644
index 0000000000..ad8eb21838
--- /dev/null
+++ b/mpsl/timeslot_canceled.svg
@@ -0,0 +1,571 @@
+
+
+
+
diff --git a/mpsl/timeslot_canceled.vsdx b/mpsl/timeslot_canceled.vsdx
new file mode 100644
index 0000000000..0715644908
Binary files /dev/null and b/mpsl/timeslot_canceled.vsdx differ
diff --git a/mpsl/timeslot_extend.svg b/mpsl/timeslot_extend.svg
new file mode 100644
index 0000000000..6286ba8e3d
--- /dev/null
+++ b/mpsl/timeslot_extend.svg
@@ -0,0 +1,348 @@
+
+
+
+
diff --git a/mpsl/timeslot_extend.vsdx b/mpsl/timeslot_extend.vsdx
new file mode 100644
index 0000000000..3df8717c24
Binary files /dev/null and b/mpsl/timeslot_extend.vsdx differ
diff --git a/mpsl/timeslot_normal.svg b/mpsl/timeslot_normal.svg
new file mode 100644
index 0000000000..4e2a8ce455
--- /dev/null
+++ b/mpsl/timeslot_normal.svg
@@ -0,0 +1,577 @@
+
+
+
+
diff --git a/mpsl/timeslot_normal.vsdx b/mpsl/timeslot_normal.vsdx
new file mode 100644
index 0000000000..d15c325ca4
Binary files /dev/null and b/mpsl/timeslot_normal.vsdx differ
diff --git a/mpsl/tx_power_control.rst b/mpsl/tx_power_control.rst
new file mode 100644
index 0000000000..3a37f575cc
--- /dev/null
+++ b/mpsl/tx_power_control.rst
@@ -0,0 +1,13 @@
+.. _mpsl_tx_power_control:
+
+TX Power Control
+################
+
+The TX Power control feature allows the application to set a maximum TX Power envelope.
+That means that the application can limit the TX power to be used per PHY and per channel.
+Limiting the Radio TX power on edge bands might be necessary to pass teleregulatory requirements when using an external amplifier.
+
+Radio protocols can define their own TX power levels for different types of radio activity.
+However, when utilizing the MPSL TX Power feature, the actual Radio TX Power can be limited.
+
+To ensure that the feature behaves in a consistent way, the TX Power channel maps must always be configured when the MPSL is in an idle state with no active users.
diff --git a/softdevice_controller/CHANGELOG.rst b/softdevice_controller/CHANGELOG.rst
index a2327971dc..6f52863854 100644
--- a/softdevice_controller/CHANGELOG.rst
+++ b/softdevice_controller/CHANGELOG.rst
@@ -9,134 +9,23 @@ Changelog
All the notable changes to this project are documented on this page.
-Main branch
-***********
-
-Added
-=====
-
-* Vendor-specific HCI command to read average RSSI calculated by LE Power Control.
- See :c:func:`sdc_hci_cmd_vs_read_average_rssi` (DRGN-17355).
-* Vendor-specific HCI command to set the time between anchor points of central ACL connections with identical connection intervals.
- See :c:func:`sdc_hci_cmd_vs_central_acl_event_spacing_set` (DRGN-20796).
-* Vendor-specific HCI command to set up (D)PPI tasks on radio events.
- See :c:func:`sdc_hci_cmd_vs_set_conn_event_trigger` (DRGN-20737).
-* Vendor-specific HCI command to read the next connection event counter value.
- See :c:func:`sdc_hci_cmd_vs_get_next_conn_event_counter` (DRGN-20737).
-* Vendor-specific HCI command to allow parallel connection establishment through initiating and periodic advertising with responses.
- See :c:func:`sdc_hci_cmd_vs_allow_parallel_connection_establishments` (DRGN-20823).
-* Vendor-specific HCI command to set the minimum value that will be used as maximum Tx octets for ACL connections.
- See :c:func:`sdc_hci_cmd_vs_min_val_of_max_acl_tx_payload_set` (DRGN-20819).
-
-Changes
-=======
+nRF Connect SDK v2.4.3
+**********************
-* The controller now returns the error code ``0x12`` if the same subevent index is used multiple times in LE Set Periodic Advertising Subevent Data.
- This conforms to erratas ES23466 and ES23424. (DRGN-20736)
-* The vendor-specific Set event length for ACL connections HCI command no longer sets the time between anchor points of central ACL connections with identical connection intervals. (DRGN-20796)
-* The vendor-specific HCI commands :c:func:`sdc_hci_cmd_vs_set_auto_power_control_request_param` and
- :c:func:`sdc_hci_cmd_vs_set_power_control_apr_handling` have been replaced by
- :c:func:`sdc_hci_cmd_vs_set_power_control_request_params` (DRGN-17355).
-* The controller now always returns the error code ``0x0D`` if a connection attempt is made while another is still pending.
- Previously, this wasn't the case if one connection attempt was through periodic advertising with responses while the other was through the initiator. (DRGN-20823)
-* The scheduling priority for initiator events where the scan window is equal to the scan interval is lowered to the third scheduling priority.
- For other configurations of scan window and scan interval the priority is unchanged. (DRGN-20831)
-* The vendor-specific Set event length for ACL connections HCI command now accepts values lower than 1250 us. (DRGN-20796)
+All the notable changes included in the |NCS| v2.4.3 release are documented in this section.
Bug fixes
=========
-* Fixed an issue where the LE Set Periodic Advertising Subevent Data command could fail when providing data at the same time as an ``AUX_SYNC_SUBEVENT_IND`` was sent. (DRGN-20762)
-* Fixed an issue where a packet might not be received when sent at the instant of a Channel Map Update.
- This could happen when acting as Peripheral. (DRGN-20815)
-* Fixed an assert that could happen if the LE Set Periodic Advertising Response Data command was issued more than once without fetching the Command Complete Event. (DRGN-20432)
-* Fixed an issue where the controller would assert during cooperative active scanning or when running a cooperative initiator.
- This could happen when the controller was about to send a scan request or connect indication. (DRGN-20832)
-* Fixed an issue where the controller would assert when initiating a connection to an extended advertiser.
- This could happen when both external radio coexistence and FEM were enabled. (DRGN-16013)
-* Fixed an issue where the nRF5340 DK consumed too much current while scanning.
- This could happen if the controller was running with TX power higher than 0 dB. (DRGN-20862)
-* Fixed an assert that could happen if the Periodic Sync with Responses was terminated. (DRGN-20956)
* Fixed an issue where the controller stopped generating advertising reports.
This could happen when the controller was running an extended cooperative scanner together with other activities, such as advertising or connection,
- while receiving data in an extended advertising event that used ``AUX_CHAIN_IND``. (DRGN-21020)
-
-nRF Connect SDK v2.5.0
-**********************
-
-All the notable changes included in the |NCS| v2.5.0 release are documented in this section.
-
-Added
-=====
-
-* Experimental support for isochronous channels, both Connected Isochronous Streams and Broadcast Isochronous Streams.
- The controller supports an ISO interval equal to the SDU interval, using unframed PDUs.
- The following HCI commands are now supported:
-
- * Read Connection Accept Timeout
- * Write Connection Accept Timeout
- * LE Read Buffer Size [v2]
- * LE Read ISO TX Sync
- * LE Set CIG Parameters
- * LE Set CIG Parameters Test
- * LE Create CIS
- * LE Remove CIG
- * LE Accept CIS Request
- * LE Reject CIS Request
- * LE Create BIG
- * LE Create BIG Test
- * LE Terminate BIG
- * LE BIG Create Sync
- * LE BIG Terminate Sync
- * LE Setup ISO Data Path
- * LE Remove ISO Data Path
- * LE ISO Transmit Test
- * LE ISO Receive Test
- * LE ISO Read Test Counters
- * LE ISO Test End
- * LE Set Host Feature
- * LE Read ISO Link Quality
-
-* Experimental support for the Quality of Service (QoS) channel survey.
- See the :c:func:`sdc_hci_cmd_vs_qos_channel_survey_enable` function.
-* Support for starting the scanner without setting scan parameters.
- Previously the controller would assert (DRGN-17623).
-* Vendor-specific HCI command to enable utilization of remote APR on the local TX power when using LE Power Control.
- See :c:func:`sdc_hci_cmd_vs_set_power_control_apr_handling` (DRGN-17355).
-
-Changes
-=======
-
-* Host now always receives LE Transmit Power Reporting Events.
- Previously, some events might not be received when remote and local power changes were applied to the same PHY simultaneously. (DRGN-18950)
-* :c:func:`sdc_hci_cmd_put` and :c:func:`sdc_hci_cmd_vs_read_supported_vs_commands` functions are removed.
- This change does not affect applications developed in the |NCS| context. (DRGN-19281)
-* When creating a connection or periodic advertiser, the controller will now attempt to select the interval so that it causes as few scheduling conflicts with existing periodic activities as possible.
- The selected interval is always in the range ``[interval_min, interval_max]``, where ``interval_min`` and ``interval_max`` are provided by the host.
- Previously, the controller always selected ``interval_max``.
-* The ``SDC_CFG_TYPE_EVENT_LENGTH`` configuration is removed.
- An application must use the :c:func:`sdc_hci_cmd_vs_event_length_set` HCI command instead.
-* The ChSel bit in a ``CONNECT_IND`` PDU will now match the ChSel bit in the ``ADV_IND`` PDU.
- Previously, this was always set to indicate channel selection algorithm 2. (DRGN-19115)
-* The LE Power Control Request feature is now :ref:`supported ` instead of experimental. (DRGN-17499)
-* :c:func:`sdc_soc_flash_write_async` and :c:func:`sdc_soc_flash_page_erase_async` functions are removed.
- This change does not affect applications developed in the |NCS| context. (DRGN-20451)
-* When synchronizing to a periodic advertiser, the number of events skipped is restricted so that there are at least three opportunities to receive before timing out.
- Previously, only one opportunity to receive was guaranteed before timing out. (DRGN-20448)
-
-Bug fixes
-=========
-
+ while receiving data in an extended advertising event that used ``AUX_CHAIN_IND`` (DRGN-21020).
* Fixed an issue where the continuous extended scanner would not be able to receive the ``AUX_ADV_IND`` packet if the time between the ``ADV_EXT_IND`` and ``AUX_ADV_IND`` was more than 840 μs (DRGN-19460).
-* Fixed an issue where the stack would dereference a NULL pointer when a resolvable :c:enum:`own_address_type` was used in the HCI Le Extended Create Connection V2 command while the resolving list was empty (DRGN-19580).
-* Fixed an issue where the HCI Reset command would not clear the channel map set by the host using the HCI Le Set Host Channel Classification command (DRGN-19623).
-* Fixed a bug where the ``Peer_Address_Type`` parameter in the ``LE Connection Complete`` event was set to ``2`` or ``3`` in case the connection was established to a device whose address was resolved (DRGN-18411).
- The least significant bit of the ``Peer_Address_Type`` parameter was set correctly.
-* Fixed an issue where the stack would assert if trying to set up more advertisers than there are available advertising sets (DRGN-20118).
-* Fixed an issue where enabling an extended advertising set would assert in cases where a host-provided address was not needed and no address had been set up for the advertising set (DRGN-20085).
-* Fixed an issue where the controller acting as a central would assert when receiving a non-compliant LL_PHY_RSP from a peer device (DRGN-20578).
-* Fixed an issue that could occur when the Host Number of Complete Packets command was sent with a connection handle the controller had already raised a disconnect event for.
- The controller would return ``BT_HCI_ERR_INVALID_PARAM`` to the command, which would mean that the host could not return the buffer to the controller (DRGN-20654).
+* Fixed an issue where the controller would stop sending ACL data packets to the host when controller to host flow control was enabled.
+ This could happen when a disconnection occurred before the host had issued the Host Number of Complete Packets command for the remaining ACL data packets.
+ Now the controller waits until after all ACL data packets have been acknowledged by the host before raising the Disconnection Complete event.
+ The controller also validates the handles provided in the Host Number of Complete Packets command (DRGN-21085).
+..Fixed a rare issue where the scanner may assert when it schedules the reception of the next advertising packet (DRGN-21262).
nRF Connect SDK v2.4.0
**********************
@@ -159,8 +48,8 @@ Changes
* The ``VersNr`` field in the ``LL_VERSION_IND`` packet now contains the value 0x0D to indicate compatibility with Bluetooth Core Specification v5.4 (DRGN-18624).
* Receiving a Periodic Advertisement Sync Transfer (PAST) with invalid parameters will now generate the ``LE Periodic Advertising Sync Transfer Received`` event when receiving PAST is enabled (DRGN-18803).
-* Periodic advertiser is allocated from the Periodic Advertising with Responses (PAwR) Advertiser sets when :c:enum:`SDC_CFG_TYPE_PERIODIC_ADV_RSP_COUNT` is available.
- Otherwise, it is allocated from the Periodic Advertiser sets if :c:enum:`SDC_CFG_TYPE_PERIODIC_ADV_COUNT` is set (DRGN-18979).
+* Periodic advertiser is allocated from the Periodic Advertising with Responses (PAwR) Advertiser sets when :c:enumerator:`SDC_CFG_TYPE_PERIODIC_ADV_RSP_COUNT` is available.
+ Otherwise, it is allocated from the Periodic Advertiser sets if :c:enumerator:`SDC_CFG_TYPE_PERIODIC_ADV_COUNT` is set (DRGN-18979).
* The controller now returns the error code ``0x0D`` instead of ``0x09`` if it has insufficient resources to handle more connections and the host tries to start a connectable advertiser or the controller receives the commands ``LE Extended Create Connection`` or ``LE Create Connection`` (DRGN-18944).
* Periodic Advertising with Responses (PAwR) Advertiser is supported (DRGN-18497).
diff --git a/softdevice_controller/README.rst b/softdevice_controller/README.rst
index 3a564eede5..228097d3d0 100644
--- a/softdevice_controller/README.rst
+++ b/softdevice_controller/README.rst
@@ -54,28 +54,14 @@ Variants for the Arm Cortex-M33 processor are available as soft-float only.
| Periodic Advertising with | | | X |
| Responses - Scanner | | | |
+--------------------------------+-----------------+--------------+-----------+
-| Connected Isochronous Stream | | | X |
-| - Central | | | |
-| (experimental support) | | | |
-+--------------------------------+-----------------+--------------+-----------+
-| Connected Isochronous Stream | | | X |
-| - Peripheral | | | |
-| (experimental support) | | | |
-+--------------------------------+-----------------+--------------+-----------+
-| Isochronous Broadcaster | | | X |
-| (experimental support) | | | |
-+--------------------------------+-----------------+--------------+-----------+
-| Synchronized Receiver | | | X |
-| (experimental support) | | | |
-+--------------------------------+-----------------+--------------+-----------+
.. note::
The following limitations apply to the listed features:
* For Connectionless CTE Advertising, angle of arrival (AoA) is supported, but angle of departure (AoD) is not.
* For Connection CTE Response, angle of arrival (AoA) is supported, but angle of departure (AoD) is not.
+ * For the LE Power Control Request feature, the support is experimental.
* For Periodic Advertising Sync Transfer - Receiver, only one sync transfer reception may be in progress at any one time per link.
- * For the Isochronous Channels features, nRF52820 and nRF52833 are the nRF52 Series devices that are supported.
.. _sdc_proprietary_feature_support:
@@ -89,9 +75,6 @@ Proprietary feature support:
| QoS Conn Event Reports | X | X | X | Reports QoS for every connection event. |
| | | | | The application can then set an adapted channel map to avoid busy channels. |
+--------------------------+-----------------+--------------+-----------+-----------------------------------------------------------------------------+
-| QoS Channel Survey | | X | X | Provides measurements of the energy levels on the Bluetooth LE channels. |
-| (experimental support) | | | | The application can then set an adapted channel map to avoid busy channels. |
-+--------------------------+-----------------+--------------+-----------+-----------------------------------------------------------------------------+
.. note::
diff --git a/softdevice_controller/doc/scheduling.rst b/softdevice_controller/doc/scheduling.rst
index 6b1b63e0fd..60ee147c9f 100644
--- a/softdevice_controller/doc/scheduling.rst
+++ b/softdevice_controller/doc/scheduling.rst
@@ -33,6 +33,8 @@ Timing-activities and priorities
The |controller| supports running multiple connections, Advertisers, Scanners, and timeslot events simultaneously.
In |NCS|, flash access is scheduled within MPSL Timeslot events.
+However, the flash access APIs provided by the |controller| are available to the application.
+The flash access mentioned below is covering the implementation provided by the APIs exposed by the |controller|.
Advertiser and broadcaster timing-events are scheduled as early as possible.
Peripheral link timing-events follow the timings dictated by the connected peer, while central link timing-events are added relative to already running central link timing-events.
@@ -56,25 +58,22 @@ The following table summarizes the priorities.
| | * Peripheral connections that are about to time out |
+-----------------------------+---------------------------------------------------------------------------------------------------+
| Second priority | * Central connection setup (waiting for ACK from peer) |
- | | * Initiator when the scan window is not equal to the scan interval |
+ | | * Initiator |
| | * Periodic advertiser sending a channel map update |
- | | * Periodic advertiser sending auxiliary packets (``AUX_SYNC_SUBEVENT_IND``, ``AUX_CONN_REQ``) |
- | | * Periodic advertiser receiving auxiliary packets (``AUX_SYNC_SUBEVENT_RSP``, ``AUX_CONN_RSP``) |
| | * Scanner in the synchronizing state |
| | * Scanner in the synchronized state where the synchronization is about to be lost |
- | | * Scanner in the synchronized state receiving auxiliary packets (``AUX_CHAIN_IND``) |
- | | * Scanner in the synchronized state sending auxiliary packets (``AUX_SYNC_SUBEVENT_RSP``) |
+ | | * Scanner in the synchronized state receiving auxiliary packets (AUX_CHAIN_IND's) |
| | * Connectable Advertiser/Broadcaster which has been blocked consecutively for a few times |
| | * Scanner which has been blocked for a long time |
| | * Scanner which is receiving an advertising packet on a secondary advertising channel |
+-----------------------------+---------------------------------------------------------------------------------------------------+
| Third priority | * All |BLE| roles in states other than above run with this priority |
+ | | * Flash access after it has been blocked consecutively for a few times |
| | * MPSL Timeslot with high priority |
+-----------------------------+---------------------------------------------------------------------------------------------------+
| Fourth priority | * 802.15.4 radio driver |
| | * MPSL Timeslot with normal priority |
- +-----------------------------+---------------------------------------------------------------------------------------------------+
- | Last priority | * Quality of Service channel survey |
+ | | * Flash access |
+-----------------------------+---------------------------------------------------------------------------------------------------+
@@ -533,6 +532,136 @@ Here :math:`\mathsf{C1}` can utilize the free time left by a previously disconne
Multilink scheduling and Connection Event Length Extension
+Flash API timing
+****************
+
+.. note::
+ The Flash API here refers specifically to ``sdc_soc_flash_*`` APIs, which are not used in Zephyr by default.
+
+Flash timing-activity is a one-time activity with no periodicity, as opposed to |BLE| role timing-activities; so the flash timing-event is scheduled in any available time between other timing-events.
+
+To run efficiently with other timing-activities, the Flash API will run in a low priority.
+Other timing-activities running in higher priority can collide with flash timing-events.
+Refer to :ref:`scheduling_priorities_table` for details on priority of timing-activities, which is used when a higher priority activity collides with a Flash timing-event.
+Flash timing-activity will use higher priority if it has been blocked many times by other timing-activities.
+It is possible for a Flash timing-activity to not get a timing-event at all if other timing-events occupy the available time and use a higher priority than the Flash timing-activity.
+To avoid a long wait time while using Flash API, flash timing-activity will fail in case it cannot get a timing-event before a timeout.
+
+The probability of successfully accessing the flash memory decreases with increasing scheduler activity, such as radio and timeslot activity.
+The probability increases with longer connection intervals.
+Use the guidelines in :ref:`behavior_with_le_table` to improve the probability of flash operation success.
+
+A flash write must be made in chunks smaller than or equal to the flash page size.
+Make flash writes in as small chunks as possible to increase the probability of success and reduce the chance of affecting Bluetooth Low Energy performance.
+The table below assumes a flash write size of four bytes.
+LE 1M PHY is assumed unless another PHY is specified.
+
+The time required to do a flash memory operation using the flash memory API depends on which Integrated Circuit (IC) is being used.
+In the table below, a flash page erase is assumed to last for 90 ms.
+
+.. _behavior_with_le_table:
+
+.. table:: Behavior with Bluetooth Low Energy traffic and concurrent flash operation
+
+ +-------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+ | Bluetooth Low Energy activity | Flash operation |
+ +===============================================================================================================================+====================================================================================================================================================================================+
+ | High duty cycle directed advertising. | Does not allow flash operation while advertising is active (maximum 1.28 seconds). |
+ | | In this case, retrying flash operation will only succeed after the advertising activity has finished. |
+ +-------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+ | All possible Bluetooth Low Energy roles running concurrently (connections as a Central, Peripheral, Advertiser, and Scanner). | Low to medium probability of flash operation success. |
+ | | |
+ | | Probability of success increases with: |
+ | | |
+ | | * Configurations with shorter event lengths |
+ | | * Lower data traffic |
+ | | * Increase in connection interval and advertiser interval |
+ | | * Decrease in scan window |
+ | | * Increase in scan interval |
+ +-------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+ | Extended scanner | Medium to high probability of flash operation success. |
+ | | |
+ | | When receiving extended advertising events with secondary channel packets, the scanner cannot choose when the secondary channel timing-events will occur. |
+ | | |
+ | | Probability of success increases with: |
+ | | |
+ | | * Lower secondary channel traffic |
+ | | |
+ | | Probability of success may increase with: |
+ | | |
+ | | * Decrease in scan window |
+ | | * Increase in scan interval |
+ +-------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+ | Extended scannable advertiser with the following configurations: | High probability of flash operation success. |
+ | | |
+ | * 255 bytes of scan response data | |
+ | * Advertising interval ≥ 100 ms | |
+ | * 3 primary advertising channels | |
+ +-------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+ | Extended scannable advertiser with the following configurations: | High probability of flash operation success. |
+ | | |
+ | * LE Coded PHY | |
+ | * 255 bytes of scan response data | |
+ | * Advertising interval ≥ 140 ms | |
+ | * 3 primary advertising channels | |
+ +-------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+ | 8 high bandwidth connections as a Central. | High probability of flash write success. |
+ | | |
+ | 1 high bandwidth connection as a Peripheral. | Medium probability of flash erase success (High probability if the connection interval is > 240 ms). |
+ | | |
+ | All active connections fulfill the following criteria: | |
+ | | |
+ | * Supervision time-out > 6 x connection interval | |
+ | * Connection interval ≥ 150 ms | |
+ | * All central connections have the same connection interval | |
+ +-------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+ | 8 high bandwidth connections as a Central. | High probability of flash write success. |
+ | | |
+ | All active connections fulfill the following criteria: | |
+ | | |
+ | * Supervision time-out > 6 x connection interval | |
+ | * Connection interval ≥ 150 ms | |
+ | * All connections have the same connection interval | |
+ +-------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+ | 8 low bandwidth connections as a Central. | High probability of flash operation success. |
+ | | |
+ | All active connections fulfill the following criteria: | |
+ | | |
+ | * Supervision time-out > 6 x connection interval | |
+ | * Connection interval ≥ 110 ms | |
+ | * All connections have the same connection interval | |
+ +-------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+ | 8 low bandwidth connections on LE Coded PHY as a Central. | High probability of flash operation success. |
+ | | |
+ | All active connections fulfill the following criteria: | |
+ | | |
+ | * Supervision time-out > 6 x connection interval | |
+ | * Connection interval ≥ 150 ms | |
+ | * All connections have the same connection interval | |
+ +-------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+ | 1 connection as a Peripheral. | High probability of flash operation success. |
+ | | |
+ | The active connection fulfills the following criteria: | |
+ | | |
+ | * Supervision time-out > 6 x connection interval | |
+ | * Connection interval ≥ 25 ms | |
+ +-------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+ | 4 connections as a Peripheral. | Medium to high probability of flash operation success. |
+ | | |
+ | All active connections fulfill the following criteria: | The scheduling of connections as Peripheral is done by the peer devices. |
+ | | The Peripheral does not influence this scheduling, which means that the connection events may collide and result in flash operations being blocked. |
+ | * Supervision time-out > 6 x connection interval | With multiple connections as Peripheral, choose connection intervals and connection event lengths in a way that leaves enough free time to handle collisions and other activities. |
+ | * Connection interval ≥ 115 ms | |
+ +-------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+ | | Connectable Undirected Advertising | High probability of flash operation success. |
+ | | Nonconnectable Advertising | |
+ | | Scannable Advertising | |
+ | | Connectable Low Duty Cycle Directed Advertising | |
+ +-------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+ | No Bluetooth Low Energy activity. | Flash operation will always succeed. |
+ +-------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+
+
Timeslot API timing
*******************
@@ -643,7 +772,7 @@ In this case, the connection that schedules events often compared to the Scanner
Three links running as a Central and one Peripheral
-Timing-activities other than |BLE| role events, such as MPSL Timeslot API, also use the same time space as all other timing-activities.
+Timing-activities other than |BLE| role events, such as Flash access and MPSL Timeslot API, also use the same time space as all other timing-activities.
Hence, they will also add up to the worst-case collision scenario.
Dropped packets are possible due to collision between different roles as explained above.
diff --git a/softdevice_controller/doc/softdevice_controller.rst b/softdevice_controller/doc/softdevice_controller.rst
index 0248646ba7..a390869892 100644
--- a/softdevice_controller/doc/softdevice_controller.rst
+++ b/softdevice_controller/doc/softdevice_controller.rst
@@ -73,8 +73,10 @@ Therefore, the host should try to pull data and events until it fails.
Host,Controller;
|||;
Host rbox Controller [label = "Send a command to the controller"];
- Host->Controller [label="sdc_hci_cmd_cb_set_event_mask()"];
- Host<Controller [label="sdc_hci_cmd_put()"];
+ Host<-Controller [label="Host signal is triggered"];
+ Host->Controller [label="sdc_evt_get()"];
+ Host<Controller [label="sdc_hci_data_put()"];
Host<-Controller [label="Host signal is triggered"];
diff --git a/softdevice_controller/include/sdc.h b/softdevice_controller/include/sdc.h
index 5409e849da..c1309b91a9 100644
--- a/softdevice_controller/include/sdc.h
+++ b/softdevice_controller/include/sdc.h
@@ -100,32 +100,8 @@ extern "C" {
/** @brief Default number of devices that can be added to the periodic advertiser list. */
#define SDC_DEFAULT_PERIODIC_ADV_LIST_SIZE 0
-/** @brief Default maximum number of concurrent Connected Isochronous Groups. */
-#define SDC_DEFAULT_CIG_COUNT 0
-
-/** @brief Default maximum number of concurrent Connected Isochronous Streams. */
-#define SDC_DEFAULT_CIS_COUNT 0
-
-/** @brief Default maximum number of concurrent Broadcast Isochronous Groups. */
-#define SDC_DEFAULT_BIG_COUNT 0
-
-/** @brief Default maximum number of concurrent Sink Broadcast Isochronous Streams. */
-#define SDC_DEFAULT_BIS_SINK_COUNT 0
-
-/** @brief Default maximum number of concurrent Source Broadcast Isochronous Streams. */
-#define SDC_DEFAULT_BIS_SOURCE_COUNT 0
-
-/** @brief Default ISO RX PDU buffer per stream count. */
-#define SDC_DEFAULT_ISO_RX_PDU_BUFFER_PER_STREAM_COUNT 0
-
-/** @brief Default ISO RX SDU buffer count. */
-#define SDC_DEFAULT_ISO_RX_SDU_BUFFER_COUNT 0
-
-/** @brief Default HCI ISO TX buffer count. */
-#define SDC_DEFAULT_ISO_TX_HCI_BUFFER_COUNT 0
-
-/** @brief Default ISO TX PDU buffer per stream count. */
-#define SDC_DEFAULT_ISO_TX_PDU_BUFFER_PER_STREAM_COUNT 0
+/** @brief Default connection event length. */
+#define SDC_DEFAULT_EVENT_LENGTH_US 7500UL
/** @brief Size of build revision array in bytes. */
#define SDC_BUILD_REVISION_SIZE 20
@@ -142,8 +118,8 @@ extern "C" {
*/
/** @brief Auxiliary defines, not to be used outside of this file. */
-#define __MEM_MINIMAL_CENTRAL_LINK_SIZE 1101
-#define __MEM_MINIMAL_PERIPHERAL_LINK_SIZE 1248
+#define __MEM_MINIMAL_CENTRAL_LINK_SIZE 1144
+#define __MEM_MINIMAL_PERIPHERAL_LINK_SIZE 1288
#define __MEM_TX_BUFFER_OVERHEAD_SIZE 16
#define __MEM_RX_BUFFER_OVERHEAD_SIZE 14
@@ -193,7 +169,7 @@ extern "C" {
/** @brief Auxiliary defines, not to be used outside of this file. */
#define __MEM_PER_ADV_SET_LOW(max_adv_data) ((4829+(max_adv_data)*18)/10)
#define __MEM_PER_ADV_SET_HIGH(max_adv_data) (670+(max_adv_data))
-#define __MEM_PER_PERIODIC_ADV_SET_LOW(max_adv_data) ((2664+(max_adv_data)*18)/10)
+#define __MEM_PER_PERIODIC_ADV_SET_LOW(max_adv_data) ((2658+(max_adv_data)*18)/10)
#define __MEM_PER_PERIODIC_ADV_SET_HIGH(max_adv_data) (457+(max_adv_data))
/** @brief Maximum required memory for a given advertising buffer size.
@@ -238,9 +214,8 @@ extern "C" {
#define __MEM_PER_PERIODIC_ADV_RSP_TX_BUFFER(max_tx_data_size) ((max_tx_data_size) + 5)
#define __MEM_PER_PERIODIC_ADV_RSP_RX_BUFFER (282)
#define __MEM_MINIMAL_PERIODIC_ADV_RSP_SET_SIZE_WITH_RX (465)
-#define __MEM_MINIMAL_PERIODIC_ADV_RSP_SET_SIZE_WITHOUT_RX (166)
+#define __MEM_MINIMAL_PERIODIC_ADV_RSP_SET_SIZE_WITHOUT_RX (160)
#define __MEM_FOR_PERIODIC_ADV_RSP_FAILURE_REPORTING (224)
-#define __MEM_PER_ISO_PDU_POOL(count) ((count) > 0 ? (16 + (count) * 288) : 0)
/** Memory required per periodic advertising with responses set.
*
@@ -258,44 +233,6 @@ extern "C" {
+ (rx_buffer_count) * __MEM_PER_PERIODIC_ADV_RSP_RX_BUFFER \
+ ((failure_reporting_enabled) ? __MEM_FOR_PERIODIC_ADV_RSP_FAILURE_REPORTING : 0))
-/** Memory required for Quality of Service (QoS) channel survey module. */
-#define SDC_MEM_QOS_CHANNEL_SURVEY (40)
-
-/** @brief Maximum memory required per CIG. */
-#define SDC_MEM_PER_CIG(count) ((count) > 0 ? (13 + (count) * 123) : 0)
-
-/** @brief Maximum memory required per CIS. Buffer and CIG memory comes in addition. */
-#define SDC_MEM_PER_CIS(count) ((count) > 0 ? (13 + (count) * 523) : 0)
-
-/** @brief Maximum memory required per BIG. */
-#define SDC_MEM_PER_BIG(count) ((count) > 0 ? (13 + (count) * 291) : 0)
-
-/** @brief Maximum memory required per BIS. Buffer and BIG memory comes in addition. */
-#define SDC_MEM_PER_BIS(count) ((count) > 0 ? (13 + (count) * 275) : 0)
-
-/** @brief Maximum memory required for the ISO RX PDU pool per stream.
- * @param[in] rx_pdu_buffer_per_stream_count Number of RX PDU buffers allocated for each BIS or CIS stream. Minimum of 1.
- * For BIS, this value determines the number of pretransmission that can be stored.
- * @param[in] cis_count The number of supported CIS streams.
- * @param[in] bis_sink_count The number of supported sink BIS streams. */
-#define SDC_MEM_ISO_RX_PDU_POOL_PER_STREAM_SIZE(rx_pdu_buffer_per_stream_count, cis_count, bis_sink_count) \
- (__MEM_PER_ISO_PDU_POOL(rx_pdu_buffer_per_stream_count) * ((cis_count) + (bis_sink_count)))
-
-/** @brief Maximum memory required for the ISO RX path SDUs. */
-#define SDC_MEM_ISO_RX_SDU_POOL_SIZE(count) ((count) > 0 ? (8 + (count) * 272) : 0)
-
-/** @brief Maximum memory required for the ISO TX pool.
- * @param[in] tx_hci_buffer_count Number of HCI ISO TX buffers.
- * @param[in] tx_pdu_buffer_per_stream_count Number of TX PDU buffers allocated for each BIS or CIS stream. Minimum of 1.
- * For BIS, this value determines the maximum supported pretransmission offset.
- * @param[in] cis_count The number of supported CIS streams.
- * @param[in] bis_source_count The number of supported source BIS streams. */
-#define SDC_MEM_ISO_TX_POOL_SIZE(tx_hci_buffer_count, tx_pdu_buffer_per_stream_count, cis_count, bis_source_count) \
- (((tx_hci_buffer_count) > 0 && (tx_pdu_buffer_per_stream_count) > 0) ? \
- (__MEM_PER_ISO_PDU_POOL(tx_hci_buffer_count) \
- + (__MEM_PER_ISO_PDU_POOL(tx_pdu_buffer_per_stream_count) * ((cis_count) + (bis_source_count))) \
- ) : 0)
-
/** @} end of sdc_mem_defines */
/** @brief Function prototype for the fault handler.
@@ -327,6 +264,8 @@ enum sdc_cfg_type
SDC_CFG_TYPE_PERIPHERAL_COUNT,
/** See @ref sdc_cfg_t::buffer_cfg. */
SDC_CFG_TYPE_BUFFER_CFG,
+ /** See @ref sdc_cfg_t::event_length. */
+ SDC_CFG_TYPE_EVENT_LENGTH,
/** See @ref sdc_cfg_t::adv_count. */
SDC_CFG_TYPE_ADV_COUNT,
/** See @ref sdc_cfg_t::scan_buffer_cfg. */
@@ -351,22 +290,6 @@ enum sdc_cfg_type
SDC_CFG_TYPE_PERIODIC_ADV_RSP_FAILURE_REPORTING_CFG,
/** See @ref sdc_cfg_t::periodic_sync_rsp_tx_buffer_cfg. */
SDC_CFG_TYPE_PERIODIC_SYNC_RSP_TX_BUFFER_CFG,
- /** See @ref sdc_cfg_t::cig_count. */
- SDC_CFG_TYPE_CIG_COUNT,
- /** See @ref sdc_cfg_t::cis_count. */
- SDC_CFG_TYPE_CIS_COUNT,
- /** See @ref sdc_cfg_t::big_count. */
- SDC_CFG_TYPE_BIG_COUNT,
- /** See @ref sdc_cfg_t::bis_sink_count. */
- SDC_CFG_TYPE_BIS_SINK_COUNT,
- /** See @ref sdc_cfg_t::bis_source_count. */
- SDC_CFG_TYPE_BIS_SOURCE_COUNT,
- /** See @ref sdc_cfg_t::iso_rx_pdu_buffer_per_stream_cfg. */
- SDC_CFG_TYPE_ISO_RX_PDU_BUFFER_PER_STREAM_CFG,
- /** See @ref sdc_cfg_t::iso_rx_sdu_buffer_cfg. */
- SDC_CFG_TYPE_ISO_RX_SDU_BUFFER_CFG,
- /** See @ref sdc_cfg_t::iso_tx_buffer_cfg. */
- SDC_CFG_TYPE_ISO_TX_BUFFER_CFG,
};
@@ -391,6 +314,13 @@ typedef struct
} sdc_cfg_buffer_cfg_t;
+/** @brief Connection event length configuration. */
+typedef struct
+{
+ uint32_t event_length_us; /**< Maximum connection event length */
+} sdc_cfg_event_length_t;
+
+
/** @brief Buffer count configuration. */
typedef struct
{
@@ -410,7 +340,6 @@ typedef struct
uint16_t max_adv_data;
} sdc_cfg_adv_buffer_cfg_t;
-
typedef struct
{
/** Configures the size of the buffer pool allocated to each periodic
@@ -434,24 +363,6 @@ typedef struct
uint8_t rx_buffer_count;
} sdc_cfg_periodic_adv_rsp_buffer_cfg_t;
-
-typedef struct
-{
- /** Configures the size of the shared HCI TX buffer pool allocated for ISO.
- *
- * Default: @ref SDC_DEFAULT_ISO_TX_HCI_BUFFER_COUNT.
- */
- uint8_t tx_hci_buffer_count;
- /** Configures the number of TX buffers allocated per ISO stream.
- *
- * @note For BIS, this value determines the maximum supported pretransmission offset.
- *
- * Default: @ref SDC_DEFAULT_ISO_TX_PDU_BUFFER_PER_STREAM_COUNT.
- */
- uint8_t tx_pdu_buffer_per_stream_count;
-} sdc_cfg_iso_tx_buffer_cfg_t;
-
-
/** @brief SoftDevice Controller configuration. */
typedef union
{
@@ -467,6 +378,10 @@ typedef union
* Default: See @ref sdc_cfg_buffer_cfg_t.
*/
sdc_cfg_buffer_cfg_t buffer_cfg;
+ /** Max connection event length.
+ * Default: @ref SDC_DEFAULT_EVENT_LENGTH_US.
+ */
+ sdc_cfg_event_length_t event_length;
/** Max number of concurrent advertisers.
* Must be more than or equal to @ref sdc_cfg_t::periodic_adv_count.
* Default: @ref SDC_DEFAULT_ADV_COUNT.
@@ -550,46 +465,6 @@ typedef union
* Default: @ref SDC_DEFAULT_PERIODIC_SYNC_RSP_TX_BUFFER_COUNT.
*/
sdc_cfg_buffer_count_t periodic_sync_rsp_tx_buffer_cfg;
- /** Configures the maximum number of concurrent CIGs.
- *
- * Default: @ref SDC_DEFAULT_CIG_COUNT.
- */
- sdc_cfg_role_count_t cig_count;
- /** Configures the maximum number of concurrent CISs.
- *
- * Default: @ref SDC_DEFAULT_CIS_COUNT.
- */
- sdc_cfg_role_count_t cis_count;
- /** Configures the maximum number of concurrent BIGs.
- *
- * Default: @ref SDC_DEFAULT_BIG_COUNT.
- */
- sdc_cfg_role_count_t big_count;
- /** Configures the maximum number of concurrent sink BISs.
- *
- * Default: @ref SDC_DEFAULT_BIS_SINK_COUNT.
- */
- sdc_cfg_role_count_t bis_sink_count;
- /** Configures the maximum number of concurrent source BISs.
- *
- * Default: @ref SDC_DEFAULT_BIS_SOURCE_COUNT.
- */
- sdc_cfg_role_count_t bis_source_count;
- /** Configures the size of the per stream RX PDU buffer pool allocated for ISO streams.
- *
- * Default: @ref SDC_DEFAULT_ISO_RX_PDU_BUFFER_PER_STREAM_COUNT.
- */
- sdc_cfg_buffer_count_t iso_rx_pdu_buffer_per_stream_cfg;
- /** Configures the RX SDU buffer count allocated for ISO.
- *
- * Default: @ref SDC_DEFAULT_ISO_RX_SDU_BUFFER_COUNT.
- */
- sdc_cfg_buffer_count_t iso_rx_sdu_buffer_cfg;
- /** Configures the size and number of TX buffer pools allocated for ISO.
- *
- * Default: See @ref sdc_cfg_iso_tx_buffer_cfg_t.
- */
- sdc_cfg_iso_tx_buffer_cfg_t iso_tx_buffer_cfg;
} sdc_cfg_t;
@@ -1072,60 +947,6 @@ int32_t sdc_support_periodic_adv_sync_transfer_receiver_central(void);
*/
int32_t sdc_support_periodic_adv_sync_transfer_receiver_peripheral(void);
-/** @brief Support Connected Isochronous streams in the peripheral role
- *
- * After this API is called, the controller will support the HCI commands
- * related to Connected Isochronous channels in the peripheral role
- *
- * @retval 0 Success
- * @retval -NRF_EPERM This API must be called before @ref sdc_cfg_set() or @ref sdc_enable().
- * @retval -NRF_EOPNOTSUPP Connected Isochronous streams in the peripheral role is not supported.
- */
-int32_t sdc_support_cis_peripheral(void);
-
-/** @brief Support Connected Isochronous streams in the central role
- *
- * After this API is called, the controller will support the HCI commands
- * related to Connected Isochronous channels in the central role
- *
- * @retval 0 Success
- * @retval -NRF_EPERM This API must be called before @ref sdc_cfg_set() or @ref sdc_enable().
- * @retval -NRF_EOPNOTSUPP Connected Isochronous streams in the central role is not supported.
- */
-int32_t sdc_support_cis_central(void);
-
-/** @brief Support Broadcast Isochronous streams as a source
- *
- * After this API is called, the controller will support the HCI commands
- * related to Broadcast Isochronous channels as a source
- *
- * @retval 0 Success
- * @retval -NRF_EPERM This API must be called before @ref sdc_cfg_set() or @ref sdc_enable().
- * @retval -NRF_EOPNOTSUPP Broadcast Isochronous streams as a source is not supported.
- */
-int32_t sdc_support_bis_source(void);
-
-/** @brief Support Broadcast Isochronous streams as a sink
- *
- * After this API is called, the controller will support the HCI commands
- * related to Broadcast Isochronous channels as a sink
- *
- * @retval 0 Success
- * @retval -NRF_EPERM This API must be called before @ref sdc_cfg_set() or @ref sdc_enable().
- * @retval -NRF_EOPNOTSUPP Broadcast Isochronous streams as a sink is not supported.
- */
-int32_t sdc_support_bis_sink(void);
-
-/** @brief Support for Quality of Service (QoS) channel survey module
- *
- * After this API is called, the controller will support the @ref sdc_hci_cmd_vs_qos_channel_survey_enable HCI command
- *
- * @retval 0 Success
- * @retval -NRF_EPERM This API must be called before @ref sdc_cfg_set() or @ref sdc_enable().
- * @retval -NRF_EOPNOTSUPP QoS channel survey is not supported.
- */
-int32_t sdc_support_qos_channel_survey(void);
-
/** @brief Configure the coex advertising mode
*
* Configure how the advertiser behaves on denial of an advertising packet.
diff --git a/softdevice_controller/include/sdc_hci.h b/softdevice_controller/include/sdc_hci.h
index 3085053f6a..5462939c00 100644
--- a/softdevice_controller/include/sdc_hci.h
+++ b/softdevice_controller/include/sdc_hci.h
@@ -68,34 +68,29 @@ typedef enum
{
SDC_HCI_MSG_TYPE_DATA = 0x02,
SDC_HCI_MSG_TYPE_EVT = 0x04,
- SDC_HCI_MSG_TYPE_ISO = 0x08,
} sdc_hci_msg_type_t;
-/** @brief Send an HCI data packet to the SoftDevice Controller.
+/** @brief Send an HCI command packet to the SoftDevice Controller.
*
- * @param[in] p_data_in HCI Data packet. The first byte in the buffer should correspond to
- * Handle, as specified by the Bluetooth Core Specification.
+ * @param[in] p_cmd_in HCI Command packet. The first byte in the buffer should correspond to
+ * OpCode, as specified by the Bluetooth Core Specification.
*
* @retval 0 Success
* @retval -NRF_EINVAL Invalid input
*/
-int32_t sdc_hci_data_put(uint8_t const * p_data_in);
+int32_t sdc_hci_cmd_put(uint8_t const * p_cmd_in);
-/** @brief Send an HCI ISO data packet to the SoftDevice Controller.
- *
- * If an error is returned, the HCI ISO data packet is dropped by the SoftDevice Controller and will not be
- * further processed.
+
+/** @brief Send an HCI data packet to the SoftDevice Controller.
*
* @param[in] p_data_in HCI Data packet. The first byte in the buffer should correspond to
* Handle, as specified by the Bluetooth Core Specification.
*
* @retval 0 Success
* @retval -NRF_EINVAL Invalid input
- * @retval -NRF_EPERM There is no data-path for the selected Handle
- * @retval -NRF_EAGAIN The data is provided too late
- * @retval -NRF_EFAULT Failure during processing of the data
*/
-int32_t sdc_hci_iso_data_put(uint8_t const * p_data_in);
+int32_t sdc_hci_data_put(uint8_t const * p_data_in);
+
/** @brief Retrieve an HCI packet from the SoftDevice Controller.
*
diff --git a/softdevice_controller/include/sdc_hci_cmd_controller_baseband.h b/softdevice_controller/include/sdc_hci_cmd_controller_baseband.h
index 8b965c45f7..1ed4ebc9c7 100644
--- a/softdevice_controller/include/sdc_hci_cmd_controller_baseband.h
+++ b/softdevice_controller/include/sdc_hci_cmd_controller_baseband.h
@@ -39,10 +39,6 @@ enum sdc_hci_opcode_cb
SDC_HCI_OPCODE_CMD_CB_SET_EVENT_MASK = 0xc01,
/** @brief See @ref sdc_hci_cmd_cb_reset(). */
SDC_HCI_OPCODE_CMD_CB_RESET = 0xc03,
- /** @brief See @ref sdc_hci_cmd_cb_read_conn_accept_timeout(). */
- SDC_HCI_OPCODE_CMD_CB_READ_CONN_ACCEPT_TIMEOUT = 0xc15,
- /** @brief See @ref sdc_hci_cmd_cb_write_conn_accept_timeout(). */
- SDC_HCI_OPCODE_CMD_CB_WRITE_CONN_ACCEPT_TIMEOUT = 0xc16,
/** @brief See @ref sdc_hci_cmd_cb_read_transmit_power_level(). */
SDC_HCI_OPCODE_CMD_CB_READ_TRANSMIT_POWER_LEVEL = 0xc2d,
/** @brief See @ref sdc_hci_cmd_cb_set_controller_to_host_flow_control(). */
@@ -173,18 +169,6 @@ typedef __PACKED_UNION
uint8_t raw[8];
} sdc_hci_cmd_cb_set_event_mask_t;
-/** @brief Read Connection Accept Timeout return parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint16_t conn_accept_timeout;
-} sdc_hci_cmd_cb_read_conn_accept_timeout_return_t;
-
-/** @brief Write Connection Accept Timeout command parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint16_t conn_accept_timeout;
-} sdc_hci_cmd_cb_write_conn_accept_timeout_t;
-
/** @brief Read Transmit Power Level command parameter(s). */
typedef __PACKED_STRUCT
{
@@ -321,46 +305,6 @@ uint8_t sdc_hci_cmd_cb_set_event_mask(const sdc_hci_cmd_cb_set_event_mask_t * p_
*/
uint8_t sdc_hci_cmd_cb_reset(void);
-/** @brief Read Connection Accept Timeout.
- *
- * The description below is extracted from Core_v5.4,
- * Vol 4, Part E, Section 7.3.13
- *
- * This command reads the value for the Connection_Accept_Timeout
- * configuration parameter. See Section 6.7.
- *
- * Event(s) generated (unless masked away):
- * When the HCI_Read_Connection_Timeout command has completed, an
- * HCI_Command_Complete event shall be generated.
- *
- * @param[out] p_return Extra return parameters.
- *
- * @retval 0 if success.
- * @return Returns value between 0x01-0xFF in case of error.
- * See Vol 2, Part D, Error for a list of error codes and descriptions.
- */
-uint8_t sdc_hci_cmd_cb_read_conn_accept_timeout(sdc_hci_cmd_cb_read_conn_accept_timeout_return_t * p_return);
-
-/** @brief Write Connection Accept Timeout.
- *
- * The description below is extracted from Core_v5.4,
- * Vol 4, Part E, Section 7.3.14
- *
- * This command writes the value for the Connection_Accept_Timeout
- * configuration parameter. See Section 6.7.
- *
- * Event(s) generated (unless masked away):
- * When the HCI_Write_Connection_Accept_Timeout command has completed,
- * an HCI_Command_Complete event shall be generated.
- *
- * @param[in] p_params Input parameters.
- *
- * @retval 0 if success.
- * @return Returns value between 0x01-0xFF in case of error.
- * See Vol 2, Part D, Error for a list of error codes and descriptions.
- */
-uint8_t sdc_hci_cmd_cb_write_conn_accept_timeout(const sdc_hci_cmd_cb_write_conn_accept_timeout_t * p_params);
-
/** @brief Read Transmit Power Level.
*
* The description below is extracted from Core_v5.4,
diff --git a/softdevice_controller/include/sdc_hci_cmd_le.h b/softdevice_controller/include/sdc_hci_cmd_le.h
index 5d0e4fe208..defd3e7f93 100644
--- a/softdevice_controller/include/sdc_hci_cmd_le.h
+++ b/softdevice_controller/include/sdc_hci_cmd_le.h
@@ -189,50 +189,8 @@ enum sdc_hci_opcode_le
SDC_HCI_OPCODE_CMD_LE_SET_PERIODIC_ADV_SYNC_TRANSFER_PARAMS = 0x205c,
/** @brief See @ref sdc_hci_cmd_le_set_default_periodic_adv_sync_transfer_params(). */
SDC_HCI_OPCODE_CMD_LE_SET_DEFAULT_PERIODIC_ADV_SYNC_TRANSFER_PARAMS = 0x205d,
- /** @brief See @ref sdc_hci_cmd_le_read_buffer_size_v2(). */
- SDC_HCI_OPCODE_CMD_LE_READ_BUFFER_SIZE_V2 = 0x2060,
- /** @brief See @ref sdc_hci_cmd_le_read_iso_tx_sync(). */
- SDC_HCI_OPCODE_CMD_LE_READ_ISO_TX_SYNC = 0x2061,
- /** @brief See @ref sdc_hci_cmd_le_set_cig_params(). */
- SDC_HCI_OPCODE_CMD_LE_SET_CIG_PARAMS = 0x2062,
- /** @brief See @ref sdc_hci_cmd_le_set_cig_params_test(). */
- SDC_HCI_OPCODE_CMD_LE_SET_CIG_PARAMS_TEST = 0x2063,
- /** @brief See @ref sdc_hci_cmd_le_create_cis(). */
- SDC_HCI_OPCODE_CMD_LE_CREATE_CIS = 0x2064,
- /** @brief See @ref sdc_hci_cmd_le_remove_cig(). */
- SDC_HCI_OPCODE_CMD_LE_REMOVE_CIG = 0x2065,
- /** @brief See @ref sdc_hci_cmd_le_accept_cis_request(). */
- SDC_HCI_OPCODE_CMD_LE_ACCEPT_CIS_REQUEST = 0x2066,
- /** @brief See @ref sdc_hci_cmd_le_reject_cis_request(). */
- SDC_HCI_OPCODE_CMD_LE_REJECT_CIS_REQUEST = 0x2067,
- /** @brief See @ref sdc_hci_cmd_le_create_big(). */
- SDC_HCI_OPCODE_CMD_LE_CREATE_BIG = 0x2068,
- /** @brief See @ref sdc_hci_cmd_le_create_big_test(). */
- SDC_HCI_OPCODE_CMD_LE_CREATE_BIG_TEST = 0x2069,
- /** @brief See @ref sdc_hci_cmd_le_terminate_big(). */
- SDC_HCI_OPCODE_CMD_LE_TERMINATE_BIG = 0x206a,
- /** @brief See @ref sdc_hci_cmd_le_big_create_sync(). */
- SDC_HCI_OPCODE_CMD_LE_BIG_CREATE_SYNC = 0x206b,
- /** @brief See @ref sdc_hci_cmd_le_big_terminate_sync(). */
- SDC_HCI_OPCODE_CMD_LE_BIG_TERMINATE_SYNC = 0x206c,
/** @brief See @ref sdc_hci_cmd_le_request_peer_sca(). */
SDC_HCI_OPCODE_CMD_LE_REQUEST_PEER_SCA = 0x206d,
- /** @brief See @ref sdc_hci_cmd_le_setup_iso_data_path(). */
- SDC_HCI_OPCODE_CMD_LE_SETUP_ISO_DATA_PATH = 0x206e,
- /** @brief See @ref sdc_hci_cmd_le_remove_iso_data_path(). */
- SDC_HCI_OPCODE_CMD_LE_REMOVE_ISO_DATA_PATH = 0x206f,
- /** @brief See @ref sdc_hci_cmd_le_iso_transmit_test(). */
- SDC_HCI_OPCODE_CMD_LE_ISO_TRANSMIT_TEST = 0x2070,
- /** @brief See @ref sdc_hci_cmd_le_iso_receive_test(). */
- SDC_HCI_OPCODE_CMD_LE_ISO_RECEIVE_TEST = 0x2071,
- /** @brief See @ref sdc_hci_cmd_le_iso_read_test_counters(). */
- SDC_HCI_OPCODE_CMD_LE_ISO_READ_TEST_COUNTERS = 0x2072,
- /** @brief See @ref sdc_hci_cmd_le_iso_test_end(). */
- SDC_HCI_OPCODE_CMD_LE_ISO_TEST_END = 0x2073,
- /** @brief See @ref sdc_hci_cmd_le_set_host_feature(). */
- SDC_HCI_OPCODE_CMD_LE_SET_HOST_FEATURE = 0x2074,
- /** @brief See @ref sdc_hci_cmd_le_read_iso_link_quality(). */
- SDC_HCI_OPCODE_CMD_LE_READ_ISO_LINK_QUALITY = 0x2075,
/** @brief See @ref sdc_hci_cmd_le_enhanced_read_transmit_power_level(). */
SDC_HCI_OPCODE_CMD_LE_ENHANCED_READ_TRANSMIT_POWER_LEVEL = 0x2076,
/** @brief See @ref sdc_hci_cmd_le_read_remote_transmit_power_level(). */
@@ -257,32 +215,6 @@ enum sdc_hci_opcode_le
SDC_HCI_OPCODE_CMD_LE_SET_PERIODIC_ADV_PARAMS_V2 = 0x2086,
};
-/** @brief Advertising Event Properties parameters. */
-typedef __PACKED_STRUCT
-{
- uint16_t connectable_adv : 1;
- uint16_t scannable_adv : 1;
- uint16_t directed_adv : 1;
- uint16_t high_duty_cycle_adv : 1;
- uint16_t legacy_adv_packets : 1;
- uint16_t omit_adv_address : 1;
- uint16_t include_tx_power : 1;
- uint16_t rfu : 9;
-} sdc_hci_le_adv_event_properties_params_t;
-
-/** @brief LE BIG Create Sync array parameters. */
-typedef __PACKED_STRUCT
-{
- uint8_t bis;
-} sdc_hci_le_big_create_sync_array_params_t;
-
-/** @brief LE Create CIS array parameters. */
-typedef __PACKED_STRUCT
-{
- uint16_t cis_conn_handle;
- uint16_t acl_conn_handle;
-} sdc_hci_le_create_cis_array_params_t;
-
/** @brief LE Extended Create Connection [v1] array parameters. */
typedef __PACKED_STRUCT
{
@@ -412,54 +344,6 @@ typedef __PACKED_STRUCT
uint8_t periodic_advertising_with_responses_scanner : 1;
} sdc_hci_le_le_features_t;
-/** @brief Options parameters for HCI_LE_Periodic_Advertising_Create_Sync command. */
-typedef __PACKED_STRUCT
-{
- uint8_t use_periodic_adv_list : 1;
- uint8_t disable_reporting : 1;
- uint8_t duplicate_filter_initially_enabled : 1;
- uint8_t rfu : 5;
-} sdc_hci_le_periodic_adv_create_sync_options_params_t;
-
-/** @brief LE Set CIG Parameters array parameters. */
-typedef __PACKED_STRUCT
-{
- uint8_t cis_id;
- uint16_t max_sdu_c_to_p;
- uint16_t max_sdu_p_to_c;
- uint8_t phy_c_to_p;
- uint8_t phy_p_to_c;
- uint8_t rtn_c_to_p;
- uint8_t rtn_p_to_c;
-} sdc_hci_le_set_cig_params_array_params_t;
-
-/** @brief LE Set CIG Parameters output array parameters. */
-typedef __PACKED_STRUCT
-{
- uint16_t conn_handle;
-} sdc_hci_le_set_cig_params_output_array_params_t;
-
-/** @brief LE Set CIG Parameters Test array parameters. */
-typedef __PACKED_STRUCT
-{
- uint8_t cis_id;
- uint8_t nse;
- uint16_t max_sdu_c_to_p;
- uint16_t max_sdu_p_to_c;
- uint16_t max_pdu_c_to_p;
- uint16_t max_pdu_p_to_c;
- uint8_t phy_c_to_p;
- uint8_t phy_p_to_c;
- uint8_t bn_c_to_p;
- uint8_t bn_p_to_c;
-} sdc_hci_le_set_cig_params_test_array_params_t;
-
-/** @brief LE Set CIG Parameters Test output array parameters. */
-typedef __PACKED_STRUCT
-{
- uint16_t conn_handle;
-} sdc_hci_le_set_cig_params_test_output_array_params_t;
-
/** @brief LE Set Connection CTE Transmit Parameters array parameters. */
typedef __PACKED_STRUCT
{
@@ -472,14 +356,6 @@ typedef __PACKED_STRUCT
uint8_t antenna_ids;
} sdc_hci_le_set_connless_cte_transmit_params_array_params_t;
-/** @brief Change Reasons parameters for HCI_LE_Set_Data_Related_Address_Changes command. */
-typedef __PACKED_STRUCT
-{
- uint8_t change_on_adv_data_change : 1;
- uint8_t change_on_scan_response_data_change : 1;
- uint8_t rfu : 6;
-} sdc_hci_le_set_data_related_address_changes_reasons_params_t;
-
/** @brief LE Set Extended Advertising Enable array parameters. */
typedef __PACKED_STRUCT
{
@@ -496,22 +372,6 @@ typedef __PACKED_STRUCT
uint16_t scan_window;
} sdc_hci_le_set_ext_scan_params_array_params_t;
-/** @brief Enable parameters for HCI_LE_Set_Periodic_Advertising_Enable command. */
-typedef __PACKED_STRUCT
-{
- uint8_t enable : 1;
- uint8_t include_adi : 1;
- uint8_t rfu : 6;
-} sdc_hci_le_set_periodic_adv_enable_params_t;
-
-/** @brief Enable parameters for HCI_LE_Set_Periodic_Advertising_Receive_Enable command. */
-typedef __PACKED_STRUCT
-{
- uint8_t enable_reporting : 1;
- uint8_t enable_duplicate_filtering : 1;
- uint8_t rfu : 6;
-} sdc_hci_le_set_periodic_adv_receive_enable_params_t;
-
/** @brief LE Set Periodic Advertising Subevent Data array parameters. */
typedef __PACKED_STRUCT
{
@@ -522,6 +382,12 @@ typedef __PACKED_STRUCT
uint8_t subevent_data[];
} sdc_hci_le_set_periodic_adv_subevent_data_array_params_t;
+/** @brief LE Set Periodic Sync Subevent array parameters. */
+typedef __PACKED_STRUCT
+{
+ uint8_t subevent;
+} sdc_hci_le_set_periodic_sync_subevent_array_params_t;
+
/** @} end of HCI_TYPES */
/**
@@ -866,12 +732,9 @@ typedef __PACKED_STRUCT
typedef __PACKED_STRUCT
{
uint8_t adv_handle;
- __PACKED_UNION {
- sdc_hci_le_adv_event_properties_params_t params;
- uint8_t raw[2];
- } adv_event_properties;
- uint32_t primary_adv_interval_min : 24;
- uint32_t primary_adv_interval_max : 24;
+ uint16_t adv_event_properties;
+ uint8_t primary_adv_interval_min[3];
+ uint8_t primary_adv_interval_max[3];
uint8_t primary_adv_channel_map;
uint8_t own_address_type;
uint8_t peer_address_type;
@@ -958,10 +821,7 @@ typedef __PACKED_STRUCT
/** @brief LE Set Periodic Advertising Enable command parameter(s). */
typedef __PACKED_STRUCT
{
- __PACKED_UNION {
- sdc_hci_le_set_periodic_adv_enable_params_t params;
- uint8_t raw[1];
- } enable;
+ uint8_t enable;
uint8_t adv_handle;
} sdc_hci_cmd_le_set_periodic_adv_enable_t;
@@ -997,10 +857,7 @@ typedef __PACKED_STRUCT
/** @brief LE Periodic Advertising Create Sync command parameter(s). */
typedef __PACKED_STRUCT
{
- __PACKED_UNION {
- sdc_hci_le_periodic_adv_create_sync_options_params_t params;
- uint8_t raw[1];
- } options;
+ uint8_t options;
uint8_t adv_sid;
uint8_t adv_address_type;
uint8_t adv_address[6];
@@ -1125,10 +982,7 @@ typedef __PACKED_STRUCT
typedef __PACKED_STRUCT
{
uint16_t sync_handle;
- __PACKED_UNION {
- sdc_hci_le_set_periodic_adv_receive_enable_params_t params;
- uint8_t raw[1];
- } enable;
+ uint8_t enable;
} sdc_hci_cmd_le_set_periodic_adv_receive_enable_t;
/** @brief LE Periodic Advertising Sync Transfer command parameter(s). */
@@ -1184,304 +1038,12 @@ typedef __PACKED_STRUCT
uint8_t cte_type;
} sdc_hci_cmd_le_set_default_periodic_adv_sync_transfer_params_t;
-/** @brief LE Read Buffer Size [v2] return parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint16_t le_acl_data_packet_length;
- uint8_t total_num_le_acl_data_packets;
- uint16_t iso_data_packet_length;
- uint8_t total_num_iso_data_packets;
-} sdc_hci_cmd_le_read_buffer_size_v2_return_t;
-
-/** @brief LE Read ISO TX Sync command parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint16_t conn_handle;
-} sdc_hci_cmd_le_read_iso_tx_sync_t;
-
-/** @brief LE Read ISO TX Sync return parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint16_t conn_handle;
- uint16_t packet_sequence_number;
- uint32_t tx_time_stamp;
- uint32_t time_offset : 24;
-} sdc_hci_cmd_le_read_iso_tx_sync_return_t;
-
-/** @brief LE Set CIG Parameters command parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint8_t cig_id;
- uint32_t sdu_interval_c_to_p : 24;
- uint32_t sdu_interval_p_to_c : 24;
- uint8_t worst_case_sca;
- uint8_t packing;
- uint8_t framing;
- uint16_t max_transport_latency_c_to_p;
- uint16_t max_transport_latency_p_to_c;
- uint8_t cis_count;
- sdc_hci_le_set_cig_params_array_params_t array_params[];
-} sdc_hci_cmd_le_set_cig_params_t;
-
-/** @brief LE Set CIG Parameters return parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint8_t cig_id;
- uint8_t cis_count;
- sdc_hci_le_set_cig_params_output_array_params_t array_params[];
-} sdc_hci_cmd_le_set_cig_params_return_t;
-
-/** @brief LE Set CIG Parameters Test command parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint8_t cig_id;
- uint32_t sdu_interval_c_to_p : 24;
- uint32_t sdu_interval_p_to_c : 24;
- uint8_t ft_c_to_p;
- uint8_t ft_p_to_c;
- uint16_t iso_interval;
- uint8_t worst_case_sca;
- uint8_t packing;
- uint8_t framing;
- uint8_t cis_count;
- sdc_hci_le_set_cig_params_test_array_params_t array_params[];
-} sdc_hci_cmd_le_set_cig_params_test_t;
-
-/** @brief LE Set CIG Parameters Test return parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint8_t cig_id;
- uint8_t cis_count;
- sdc_hci_le_set_cig_params_test_output_array_params_t array_params[];
-} sdc_hci_cmd_le_set_cig_params_test_return_t;
-
-/** @brief LE Create CIS command parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint8_t cis_count;
- sdc_hci_le_create_cis_array_params_t array_params[];
-} sdc_hci_cmd_le_create_cis_t;
-
-/** @brief LE Remove CIG command parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint8_t cig_id;
-} sdc_hci_cmd_le_remove_cig_t;
-
-/** @brief LE Remove CIG return parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint8_t cig_id;
-} sdc_hci_cmd_le_remove_cig_return_t;
-
-/** @brief LE Accept CIS Request command parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint16_t conn_handle;
-} sdc_hci_cmd_le_accept_cis_request_t;
-
-/** @brief LE Reject CIS Request command parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint16_t conn_handle;
- uint8_t reason;
-} sdc_hci_cmd_le_reject_cis_request_t;
-
-/** @brief LE Reject CIS Request return parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint16_t conn_handle;
-} sdc_hci_cmd_le_reject_cis_request_return_t;
-
-/** @brief LE Create BIG command parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint8_t big_handle;
- uint8_t adv_handle;
- uint8_t num_bis;
- uint32_t sdu_interval : 24;
- uint16_t max_sdu;
- uint16_t max_transport_latency;
- uint8_t rtn;
- uint8_t phy;
- uint8_t packing;
- uint8_t framing;
- uint8_t encryption;
- uint8_t broadcast_code[16];
-} sdc_hci_cmd_le_create_big_t;
-
-/** @brief LE Create BIG Test command parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint8_t big_handle;
- uint8_t adv_handle;
- uint8_t num_bis;
- uint32_t sdu_interval : 24;
- uint16_t iso_interval;
- uint8_t nse;
- uint16_t max_sdu;
- uint16_t max_pdu;
- uint8_t phy;
- uint8_t packing;
- uint8_t framing;
- uint8_t bn;
- uint8_t irc;
- uint8_t pto;
- uint8_t encryption;
- uint8_t broadcast_code[16];
-} sdc_hci_cmd_le_create_big_test_t;
-
-/** @brief LE Terminate BIG command parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint8_t big_handle;
- uint8_t reason;
-} sdc_hci_cmd_le_terminate_big_t;
-
-/** @brief LE BIG Create Sync command parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint8_t big_handle;
- uint16_t sync_handle;
- uint8_t encryption;
- uint8_t broadcast_code[16];
- uint8_t mse;
- uint16_t big_sync_timeout;
- uint8_t num_bis;
- sdc_hci_le_big_create_sync_array_params_t array_params[];
-} sdc_hci_cmd_le_big_create_sync_t;
-
-/** @brief LE BIG Terminate Sync command parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint8_t big_handle;
-} sdc_hci_cmd_le_big_terminate_sync_t;
-
-/** @brief LE BIG Terminate Sync return parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint8_t big_handle;
-} sdc_hci_cmd_le_big_terminate_sync_return_t;
-
/** @brief LE Request Peer SCA command parameter(s). */
typedef __PACKED_STRUCT
{
uint16_t conn_handle;
} sdc_hci_cmd_le_request_peer_sca_t;
-/** @brief LE Setup ISO Data Path command parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint16_t conn_handle;
- uint8_t data_path_direction;
- uint8_t data_path_id;
- uint8_t codec_id[5];
- uint32_t controller_delay : 24;
- uint8_t codec_config_length;
- uint8_t codec_config[];
-} sdc_hci_cmd_le_setup_iso_data_path_t;
-
-/** @brief LE Setup ISO Data Path return parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint16_t conn_handle;
-} sdc_hci_cmd_le_setup_iso_data_path_return_t;
-
-/** @brief LE Remove ISO Data Path command parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint16_t conn_handle;
- uint8_t data_path_direction;
-} sdc_hci_cmd_le_remove_iso_data_path_t;
-
-/** @brief LE Remove ISO Data Path return parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint16_t conn_handle;
-} sdc_hci_cmd_le_remove_iso_data_path_return_t;
-
-/** @brief LE ISO Transmit Test command parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint16_t conn_handle;
- uint8_t payload_type;
-} sdc_hci_cmd_le_iso_transmit_test_t;
-
-/** @brief LE ISO Transmit Test return parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint16_t conn_handle;
-} sdc_hci_cmd_le_iso_transmit_test_return_t;
-
-/** @brief LE ISO Receive Test command parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint16_t conn_handle;
- uint8_t payload_type;
-} sdc_hci_cmd_le_iso_receive_test_t;
-
-/** @brief LE ISO Receive Test return parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint16_t conn_handle;
-} sdc_hci_cmd_le_iso_receive_test_return_t;
-
-/** @brief LE ISO Read Test Counters command parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint16_t conn_handle;
-} sdc_hci_cmd_le_iso_read_test_counters_t;
-
-/** @brief LE ISO Read Test Counters return parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint16_t conn_handle;
- uint32_t received_sdu_count;
- uint32_t missed_sdu_count;
- uint32_t failed_sdu_count;
-} sdc_hci_cmd_le_iso_read_test_counters_return_t;
-
-/** @brief LE ISO Test End command parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint16_t conn_handle;
-} sdc_hci_cmd_le_iso_test_end_t;
-
-/** @brief LE ISO Test End return parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint16_t conn_handle;
- uint32_t received_sdu_count;
- uint32_t missed_sdu_count;
- uint32_t failed_sdu_count;
-} sdc_hci_cmd_le_iso_test_end_return_t;
-
-/** @brief LE Set Host Feature command parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint8_t bit_number;
- uint8_t bit_value;
-} sdc_hci_cmd_le_set_host_feature_t;
-
-/** @brief LE Read ISO Link Quality command parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint16_t conn_handle;
-} sdc_hci_cmd_le_read_iso_link_quality_t;
-
-/** @brief LE Read ISO Link Quality return parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint16_t conn_handle;
- uint32_t tx_unacked_packets;
- uint32_t tx_flushed_packets;
- uint32_t tx_last_subevent_packets;
- uint32_t retransmitted_packets;
- uint32_t crc_error_packets;
- uint32_t rx_unreceived_packets;
- uint32_t duplicate_packets;
-} sdc_hci_cmd_le_read_iso_link_quality_return_t;
-
/** @brief LE Enhanced Read Transmit Power Level command parameter(s). */
typedef __PACKED_STRUCT
{
@@ -1553,10 +1115,7 @@ typedef __PACKED_STRUCT
typedef __PACKED_STRUCT
{
uint8_t adv_handle;
- __PACKED_UNION {
- sdc_hci_le_set_data_related_address_changes_reasons_params_t params;
- uint8_t raw[1];
- } change_reasons;
+ uint8_t change_reasons;
} sdc_hci_cmd_le_set_data_related_address_changes_t;
/** @brief LE Set Periodic Advertising Subevent Data command parameter(s). */
@@ -1597,7 +1156,7 @@ typedef __PACKED_STRUCT
uint16_t sync_handle;
uint16_t periodic_adv_properties;
uint8_t num_subevents;
- uint8_t subevents[];
+ sdc_hci_le_set_periodic_sync_subevent_array_params_t array_params[];
} sdc_hci_cmd_le_set_periodic_sync_subevent_t;
/** @brief LE Set Periodic Sync Subevent return parameter(s). */
@@ -5204,1043 +4763,36 @@ uint8_t sdc_hci_cmd_le_set_periodic_adv_sync_transfer_params(const sdc_hci_cmd_l
*/
uint8_t sdc_hci_cmd_le_set_default_periodic_adv_sync_transfer_params(const sdc_hci_cmd_le_set_default_periodic_adv_sync_transfer_params_t * p_params);
-/** @brief LE Read Buffer Size [v2].
+/** @brief LE Request Peer SCA.
*
* The description below is extracted from Core_v5.4,
- * Vol 4, Part E, Section 7.8.2
- *
- * This command is used to read the maximum size of the data portion of ACL
- * data packets and isochronous data packets sent from the Host to the Control-
- * ler. The Host shall segment the data transmitted to the Controller according to
- * these values so that the HCI ACL Data packets and HCI ISO Data packets will
- * contain data up to this size (“data” includes optional fields in the HCI ISO Data
- * packet, such as ISO_SDU_Length). The HCI_LE_Read_Buffer_Size
- * command also returns the total number of HCI LE ACL Data packets and iso-
- * chronous data packets that can be stored in the data buffers of the Controller.
- * The HCI_LE_Read_Buffer_Size command shall be issued by the Host before it
- * sends any data to an LE Controller (see Section 4.1.1). If the Controller sup-
- * ports HCI ISO Data packets, it shall return non-zero values for the ISO_Data_-
- * Packet_Length and Total_Num_ISO_Data_Packets parameters.
- *
- * If the Controller returns a length value of zero for ACL data packets, the Host
- * shall use the HCI_Read_Buffer_Size command to determine the size of the
- * data buffers (shared between BR/EDR and LE transports).
- *
- * Note: Both the HCI_Read_Buffer_Size command and the HCI_LE_Read_-
- * Buffer_Size command may return buffer length and number of packets param-
- * eter values that are nonzero. This allows a Controller to offer different buffers
- * and number of buffers for BR/EDR data packets and LE data packets.
- *
- * The LE_ACL_Data_Packet_Length return parameter shall be used to deter-
- * mine the maximum size of the L2CAP PDU segments that are contained in
- * ACL data packets, and which are transferred from the Host to the Controller to
- * be broken up into packets by the Link Layer. The Total_Num_LE_ACL_Data_-
- * Packets return parameter contains the total number of HCI ACL Data packets
- * that can be stored in the data buffers of the Controller. The Host determines
- * how to divide the buffers between different connection handles.
- *
- * The ISO_Data_Packet_Length return parameter shall be used to determine the
- * maximum size of the SDU segments that are contained in isochronous data
- * packets, and which are transferred from the Host to the Controller. The
- * Total_Num_ISO_Data_Packets return parameter contains the total number of
- * isochronous data packets that can be stored in the data buffers of the
- * Controller. The Host determines how to divide the buffers between different
- * connection handle(s).
- *
- * Note: The LE_ACL_Data_Packet_Length and ISO_Data_Packet_Length
- * return parameters do not include the length of the HCI ACL Data packet header
- * or the HCI ISO Data packet header respectively.
- *
- * Event(s) generated (unless masked away):
- * When the HCI_LE_Read_Buffer_Size command has completed, an
- * HCI_Command_Complete event shall be generated.
- *
- * @param[out] p_return Extra return parameters.
- *
- * @retval 0 if success.
- * @return Returns value between 0x01-0xFF in case of error.
- * See Vol 2, Part D, Error for a list of error codes and descriptions.
- */
-uint8_t sdc_hci_cmd_le_read_buffer_size_v2(sdc_hci_cmd_le_read_buffer_size_v2_return_t * p_return);
-
-/** @brief LE Read ISO TX Sync.
- *
- * The description below is extracted from Core_v5.3,
- * Vol 4, Part E, Section 7.8.96
- *
- * This command is used to read the TX_Time_Stamp and Time_Offset of a
- * transmitted SDU identified by the Packet_Sequence_Number on a CIS or BIS
- * identified by the Connection_Handle parameter on the Central or Peripheral.
+ * Vol 4, Part E, Section 7.8.108
*
- * The Packet_Sequence_Number parameter contains the sequence number of a
- * transmitted SDU.
+ * This command is used to read the Sleep Clock Accuracy (SCA) of the peer
+ * device.
*
- * The TX_Time_Stamp and Time_Offset parameters are described in [Vol 6] Part
- * G, Section 3.3 and [Vol 6] Part G, Section 3.1 respectively. When the
- * Connection_Handle identifies a CIS or BIS that is transmitting unframed PDUs,
- * the value of Time_Offset returned shall be zero.
+ * The Connection_Handle parameter is the connection handle of the ACL
+ * connection.
*
- * If the Host issues this command with a connection handle that does not exist,
- * or the connection handle is not associated with a CIS or BIS, the Controller
- * shall return the error code Unknown Connection Identifier (0x02).
+ * If the Host sends this command with a Connection_Handle that does not exist,
+ * or the Connection_Handle is not for an ACL the Controller shall return the error
+ * code Unknown Connection Identifier (0x02).
*
- * If the Host issues this command on an existing connection handle for a CIS or
- * BIS that is not configured for transmitting SDUs, the Controller shall return the
- * error code Command Disallowed (0x0C).
+ * If the Host sends this command and the peer device does not support the
+ * Sleep Clock Accuracy Updates feature, the Controller shall return the error
+ * code Unsupported Feature or Parameter Value (0x11) in the HCI_LE_-
+ * Request_Peer_SCA_Complete event.
*
- * If the Host issues this command before an SDU has been transmitted by the
- * Controller, the Controller shall return the error code Command Disallowed
- * (0x0C).
+ * If the Host issues this command when the Controller is aware (e.g., through a
+ * previous feature exchange) that the peer device's Link Layer does not support
+ * the Sleep Clock Accuracy Updates feature, the Controller shall return the error
+ * code Unsupported Remote Feature (0x1A).
*
* Event(s) generated (unless masked away):
- * When the HCI_LE_Read_ISO_TX_Sync command has completed, an
- * HCI_Command_Complete event shall be generated.
- *
- * @param[in] p_params Input parameters.
- * @param[out] p_return Extra return parameters.
- *
- * @retval 0 if success.
- * @return Returns value between 0x01-0xFF in case of error.
- * See Vol 2, Part D, Error for a list of error codes and descriptions.
- */
-uint8_t sdc_hci_cmd_le_read_iso_tx_sync(const sdc_hci_cmd_le_read_iso_tx_sync_t * p_params,
- sdc_hci_cmd_le_read_iso_tx_sync_return_t * p_return);
-
-/** @brief LE Set CIG Parameters.
- *
- * The description below is extracted from Core_v5.4,
- * Vol 4, Part E, Section 7.8.97
- *
- * The HCI_LE_Set_CIG_Parameters command is used by a Central'’s Host to
- * create a CIG and to set the parameters of one or more CISes that are
- * associated with a CIG in the Controller.
- *
- * The CIG_ID parameter identifies a CIG. This parameter is allocated by the
- * Central's Host and passed to the Peripheral's Host through the Link Layers
- * during the process of creating a CIS. If the CIG_ID does not exist, then the
- * Controller shall first create a new CIG. Once the CIG is created (whether
- * through this command or previously), the Controller shall modify or add CIS
- * configurations in the CIG that is identified by the CIG_ID and update all the
- * parameters that apply to the CIG.
- *
- * The SDU_Interval_C_To_P parameter specifies the time interval between the
- * start of consecutive SDUs from the Central's Host for all the CISes in the CIG.
- * This parameter shall be ignored for all CISes that are unidirectional from
- * Peripheral to Central.
- *
- * The SDU_Interval_P_To_C parameter specifies the time interval between the
- * start of consecutive SDUs from the Peripheral's Host for all the CISes in the
- * CIG. This parameter shall be ignored for all CISes that are unidirectional from
- * Central to Peripheral.
- * The Worst_Case_SCA parameter shall be the worst-case sleep clock accuracy
- * of all the Peripherals that will participate in the CIG. The Host should get the
- * sleep clock accuracy from all the Peripherals before issuing this command. If
- * the Host cannot get the sleep clock accuracy from all the Peripherals, it shall
- * set the Worst_Case_SCA parameter to zero.
- *
- * Note: The Worst_Case_SCA parameter can be used by the Link Layer to
- * better allow for clock drift when scheduling the CISes in the CIG. For example,
- * if a CIS has more than two subevents, the Link Layer of the Central can set the
- * timing of the subevents such that the worst case drift in the Peripheral's clock
- * will not exceed 2 × Sub_Interval. This prevents the Peripheral from
- * synchronizing its timing to the wrong subevent (adjacent subevents cannot be
- * on the same channel).
- *
- * The Packing parameter indicates the preferred method of arranging subevents
- * of multiple CISes. The subevents can be arranged in Sequential or Interleaved
- * arrangement (see [Vol 6] Part B, Section 4.5.14.2). This is a recommendation
- * to the Controller which the Controller may ignore. This parameter shall be
- * ignored when there is only one CIS in the CIG.
- *
- * The Framing parameter indicates the format of the CIS Data PDUs of the
- * specified CISes. If the Framing parameter is set to 1 then the CIS Data PDUs
- * of the specified CISes shall be framed. If the Framing parameter is set to 0 the
- * CIS Data PDUs of a given CIS may be either unframed or framed (determined
- * separately for each specified CIS) (see [Vol 6] Part G, Section 1).
- *
- * The Max_Transport_Latency_C_To_P parameter contains the maximum
- * transport latency from the Central to the Peripheral, in milliseconds, as
- * described in [Vol 6] Part G, Section 3.2.1 and [Vol 6] Part G, Section 3.2.2. This
- * parameter shall be ignored for all CISes that are unidirectional from Peripheral
- * to Central.
- *
- * The Max_Transport_Latency_P_To_C parameter contains the maximum
- * transport latency from the Peripheral to the Central, in milliseconds, as
- * described in [Vol 6] Part G, Section 3.2.1 and [Vol 6] Part G, Section 3.2.2. This
- * parameter shall be ignored for all CISes that are unidirectional from Central to
- * Peripheral.
- *
- * The CIS_Count parameter indicates the number of CIS configurations being
- * modified or added by this command. The Controller shall set the CIS_Count
- * return parameter equal to this.
- *
- * The CIS_ID[i] parameter identifies a CIS and is set by the Central’s Host and
- * passed to the Peripheral’s Host through the Link Layers during the process of
- * establishing a CIS.
- *
- * The Max_SDU_C_To_P[i] parameter identifies the maximum size of an SDU
- * from the Central’s Host. If the CIS is unidirectional from Peripheral to Central,
- * this parameter shall be set to 0. If a CIS configuration that is being modified
- * has a data path set in the Central to Peripheral direction and the Host has
- * specified that Max_SDU_C_To_P[i] shall be set to zero, the Controller shall
- * return the error code Command Disallowed (0x0C).
- *
- * The Max_SDU_P_To_C[i] parameter identifies the maximum size of an SDU
- * from the Peripheral's Host. If the CIS is unidirectional from Central to
- * Peripheral, this parameter shall be set to 0. If a CIS configuration that is being
- * modified has a data path set in the Peripheral to Central direction and the Host
- * has specified that Max_SDU_P_To_C[i] shall be set to zero, the Controller
- * shall return the error code Command Disallowed (0x0C).
- *
- * The PHY_C_To_P[i] parameter identifies which PHY to use for transmission
- * from the Central to the Peripheral. The Host shall set at least one bit in this
- * parameter and the Controller shall pick a PHY from the bits that are set.
- *
- * The PHY_P_To_C[i] parameter identifies which PHY to use for transmission
- * from the Peripheral to the Central. The Host shall set at least one bit in this
- * parameter and the Controller shall pick a PHY from the bits that are set.
- *
- * The RTN_C_To_P[i] (Retransmission Number) parameter contains the number
- * of times that a CIS Data PDU should be retransmitted from the Central to
- * Peripheral before being acknowledged or flushed (irrespective of which CIS
- * events the retransmission opportunities occur in). If the CIS is unidirectional
- * from Peripheral to Central, this parameter shall be ignored. Otherwise, this
- * parameter is a recommendation to the Controller which the Controller may
- * ignore.
- *
- * The RTN_P_To_C[i] parameter contains the number of times that a CIS Data
- * PDU should be retransmitted from the Peripheral to Central before being
- * acknowledged or flushed (irrespective of which CIS events the retransmission
- * opportunities occur in). If the CIS is unidirectional from Central to Peripheral,
- * this parameter shall be ignored. Otherwise, this parameter is a
- * recommendation to the Controller which the Controller may ignore.
- *
- * In each direction, if the Controller satisfies the recommendation, then every
- * PDU will have at least RTN+1 opportunities for transmission (assuming that the
- * initial transmission of that PDU happens at the earliest allowed subevent). The
- * RTN value indicates that the Host is recommending that the Controller selects
- * a combination of CIS parameters that satisfy the inequality:
- *
- * NSE * FT - NSE ÷ BN * ( BN - 1 ) ≥ RTN + 1
- *
- * If the Status return parameter is non-zero, then the state of the CIG and its CIS
- * configurations shall not be changed by the command. If the CIG did not already
- * exist, it shall not be created.
- *
- * If the Status return parameter is zero, then the Controller shall set the
- * Connection_Handle arrayed return parameter to the connection handle(s)
- * corresponding to the CIS configurations specified in the CIS_IDs command
- * parameter, in the same order. If the same CIS_ID is being reconfigured, the
- * same connection handle shall be returned.
- * The connection handle of a CIS shall refer to the CIS when it exists and to the
- * configuration of the CIS stored in a CIG when the CIG exists but the CIS with
- * that CIS_ID does not.
- *
- * If the Host issues this command when the CIG is not in the configurable state,
- * the Controller shall return the error code Command Disallowed (0x0C).
- *
- * If the Host attempts to create a CIG or set parameters that exceed the
- * maximum supported resources in the Controller, the Controller shall return the
- * error code Memory Capacity Exceeded (0x07).
- *
- * If the Host attempts to set CIS parameters that exceed the maximum
- * supported connections in the Controller, the Controller shall return the error
- * code Connection Limit Exceeded (0x09).
- *
- * If the Host sets, in the PHY_C_To_P[i] or PHY_P_To_C[i] parameters, a bit for
- * a PHY that the Controller does not support, including a bit that is reserved for
- * future use, the Controller shall return the error code Unsupported Feature or
- * Parameter Value (0x11).
- *
- * If the Controller does not support asymmetric PHYs and the Host sets
- * PHY_C_To_P[i] to a different value than PHY_P_To_C[i], the Controller shall
- * return the error code Unsupported Feature or Parameter Value (0x11).
- *
- * If the Host specifies an invalid combination of CIS parameters, the Controller
- * shall return the error code Invalid HCI Command Parameters (0x12) or the
- * error code Unsupported Feature or Parameter Value (0x11); it should return
- * the error code Invalid HCI Command Parameters (0x12).
- *
- * Event(s) generated (unless masked away):
- * When the HCI_LE_Set_CIG_Parameters command has completed, an
- * HCI_Command_Complete event shall be generated.
- *
- * @param[in] p_params Input parameters.
- * @param[out] p_return Extra return parameters.
- *
- * @retval 0 if success.
- * @return Returns value between 0x01-0xFF in case of error.
- * See Vol 2, Part D, Error for a list of error codes and descriptions.
- */
-uint8_t sdc_hci_cmd_le_set_cig_params(const sdc_hci_cmd_le_set_cig_params_t * p_params,
- sdc_hci_cmd_le_set_cig_params_return_t * p_return);
-
-/** @brief LE Set CIG Parameters Test.
- *
- * The description below is extracted from Core_v5.4,
- * Vol 4, Part E, Section 7.8.98
- *
- * The HCI_LE_Set_CIG_Parameters_Test command should only be used for
- * testing purposes.
- *
- * The command is used by a Central's Host to create a CIG and to set the
- * parameters of one or more CISes that are associated with a CIG in the
- * Controller.
- *
- * The CIG_ID parameter identifies a CIG. This parameter is allocated by the
- * Central's Host and passed to the Peripheral's Host through the Link Layers
- * during the process of creating a CIS. If the CIG_ID does not exist, then the
- * Controller shall first create a new CIG. Once the CIG is created (whether
- * through this command or previously), the Controller shall modify or add CIS
- * configurations in the CIG that is identified by the CIG_ID and update all the
- * parameters that apply to the CIG.
- *
- * The SDU_Interval_C_To_P parameter specifies the time interval of periodic
- * SDUs from the Central's Host.
- * The SDU_Interval_P_To_C parameter specifies the time interval of periodic
- * SDUs from the Peripheral's Host.
- *
- * The FT_C_To_P parameter identifies the maximum time for a payload from the
- * Central to Peripheral to be transmitted and re-transmitted, after which it is
- * flushed (see [Vol 6] Part B, Section 4.5.13.5). This parameter is expressed in
- * multiples of ISO_Interval.
- *
- * The FT_P_To_C parameter identifies the maximum time for a payload from the
- * Peripheral to Central to be transmitted and re-transmitted, after which it is
- * flushed (see[Vol 6] Part B, Section 4.5.13.5). This parameter is expressed in
- * multiples of ISO_Interval.
- *
- * The ISO_Interval parameter specifies the time between two consecutive CIS
- * anchor points.
- *
- * The CIS_Count parameter contains the number of CIS configurations being
- * added or modified by this command. The Controller shall set the CIS_Count
- * return parameter equal to this.
- *
- * The CIS_ID[i] parameter identifies the CIS and is set by the Central's Host and
- * passed to the Peripheral's Host through the Link Layers during the process of
- * establishing a CIS.
- *
- * The Worst_Case_SCA parameter is the worst-case sleep clock accuracy of all
- * the Peripherals that will participate in the CIG. The Host should get the sleep
- * clock accuracy from all the Peripherals before issuing this command. In case
- * the Host cannot get the sleep clock accuracy from all the Peripherals, it shall
- * set the Worst_Case_SCA parameter to zero.
- *
- * Note: The Worst_Case_SCA parameter can be used by the Link Layer to
- * better allow for clock drift when scheduling the CISes in the CIG. For example,
- * if a CIS has more than two subevents, the Link Layer of the Central can set the
- * timing of the subevents such that the worst case drift in the Peripheral's clock
- * will not exceed 2 × Sub_Interval. This prevents the Peripheral from
- * synchronizing its timing to the wrong subevent (adjacent subevents cannot be
- * on the same channel).
- *
- * The Packing parameter is used to indicate the preferred method of arranging
- * subevents of multiple CISes. The subevents can be arranged in Sequential or
- * Interleaved arrangement. This is a recommendation to the Controller which it
- * may ignore. This parameter shall be ignored when there is only one CIS in the
- * CIG.
- *
- * The Framing parameter indicates the format of the CIS Data PDUs of all the
- * CISes. If the Framing parameter is set to 1 then the CIS Data PDUs of the
- * specified CISes shall be framed, and when set to 0 they shall be unframed (see
- * [Vol 6] Part G, Section 1).
- *
- * The CIS_ID[i] parameter is used to identify a CIS.
- * The NSE[i] parameter identifies the maximum number of subevents for each
- * CIS in a CIG event.
- *
- * The Max_SDU_C_To_P[i] parameter identifies the maximum size of SDU from
- * the Central’s Host. If the CIS is unidirectional from Peripheral to Central, this
- * parameter shall be set to 0. If a CIS configuration that is being modified has a
- * data path set in the Central to Peripheral direction and the Host has specified
- * that Max_SDU_C_To_P[i] shall be set to zero, the Controller shall return the
- * error code Command Disallowed (0x0C). The minimum value of the
- * Max_SDU_Size parameter in the ISO Transmit Test mode when the
- * Payload_Type = 1 or 2 shall be 4 octets.
- *
- * The Max_SDU_P_To_C[i] parameter identifies the maximum size of SDU from
- * the Peripheral’s Host. If the CIS is unidirectional from Central to Peripheral, this
- * parameter shall be set to 0. If a CIS configuration that is being modified has a
- * data path set in the Peripheral to Central direction and the Host has specified
- * that Max_SDU_P_To_C[i] shall be set to zero, the Controller shall return the
- * error code Command Disallowed (0x0C).The minimum value of the Max_SDU
- * parameter in the ISO Transmit Test mode when the Payload_Type = 1 or 2
- * shall be 4 octets.
- *
- * The Max_PDU_C_To_P[i] parameter identifies the maximum size PDU from
- * the Central to Peripheral.
- *
- * The Max_PDU_P_To_C[i] parameter identifies the maximum size PDU from
- * the Peripheral to Central.
- *
- * The PHY_C_To_P[i] parameter identifies the PHY to be used for transmission
- * of packets from the Central to the Peripheral. The Host shall set only one bit in
- * this parameter and the Controller shall use the PHY set by the Host.
- *
- * The PHY_P_To_C[i] parameter identifies the PHY to be used for transmission
- * of packets from the Peripheral to the Central. The Host shall set only one bit in
- * this parameter and the Controller shall use the PHY set by the Host.
- *
- * The BN_C_To_P[i] parameter identifies the burst number for Central to
- * Peripheral (see [Vol 6] Part B, Section 4.5.13). If the CIS is unidirectional from
- * Peripheral to Central, this parameter shall be set to zero.
- *
- * The BN_P_To_C[i] parameter identifies the burst number for Peripheral to
- * Central (see [Vol 6] Part B, Section 4.5.13). If the CIS is unidirectional from
- * Central to Peripheral, this parameter shall be set to zero.
- *
- * If the Status return parameter is non-zero, then the state of the CIG and its CIS
- * configurations shall not be changed by the command. If the CIG did not already
- * exist, it shall not be created.
- *
- * If the Status return parameter is zero, then the Controller shall set the
- * Connection_Handle arrayed return parameter to the connection handle(s)
- * corresponding to the CIS configurations specified in the CIS_IDs command
- * parameter, in the same order. If the same CIS_ID is being reconfigured, the
- * same connection handle shall be returned.
- *
- * If the Host issues this command when the CIG is not in the configurable state,
- * the Controller shall return the error code Command Disallowed (0x0C).
- *
- * If the Host attempts to create a CIG or set parameters that exceed the
- * maximum supported resources in the Controller, the Controller shall return the
- * error code Memory Capacity Exceeded (0x07).
- *
- * If the Host attempts to set CIS parameters that exceed the maximum
- * supported connections in the Controller, the Controller shall return the error
- * code Connection Limit Exceeded (0x09).
- *
- * If the Host attempts to set an invalid combination of CIS parameters, the
- * Controller shall return the error code Invalid HCI Command Parameters (0x12)
- * or the error code Unsupported Feature or Parameter Value (0x11); it should
- * return the error code Invalid HCI Command Parameters (0x12).
- *
- * If the Host sets, in the PHY_C_To_P[i] or PHY_P_To_C[i] parameters, a bit for
- * a PHY that the Controller does not support, including a bit that is reserved for
- * future use, the Controller shall return the error code Unsupported Feature or
- * Parameter Value (0x11).
- *
- * If the Controller does not support asymmetric PHYs and the Host sets
- * PHY_C_To_P[i] to a different value than PHY_P_To_C[i], the Controller shall
- * return the error code Unsupported Feature or Parameter Value (0x11).
- *
- * Event(s) generated (unless masked away):
- * When the HCI_LE_Set_CIG_Parameters_Test command has completed, an
- * HCI_Command_Complete event shall be generated.
- *
- * @param[in] p_params Input parameters.
- * @param[out] p_return Extra return parameters.
- *
- * @retval 0 if success.
- * @return Returns value between 0x01-0xFF in case of error.
- * See Vol 2, Part D, Error for a list of error codes and descriptions.
- */
-uint8_t sdc_hci_cmd_le_set_cig_params_test(const sdc_hci_cmd_le_set_cig_params_test_t * p_params,
- sdc_hci_cmd_le_set_cig_params_test_return_t * p_return);
-
-/** @brief LE Create CIS.
- *
- * The description below is extracted from Core_v5.4,
- * Vol 4, Part E, Section 7.8.99
- *
- * The HCI_LE_Create_CIS command is used by the Central's Host to create
- * one or more CISes using the connections identified by the ACL_Connection_-
- * Handle arrayed parameter.
- *
- * The CIS_Count parameter is the total number of CISes created by this
- * command.
- *
- * The CIS_Connection_Handle[i] parameter specifies the connection handle
- * corresponding to the configuration of the CIS to be created and whose
- * configuration is already stored in a CIG.
- *
- * The ACL_Connection_Handle[i] parameter specifies the connection handle of
- * the ACL connection associated with each CIS to be created. The list of the
- * ACL_Connection_Handles shall be in the same order as the list of the
- * CIS_Connection_Handles e.g., CIS_Connection_Handle[1] will connect to the
- * Peripheral associated with the ACL_Connection_Handle[1].
- *
- * If this command is issued on the Central before the devices have performed
- * the Feature Exchange procedure, then the Controller shall complete that pro-
- * cedure before initiating the Connected Isochronous Stream Creation procedure
- * (see [Vol 6] Part B, Section 5.1.15).
- *
- * If any ACL_Connection_Handle[i] is not the handle of an existing ACL
- * connection or any CIS_Connection_Handle[i] is not the handle of a CIS or CIS
- * configuration, the Controller shall return the error code Unknown Connection
- * Identifier (0x02).
- *
- * If the Host attempts to create a CIS that has already been created, the
- * Controller shall return the error code Connection Already Exists (0x0B).
- *
- * If two different elements of the CIS_Connection_Handle arrayed parameter
- * identify the same CIS, the Controller shall return the error code Invalid HCI
- * Command Parameters (0x12).
- *
- * If the Host issues this command before all the HCI_LE_CIS_Established
- * events from the previous use of the command have been generated, the
- * Controller shall return the error code Command Disallowed (0x0C).
- * If the Host issues this command on an ACL_Connection_Handle where the
- * Controller is the Peripheral, the Controller shall return the error code Command
- * Disallowed (0x0C).
- *
- * Note: The order of the CIS connection handles in this command does not relate
- * to the order of connection handles in the return parameters of the HCI_LE_-
- * Set_CIG_Parameters command or the HCI_LE_Set_CIG_Parameters_Test
- * command.
- *
- * If the Host issues this command when the Connected Isochronous Stream
- * (Host Support) feature bit (see [Vol 6] Part B, Section 4.6.27) is not set, the
- * Controller shall return the error code Command Disallowed (0x0C).
- *
- * If the Host specified an invalid combination of parameters in the HCI_LE_Set_-
- * CIG_Parameters or HCI_LE_Set_CIG_Parameters_Test command that cre-
- * ated the CIS configuration, but the Controller could not detect the problem
- * without knowing the properties of the ACL connection associated with the CIS,
- * then the Controller shall return an error which should use the error code
- * Unsupported Feature or Parameter Value (0x11).
- *
- * Note: If an error is reported in the HCI_Command_Status event, it means that
- * no CIS is created and the Host cannot determine which CIS had the error.
- * Therefore, in the case of an error that only affects one CIS of several, reporting
- * the error in the HCI_LE_CIS_Established event for that CIS means that the
- * remaining CISes are still created and the Host can determine which CIS had
- * the error.
- *
- * Event(s) generated (unless masked away):
- * When the Controller receives the HCI_LE_Create_CIS command, the
- * Controller sends the HCI_Command_Status event to the Host. An
- * HCI_LE_CIS_Established event will be generated for each CIS when it is
- * established or if it is disconnected or considered lost before being established;
- * until all the events are generated, the command remains pending.
- *
- * @param[in] p_params Input parameters.
- *
- * @retval 0 if success.
- * @return Returns value between 0x01-0xFF in case of error.
- * See Vol 2, Part D, Error for a list of error codes and descriptions.
- */
-uint8_t sdc_hci_cmd_le_create_cis(const sdc_hci_cmd_le_create_cis_t * p_params);
-
-/** @brief LE Remove CIG.
- *
- * The description below is extracted from Core_v5.4,
- * Vol 4, Part E, Section 7.8.100
- *
- * The HCI_LE_Remove_CIG command is used by the Central’s Host to remove
- * the CIG identified by CIG_ID.
- *
- * The CIG_ID parameter contains the identifier of the CIG.
- *
- * This command shall delete the CIG_ID and also delete the
- * Connection_Handles of the CIS configurations stored in the CIG.
- *
- * This command shall also remove the isochronous data paths that are
- * associated with the Connection_Handles of the CIS configurations, which is
- * equivalent to issuing the HCI_LE_Remove_ISO_Data_Path command (see
- * Section 7.8.110).
- *
- * If the Host tries to remove a CIG which is in the active state, then the Controller
- * shall return the error code Command Disallowed (0x0C).
- *
- * If the Host issues this command with a CIG_ID that does not exist, the
- * Controller shall return the error code Unknown Connection Identifier (0x02).
- *
- * Event(s) generated (unless masked away):
- * When the HCI_LE_Remove_CIG command has completed, an
- * HCI_Command_Complete event shall be generated.
- *
- * @param[in] p_params Input parameters.
- * @param[out] p_return Extra return parameters.
- *
- * @retval 0 if success.
- * @return Returns value between 0x01-0xFF in case of error.
- * See Vol 2, Part D, Error for a list of error codes and descriptions.
- */
-uint8_t sdc_hci_cmd_le_remove_cig(const sdc_hci_cmd_le_remove_cig_t * p_params,
- sdc_hci_cmd_le_remove_cig_return_t * p_return);
-
-/** @brief LE Accept CIS Request.
- *
- * The description below is extracted from Core_v5.4,
- * Vol 4, Part E, Section 7.8.101
- *
- * The HCI_LE_Accept_CIS_Request command is used by the Peripheral's Host
- * to inform the Controller to accept the request for the CIS that is identified by the
- * Connection_Handle.
- *
- * The command shall only be issued after an HCI_LE_CIS_Request event has
- * occurred. The event contains the Connection_Handle of the CIS.
- *
- * If the Peripheral's Host issues this command with a Connection_Handle that
- * does not exist, or the Connection_Handle is not for a CIS, the Controller shall
- * return the error code Unknown Connection Identifier (0x02).
- *
- * If the Peripheral's Host issues this command with a Connection_Handle for a
- * CIS that has already been established or that already has an HCI_LE_-
- * Accept_CIS_Request or HCI_LE_Reject_CIS_Request command in progress,
- * the Controller shall return the error code Command Disallowed (0x0C).
- *
- * If the Central’s Host issues this command, the Controller shall return the error
- * code Command Disallowed (0x0C).
- *
- * Event(s) generated (unless masked away):
- * When the Controller receives the HCI_LE_Accept_CIS_Request command,
- * the Controller sends the HCI_Command_Status event to the Host. An
- * HCI_LE_CIS_Established event will be generated when the CIS is established
- * or is considered lost before being established.
- *
- * @param[in] p_params Input parameters.
- *
- * @retval 0 if success.
- * @return Returns value between 0x01-0xFF in case of error.
- * See Vol 2, Part D, Error for a list of error codes and descriptions.
- */
-uint8_t sdc_hci_cmd_le_accept_cis_request(const sdc_hci_cmd_le_accept_cis_request_t * p_params);
-
-/** @brief LE Reject CIS Request.
- *
- * The description below is extracted from Core_v5.4,
- * Vol 4, Part E, Section 7.8.102
- *
- * The HCI_LE_Reject_CIS_Request command is used by the Peripheral's Host
- * to inform the Controller to reject the request for the CIS that is identified by the
- * Connection_Handle.
- *
- * The command shall only be issued after an HCI_LE_CIS_Request event has
- * occurred. The event contains the Connection_Handle of the CIS.
- *
- * When this command succeeds, the Controller shall delete the
- * Connection_Handle of the requested CIS.
- *
- * The Reason command parameter indicates the reason for rejecting the CIS
- * request.
- *
- * If the Peripheral's Host issues this command with a Connection_Handle that is
- * not for a CIS, the Controller shall return the error code Unknown Connection
- * Identifier (0x02).
- *
- * If the Peripheral's Host issues this command with a Connection_Handle for a
- * CIS that has already been established or that already has an HCI_LE_-
- * Accept_CIS_Request or HCI_LE_Reject_CIS_Request command in progress,
- * the Controller shall return the error code Command Disallowed (0x0C).
- *
- * If the Central’s Host issues this command, the Controller shall return the error
- * code Command Disallowed (0x0C).
- *
- * Event(s) generated (unless masked away):
- * When the HCI_LE_Reject_CIS_Request command has completed, an
- * HCI_Command_Complete event shall be generated.
- *
- * @param[in] p_params Input parameters.
- * @param[out] p_return Extra return parameters.
- *
- * @retval 0 if success.
- * @return Returns value between 0x01-0xFF in case of error.
- * See Vol 2, Part D, Error for a list of error codes and descriptions.
- */
-uint8_t sdc_hci_cmd_le_reject_cis_request(const sdc_hci_cmd_le_reject_cis_request_t * p_params,
- sdc_hci_cmd_le_reject_cis_request_return_t * p_return);
-
-/** @brief LE Create BIG.
- *
- * The description below is extracted from Core_v5.4,
- * Vol 4, Part E, Section 7.8.103
- *
- * The HCI_LE_Create_BIG command is used to create a BIG with one or more
- * BISes (see [Vol 6] Part B, Section 4.4.6). All BISes in a BIG have the same
- * value for all parameters.
- *
- * The BIG_Handle contains the identifier of the BIG. This parameter is allocated
- * by the Host and used by the Controller and the Host to identify a BIG.
- *
- * The Advertising_Handle identifies the associated periodic advertising train of
- * the BIG (see [Vol 6] Part B, Section 4.4.5.1).
- *
- * The Num_BIS parameter contains the total number of BISes in the BIG.
- *
- * The SDU_Interval parameter contains the time interval of the periodic SDUs.
- *
- * The Max_SDU parameter contains the maximum size of an SDU.
- *
- * The Max_Transport_Latency parameter is the maximum transport latency (in
- * milliseconds) as described in [Vol 6] Part G, Section 3.2.1 and [Vol 6] Part G,
- * Section 3.2.2. This includes pre-transmissions.
- *
- * The RTN (Retransmission Number) parameter contains the number of times
- * every PDU should be retransmitted, irrespective of which BIG events the
- * retransmissions occur in. This is a recommendation to the Controller which the
- * Controller may ignore.
- *
- * The PHY parameter is a bit field that indicates the PHY used for transmission
- * of PDUs of BISes in the BIG. The Host shall set at least one bit in this
- * parameter and the Controller shall pick a PHY from the bits set. If the Host
- * sets, in the PHY parameter, a bit for a PHY that the Controller does not
- * support, including a bit that is reserved for future use, the Controller shall return
- * the error code Unsupported Feature or Parameter Value (0x11).
- *
- * The Packing parameter is used to indicate the preferred method of arranging
- * subevents of multiple BISes. The subevents can be arranged in Sequential or
- * Interleaved arrangement. This is a recommendation to the Controller which it
- * may ignore. This parameter shall be ignored when there is only one BIS in the
- * BIG.
- *
- * The Framing parameter indicates the format for sending BIS Data PDUs. If the
- * Framing parameter is set to 1 then BIS Data PDUs shall be Framed and when
- * set to 0 they may be unframed (see [Vol 6] Part G, Section 1).
- *
- * The Encryption parameter identifies the encryption mode of the BISes. If the
- * Encryption parameter is set to 1 (encrypted), the Broadcast_Code is used in
- * the encryption of payloads (see [Vol 6] Part B, Section 4.4.6.10).
- *
- * The Broadcast_Code parameter is used to generate the encryption key for
- * encrypting payloads of all BISes. When the Encryption parameter is set to 0
- * (unencrypted), the Broadcast_Code parameter shall be set to zero by the Host
- * and ignored by the Controller.
- *
- * If the Controller cannot create all BISes of the BIG or if Num_BIS exceeds the
- * maximum value supported by the Controller, it shall return the error code
- * Connection Rejected due to Limited Resources (0x0D).
- *
- * If the Advertising_Handle does not identify a periodic advertising train or the
- * periodic advertising train is associated with another BIG, the Controller shall
- * return the error code Unknown Advertising Identifier (0x42).
- *
- * If the Host issues this command with a BIG_Handle for a BIG that is already
- * created, the Controller shall return the error code Command Disallowed
- * (0x0C).
- *
- * If the Host specifies an invalid combination of BIG parameters, the Controller
- * shall return an error which should use the error code Invalid HCI Command
- * Parameters (0x12).
- *
- * If the length of the associated periodic advertising, with the BIGInfo added to
- * the ACAD, is greater than the maximum that the Controller can transmit within
- * the periodic advertising interval, then the Controller shall return an error and
- * should use the error code Packet Too Long (0x45). If advertising on the LE
- * Coded PHY, then the S=8 coding shall be assumed unless the current
- * advertising parameters require the use of S=2 for an advertising physical
- * channel, in which case the S=2 coding shall be assumed for that advertising
- * physical channel.
- *
- * Event(s) generated (unless masked away):
- * When the Controller receives the HCI_LE_Create_BIG command, the Control-
- * ler sends the HCI_Command_Status event to the Host. When the HCI_LE_-
- * Create_BIG command has completed, the HCI_LE_Create_BIG_Complete
- * event is generated.
- *
- * @param[in] p_params Input parameters.
- *
- * @retval 0 if success.
- * @return Returns value between 0x01-0xFF in case of error.
- * See Vol 2, Part D, Error for a list of error codes and descriptions.
- */
-uint8_t sdc_hci_cmd_le_create_big(const sdc_hci_cmd_le_create_big_t * p_params);
-
-/** @brief LE Create BIG Test.
- *
- * The description below is extracted from Core_v5.4,
- * Vol 4, Part E, Section 7.8.104
- *
- * The HCI_LE_Create_BIG_Test command should only be used for testing
- * purposes.
- *
- * The command is used to create one or more BISes of a BIG (see [Vol 6] Part B,
- * Section 4.4.6). All BISes in the BIG have the same values for all parameters.
- *
- * The BIG_Handle contains the identifier of the BIG. This parameter is allocated
- * by the Host and used by the Controller and the Host to identify a BIG.
- *
- * The Advertising_Handle identifies the associated periodic advertising train of
- * the BIG.
- *
- * The Num_BIS parameter contains the total number of BISes in the BIG.
- *
- * The SDU_Interval parameter specifies the time interval of the periodic SDUs.
- *
- * The ISO_Interval parameter contains the time duration between two
- * consecutive BIG anchor points.
- *
- * The NSE (Number of SubEvents) parameter contains the total number of
- * subevents that are used to transmit BIS Data PDUs for each BIS in a BIG
- * event. The NSE parameter shall be greater than or equal to IRC * BN.
- * The Max_SDU parameter contains the maximum size, in octets, of an SDU.
- * The minimum value of the Max_SDU parameter in the ISO Transmit Test mode
- * when the Payload_Type = 1 or 2 shall be 4.
- *
- * The Max_PDU parameter contains the maximum size of every BIS Data PDU
- * for every BIS in the BIG.
- *
- * The PHY parameter is a bit field that indicates the PHY used for transmission
- * of PDUs of BISes in the BIG. The Host shall set only one bit in this parameter
- * and the Controller shall use the PHY set by the Host. If the Host sets, in the
- * PHY parameter, a bit for a PHY that the Controller does not support, including
- * a bit that is reserved for future use, the Controller shall return the error code
- * Unsupported Feature or Parameter Value (0x11).
- *
- * The Packing parameter indicates the preferred method of arranging subevents
- * of multiple BISes. The subevents can be arranged in Sequential or Interleaved
- * arrangement. This is a recommendation to the Controller which it may ignore.
- * This parameter shall be ignored when there is only one BIS in the BIG.
- *
- * The Framing parameter indicates the format of BIS Data PDUs. If the Framing
- * parameter is set to 1 then BIS Data PDUs shall be Framed and when set to 0
- * the BIS Data PDUs shall be unframed (see [Vol 6] Part G, Section 1).
- *
- * The BN (Burst Number) parameter contains the number of new payloads for
- * each BIS in a BIS event.
- *
- * The IRC (Immediate Repetition Count) parameter contains the number of times
- * the scheduled data packet is transmitted (see [Vol 6] Part B, Section 4.4.6).
- * The IRC parameter shall be an integer in the range 1 to (NSE ÷ BN).
- *
- * The PTO (Pre_Transmission_Offset) parameter contains the offset in number
- * of ISO_Intervals for pre transmissions of data packets (see [Vol 6] Part B,
- * Section 4.4.6).
- *
- * The Encryption parameter identifies the encryption mode of the BISes in the
- * BIG. If the Encryption parameter is set to 1 (encrypted), the Broadcast_Code is
- * used in the encryption of payloads (see [Vol 6] Part B, Section 4.4.6).
- *
- * The Broadcast_Code parameter is a 16-octet field that is used to generate the
- * session key to encrypt payloads of all BISes in the BIG. When the Encryption
- * parameter is set to 0 (unencrypted), all 16 octets of the Broadcast_Code
- * parameter shall be set to zero by the Host and ignored by the Controller.
- *
- * If the Controller cannot create all BISes of the BIG or if Num_BIS exceeds the
- * maximum value supported by the Controller, it shall return the error code
- * Connection Rejected due to Limited Resources (0x0D).
- *
- * If the Advertising_Handle does not identify a periodic advertising train or the
- * periodic advertising train is associated with another BIG, the Controller shall
- * return the error code Unknown Advertising Identifier (0x42).
- * If the Host issues this command with a BIG_Handle for a BIG that is already
- * created, the Controller shall return the error code Command Disallowed
- * (0x0C).
- *
- * If the value of the Max_PDU, NSE, BN, IRC or PTO parameters exceeds the
- * values supported by the Controller, the Controller shall return the error code
- * Unsupported Feature or Parameter Value (0x11).
- *
- * If the Host specifies an invalid combination of BIG parameters, the Controller
- * shall return an error. If the value of the NSE parameter is not an integer
- * multiple of BN, or NSE is less than (IRC * BN), or the parameters are not in the
- * specified range, these errors shall use the error code Unsupported Feature or
- * Parameter Value (0x11). The errors in all other circumstances should use the
- * error code Invalid HCI Command Parameters (0x12).
- *
- * If the length of the associated periodic advertising, with the BIGInfo added to
- * the ACAD, is greater than the maximum that the Controller can transmit within
- * the periodic advertising interval, then the Controller shall return an error and
- * should use the error code Packet Too Long (0x45). If advertising on the LE
- * Coded PHY, then the S=8 coding shall be assumed unless the current
- * advertising parameters require the use of S=2 for an advertising physical
- * channel, in which case the S=2 coding shall be assumed for that advertising
- * physical channel.
- *
- * Event(s) generated (unless masked away):
- * When the Controller receives the HCI_LE_Create_BIG_Test command, the
- * Controller sends the HCI_Command_Status event to the Host. When the
- * HCI_LE_Create_BIG_Test command has completed, the HCI_LE_Create_-
- * BIG_Complete event is generated.
- *
- * @param[in] p_params Input parameters.
- *
- * @retval 0 if success.
- * @return Returns value between 0x01-0xFF in case of error.
- * See Vol 2, Part D, Error for a list of error codes and descriptions.
- */
-uint8_t sdc_hci_cmd_le_create_big_test(const sdc_hci_cmd_le_create_big_test_t * p_params);
-
-/** @brief LE Terminate BIG.
- *
- * The description below is extracted from Core_v5.4,
- * Vol 4, Part E, Section 7.8.105
- *
- * The HCI_LE_Terminate_BIG command is used to terminate a BIG identified by
- * the BIG_Handle parameter. The command also terminates the transmission of
- * all BISes of the BIG, destroys the associated connection handles of the BISes
- * in the BIG and removes the data paths for all BISes in the BIG.
- *
- * The Reason parameter is used to indicate the reason why the BIG is to be
- * terminated.
- *
- * If the BIG_Handle does not identify a BIG, the Controller shall return the error
- * code Unknown Advertising Identifier (0x42).
- *
- * If the Controller is not the Isochronous Broadcaster for the BIG identified by
- * BIG_Handle, the Controller shall return the error code Command Disallowed
- * (0x0C).
- *
- * Event(s) generated (unless masked away):
- * When the Controller receives the HCI_LE_Terminate_BIG command, the
- * Controller sends the HCI_Command_Status event to the Host.
- *
- * When the HCI_LE_Terminate_BIG command has completed, the HCI_LE_-
- * Terminate_BIG_Complete event will be generated.
- * If the Host attempts to terminate a BIG while the process of establishment of
- * the BIG is in progress (i.e. HCI_LE_Create_BIG_Complete event has not been
- * generated) the process of establishment shall stop and the Controller shall
- * generate the HCI_LE_Create_BIG_Complete event to the Host with the error
- * code Operation Cancelled by Host (0x44).
- *
- * @param[in] p_params Input parameters.
- *
- * @retval 0 if success.
- * @return Returns value between 0x01-0xFF in case of error.
- * See Vol 2, Part D, Error for a list of error codes and descriptions.
- */
-uint8_t sdc_hci_cmd_le_terminate_big(const sdc_hci_cmd_le_terminate_big_t * p_params);
-
-/** @brief LE BIG Create Sync.
- *
- * The description below is extracted from Core_v5.4,
- * Vol 4, Part E, Section 7.8.106
- *
- * The HCI_LE_BIG_Create_Sync command is used to synchronize to a BIG
- * described in the periodic advertising train specified by the Sync_Handle
- * parameter.
- *
- * The BIG_Handle parameter is assigned by the Host to identify the
- * synchronized BIG.
- *
- * The Encryption parameter indicates whether the Broadcast_Code parameter is
- * valid.
- *
- * The Broadcast_Code parameter is a 16-octet field that is used to generate the
- * session key to encrypt or decrypt payloads of an encrypted BIS.
- * Broadcast_Code shall be ignored by the Controller if Encryption is set to 0x00.
- *
- * If Encryption is set to 0x00 for an encrypted BIG or is set to 0x01 for an
- * unencrypted BIG, then the Controller shall return the error Encryption Mode
- * Not Acceptable (0x25).
- *
- * The MSE (Maximum Subevents) parameter is the maximum number of
- * subevents that a Controller should use to receive data payloads in each
- * interval for a BIS.
- *
- * The BIG_Sync_Timeout parameter specifies the maximum permitted time
- * between successful receptions of BIS PDUs. If this time is exceeded,
- * synchronization is lost. When the Controller establishes synchronization and if
- * the BIG_Sync_Timeout set by the Host is less than 6 * ISO_Interval, the
- * Controller shall set the timeout to 6 * ISO_Interval.
- *
- * The Num_BIS parameter contains the number of BIS indices specified in the
- * BIS arrayed parameter. The number of BISes requested may be a subset of
- * the BISes available in the BIG.
- * The BIS arrayed parameter is a list of indices corresponding to BIS(es) in the
- * synchronized BIG. The list of BIS indices shall be in ascending order and shall
- * not contain any duplicates. This list of specified BIS(es) may be all or a subset
- * of BISes available in the BIG.
- *
- * If the Sync_Handle does not exist, the Controller shall return the error code
- * Unknown Advertising Identifier (0x42).
- *
- * If the Host sends this command with a BIG_Handle that is already allocated,
- * the Controller shall return the error code Command Disallowed (0x0C).
- *
- * If the information describing the BIG does not specify a PHY supported by the
- * Controller or does not specify exactly one PHY, the Controller shall return the
- * error code Unsupported Feature or Parameter Value (0x11).
- *
- * If the Num_BIS parameter is greater than the total number of BISes in the BIG,
- * the Controller shall return the error code Unsupported Feature or Parameter
- * Value (0x11).
- *
- * If the Host sends this command when the Controller is in the process of
- * synchronizing to any BIG, i.e. the HCI_LE_BIG_Sync_Established event has
- * not been generated, the Controller shall return the error code Command
- * Disallowed (0x0C).
- *
- * If the Controller is unable to receive PDUs from the specified number of BISes
- * in the synchronized BIG, it shall return the error code Connection Rejected Due
- * To Limited Resources (0x0D).
- *
- * Event(s) generated (unless masked away):
- * When the Controller receives the HCI_LE_BIG_Create_Sync command, the
- * Controller sends the HCI_Command_Status event to the Host. When the
- * HCI_LE_BIG_Create_Sync command has completed, the HCI_LE_BIG_-
- * Sync_Established event will be generated.
- *
- * @param[in] p_params Input parameters.
- *
- * @retval 0 if success.
- * @return Returns value between 0x01-0xFF in case of error.
- * See Vol 2, Part D, Error for a list of error codes and descriptions.
- */
-uint8_t sdc_hci_cmd_le_big_create_sync(const sdc_hci_cmd_le_big_create_sync_t * p_params);
-
-/** @brief LE BIG Terminate Sync.
- *
- * The description below is extracted from Core_v5.4,
- * Vol 4, Part E, Section 7.8.107
- *
- * The HCI_LE_BIG_Terminate_Sync command is used to stop synchronizing or
- * cancel the process of synchronizing to the BIG identified by the BIG_Handle
- * parameter. The command also terminates the reception of BISes in the BIG
- * specified in the HCI_LE_BIG_Create_Sync command, destroys the associated
- * connection handles of the BISes in the BIG and removes the data paths for all
- * BISes in the BIG.
- *
- * If the Host issues this command with a BIG_Handle that does not exist, the
- * Controller shall return the error code Unknown Advertising Identifier (0x42).
- *
- * If the Host issues this command for a BIG which it is neither synchronized to
- * nor in the process of synchronizing to, then the Controller shall return the error
- * code Command Disallowed (0x0C).
- *
- * Event(s) generated (unless masked away):
- * When the HCI_LE_BIG_Terminate_Sync command has completed, an
- * HCI_Command_Complete event shall be generated.
- *
- * If the Host attempts to terminate synchronization with a BIG while the process
- * of synchronization with that BIG is in progress (i.e. HCI_LE_BIG_Sync_-
- * Established event has not been generated) the process of synchronization
- * shall stop, and the Controller shall generate the HCI_LE_BIG_Sync_-
- * Established event to the Host with the error code Operation Cancelled by Host
- * (0x44).
- *
- * @param[in] p_params Input parameters.
- * @param[out] p_return Extra return parameters.
- *
- * @retval 0 if success.
- * @return Returns value between 0x01-0xFF in case of error.
- * See Vol 2, Part D, Error for a list of error codes and descriptions.
- */
-uint8_t sdc_hci_cmd_le_big_terminate_sync(const sdc_hci_cmd_le_big_terminate_sync_t * p_params,
- sdc_hci_cmd_le_big_terminate_sync_return_t * p_return);
-
-/** @brief LE Request Peer SCA.
- *
- * The description below is extracted from Core_v5.4,
- * Vol 4, Part E, Section 7.8.108
- *
- * This command is used to read the Sleep Clock Accuracy (SCA) of the peer
- * device.
- *
- * The Connection_Handle parameter is the connection handle of the ACL
- * connection.
- *
- * If the Host sends this command with a Connection_Handle that does not exist,
- * or the Connection_Handle is not for an ACL the Controller shall return the error
- * code Unknown Connection Identifier (0x02).
- *
- * If the Host sends this command and the peer device does not support the
- * Sleep Clock Accuracy Updates feature, the Controller shall return the error
- * code Unsupported Feature or Parameter Value (0x11) in the HCI_LE_-
- * Request_Peer_SCA_Complete event.
- *
- * If the Host issues this command when the Controller is aware (e.g., through a
- * previous feature exchange) that the peer device's Link Layer does not support
- * the Sleep Clock Accuracy Updates feature, the Controller shall return the error
- * code Unsupported Remote Feature (0x1A).
- *
- * Event(s) generated (unless masked away):
- * When the Controller receives the HCI_LE_Request_Peer_SCA command, the
- * Controller sends the HCI_Command_Status event to the Host. When the
- * HCI_LE_Request_Peer_SCA command has completed, the HCI_LE_-
- * Request_Peer_SCA_Complete event shall be generated.
+ * When the Controller receives the HCI_LE_Request_Peer_SCA command, the
+ * Controller sends the HCI_Command_Status event to the Host. When the
+ * HCI_LE_Request_Peer_SCA command has completed, the HCI_LE_-
+ * Request_Peer_SCA_Complete event shall be generated.
*
* @param[in] p_params Input parameters.
*
@@ -6250,407 +4802,6 @@ uint8_t sdc_hci_cmd_le_big_terminate_sync(const sdc_hci_cmd_le_big_terminate_syn
*/
uint8_t sdc_hci_cmd_le_request_peer_sca(const sdc_hci_cmd_le_request_peer_sca_t * p_params);
-/** @brief LE Setup ISO Data Path.
- *
- * The description below is extracted from Core_v5.4,
- * Vol 4, Part E, Section 7.8.109
- *
- * The HCI_LE_Setup_ISO_Data_Path command is used to identify and create
- * the isochronous data path between the Host and the Controller for a CIS, CIS
- * configuration, or BIS identified by the Connection_Handle parameter. This
- * command can also be used to configure a codec for each data path. When a
- * connection is created no data paths are set up for that connection.
- *
- * The input and output directions are defined from the perspective of the
- * Controller, so "input" refers to data flowing from the Host to the Controller.
- *
- * If the Host issues this command more than once for the same Connection_-
- * Handle and direction before issuing the HCI_LE_Remove_ISO_Data_Path
- * command for that Connection_Handle and direction, the Controller shall return
- * the error code Command Disallowed (0x0C).
- *
- * If the Host issues this command for a CIS on a Peripheral before it has issued
- * the HCI_LE_Accept_CIS_Request command for that CIS, then the Controller
- * shall return the error code Command Disallowed (0x0C).
- *
- * The Data_Path_Direction parameter specifies the direction for which the data
- * path is being configured.
- *
- * The Data_Path_ID parameter specifies the data transport path used. When set
- * to 0x00, the data path shall be over the HCI transport. When set to a value in
- * the range 0x01 to 0xFE, the data path shall use a vendor-specific transport
- * interface (e.g., a PCM interface) with logical transport numbers. The meanings
- * of these logical transport numbers are vendor-specific.
- *
- * If the Host issues this command for a vendor-specific data transport path that
- * has not been configured, the Controller shall return the error code Command
- * Disallowed (0x0C).
- *
- * If the Host attempts to set a data path with a Connection Handle that does not
- * exist or that is not for a CIS, CIS configuration, or BIS, the Controller shall
- * return the error code Unknown Connection Identifier (0x02).
- * If the Host attempts to set an output data path using a connection handle that is
- * for an Isochronous Broadcaster, for an input data path on a Synchronized
- * Receiver, or for a data path for the direction on a unidirectional CIS where BN
- * is set to 0, the Controller shall return the error code Command Disallowed
- * (0x0C).
- *
- * The Codec_ID parameter specifies the coding format used over the air.
- *
- * When Data_Path_Direction is set to 0x00 (input), the Controller_Delay param-
- * eter specifies the delay at the data source from the reference time of an SDU to
- * the CIG reference point (see [Vol 6] Part B, Section 4.5.14.1) or BIG anchor
- * point (see [Vol 6] Part B, Section 4.4.6.4). When Data_Path_Direction is set to
- * 0x01 (output), Controller_Delay specifies the delay from the
- * SDU_Synchronization_Reference to the point in time at which the Controller
- * begins to transfer the corresponding data to the data path interface. The Host
- * should use the HCI_Read_Local_Supported_Controller_Delay command to
- * obtain a suitable value for Controller_Delay.
- *
- * Note: Controller vendors may provide additional guidance to the Host on how
- * to select a suitable Controller_Delay value from the range of values provided
- * by the HCI_Read_Local_Supported_Controller_Delay command for various
- * configurations of the data path interface.
- *
- * The Codec_Configuration parameter specifies codec-specific configuration
- * information for the specified direction.
- *
- * If the Host issues this command with Codec_Configuration_Length non-zero
- * and Codec_ID set to transparent air mode, the Controller shall return the error
- * code Invalid HCI Command Parameters (0x12).
- *
- * If the Host issues this command with codec-related parameters that exceed the
- * bandwidth and latency allowed on the established CIS or BIS identified by the
- * Connection_Handle parameter, the Controller shall return the error code
- * Invalid HCI Command Parameters (0x12).
- *
- * Event(s) generated (unless masked away):
- * When the HCI_LE_Setup_ISO_Data_Path command has completed, an
- * HCI_Command_Complete event shall be generated.
- *
- * @param[in] p_params Input parameters.
- * @param[out] p_return Extra return parameters.
- *
- * @retval 0 if success.
- * @return Returns value between 0x01-0xFF in case of error.
- * See Vol 2, Part D, Error for a list of error codes and descriptions.
- */
-uint8_t sdc_hci_cmd_le_setup_iso_data_path(const sdc_hci_cmd_le_setup_iso_data_path_t * p_params,
- sdc_hci_cmd_le_setup_iso_data_path_return_t * p_return);
-
-/** @brief LE Remove ISO Data Path.
- *
- * The description below is extracted from Core_v5.4,
- * Vol 4, Part E, Section 7.8.110
- *
- * The HCI_LE_Remove_ISO_Data_Path command is used to remove the input
- * and/or output data path(s) associated with a CIS, CIS configuration, or BIS
- * identified by the Connection_Handle parameter.
- *
- * The Data_Path_Direction parameter specifies which directions are to have the
- * data path removed.
- *
- * If the Host issues this command with a Connection_Handle that does not exist
- * or is not for a CIS, CIS configuration, or BIS, the Controller shall return the
- * error code Unknown Connection Identifier (0x02).
- *
- * If the Host issues this command for a data path that has not been set up (using
- * the HCI_LE_Setup_ISO_Data_Path command), the Controller shall return the
- * error code Command Disallowed (0x0C).
- *
- * Event(s) generated (unless masked away):
- * When the HCI_LE_Remove_ISO_Data_Path command has completed, an
- * HCI_Command_Complete event shall be generated.
- *
- * @param[in] p_params Input parameters.
- * @param[out] p_return Extra return parameters.
- *
- * @retval 0 if success.
- * @return Returns value between 0x01-0xFF in case of error.
- * See Vol 2, Part D, Error for a list of error codes and descriptions.
- */
-uint8_t sdc_hci_cmd_le_remove_iso_data_path(const sdc_hci_cmd_le_remove_iso_data_path_t * p_params,
- sdc_hci_cmd_le_remove_iso_data_path_return_t * p_return);
-
-/** @brief LE ISO Transmit Test.
- *
- * The description below is extracted from Core_v5.4,
- * Vol 4, Part E, Section 7.8.111
- *
- * The HCI_LE_ISO_Transmit_Test command should only be used in the ISO
- * Test mode and only for testing purposes.
- *
- * The command is used to configure an established CIS or BIS specified by the
- * Connection_Handle parameter, and transmit test payloads which are
- * generated by the Controller.
- *
- * The Payload_Type parameter defines the configuration of SDUs in the
- * payload.
- *
- * If the Host issues this command with a connection handle that does not exist,
- * or the Connection_Handle command parameter is not associated with a CIS or
- * a BIS, the Controller shall return the error code Unknown Connection Identifier
- * (0x02).
- *
- * If the Host issues this command when the value of the transmit BN parameter
- * of the CIS is set to zero, the Controller shall return the error code Unsupported
- * Feature or Parameter Value (0x11).
- *
- * If the Host has set the input data path for the CIS or BIS identified by the
- * connection handle, the Controller shall return the error code Command
- * Disallowed (0x0C).
- *
- * Event(s) generated (unless masked away):
- * When the HCI_LE_ISO_Transmit_Test command has completed, an
- * HCI_Command_Complete event shall be generated.
- *
- * @param[in] p_params Input parameters.
- * @param[out] p_return Extra return parameters.
- *
- * @retval 0 if success.
- * @return Returns value between 0x01-0xFF in case of error.
- * See Vol 2, Part D, Error for a list of error codes and descriptions.
- */
-uint8_t sdc_hci_cmd_le_iso_transmit_test(const sdc_hci_cmd_le_iso_transmit_test_t * p_params,
- sdc_hci_cmd_le_iso_transmit_test_return_t * p_return);
-
-/** @brief LE ISO Receive Test.
- *
- * The description below is extracted from Core_v5.4,
- * Vol 4, Part E, Section 7.8.112
- *
- * The HCI_LE_ISO_Receive_Test command should only be used in the ISO Test
- * mode and only for testing purposes.
- *
- * The command is used to configure an established CIS or a synchronized BIG
- * specified by the Connection_Handle parameter to receive payloads.
- *
- * When using this command for a BIS, the Host shall synchronize with a BIG
- * using the HCI_LE_BIG_Create_Sync command before invoking this
- * command.
- *
- * The Payload_Type parameter defines the configuration of SDUs in the
- * payload.
- *
- * If the Host issues this command with a connection handle that is not for an
- * established CIS or a BIS, the Controller shall return the error code Unknown
- * Connection Identifier (0x02).
- *
- * If the Host issues this command when the value of the receive BN parameter of
- * the CIS or BIS is set to zero, the Controller shall return the error code
- * Unsupported Feature or Parameter Value (0x11).
- *
- * If the Host has set the output data path for the CIS or BIS identified by the
- * Connection_Handle parameter, the Controller shall return the error code
- * Command Disallowed (0x0C).
- *
- * Event(s) generated (unless masked away):
- * When the HCI_LE_ISO_Receive_Test command has completed, an
- * HCI_Command_Complete event shall be generated.
- *
- * @param[in] p_params Input parameters.
- * @param[out] p_return Extra return parameters.
- *
- * @retval 0 if success.
- * @return Returns value between 0x01-0xFF in case of error.
- * See Vol 2, Part D, Error for a list of error codes and descriptions.
- */
-uint8_t sdc_hci_cmd_le_iso_receive_test(const sdc_hci_cmd_le_iso_receive_test_t * p_params,
- sdc_hci_cmd_le_iso_receive_test_return_t * p_return);
-
-/** @brief LE ISO Read Test Counters.
- *
- * The description below is extracted from Core_v5.4,
- * Vol 4, Part E, Section 7.8.113
- *
- * The HCI_LE_ISO_Read_Test_Counters command should only be used in the
- * ISO Test mode and only for testing purposes.
- *
- * The command is used to read the test counters (see [Vol 6] Part B, Section 7)
- * in the Controller which is configured in ISO Receive Test mode for a CIS or BIS
- * specified by the Connection_Handle. Reading the test counters does not reset
- * the test counters.
- *
- * The Received_SDU_Count, Missed_SDU_Count and Failed_SDU_Count
- * parameters are set in the ISO Receive Test mode (see [Vol 6] Part B, Section
- * 7.2).
- *
- * If the Host issues this command with a Connection_Handle parameter that is
- * not for an established CIS or a BIS, the Controller shall return the error code
- * Unknown Connection Identifier (0x02).
- *
- * If the Host issues this command for a CIS or BIS that is not configured in the
- * ISO Receive Test mode, the Controller shall return the error code Unsupported
- * Feature or Parameter Value (0x11).
- *
- * Event(s) generated (unless masked away):
- * When the HCI_LE_ISO_Read_Test_Counters command has completed, an
- * HCI_Command_Complete event shall be generated.
- *
- * @param[in] p_params Input parameters.
- * @param[out] p_return Extra return parameters.
- *
- * @retval 0 if success.
- * @return Returns value between 0x01-0xFF in case of error.
- * See Vol 2, Part D, Error for a list of error codes and descriptions.
- */
-uint8_t sdc_hci_cmd_le_iso_read_test_counters(const sdc_hci_cmd_le_iso_read_test_counters_t * p_params,
- sdc_hci_cmd_le_iso_read_test_counters_return_t * p_return);
-
-/** @brief LE ISO Test End.
- *
- * The description below is extracted from Core_v5.4,
- * Vol 4, Part E, Section 7.8.114
- *
- * The HCI_LE_ISO_Test_End command should only be used in the ISO Test
- * mode and only for testing purposes.
- *
- * The command is used to terminate the ISO Transmit and/or Receive Test
- * mode for a CIS or BIS specified by the Connection_Handle parameter but does
- * not terminate the CIS or BIS.
- *
- * When the Host terminates the ISO Test mode for a CIS or BIS that is set to ISO
- * Transmit Test mode only, the test counters in the return parameters shall be set
- * to zero.
- *
- * When the Host terminates the ISO Test mode for a CIS or BIS that is set to the
- * ISO Receive Test mode, the return parameters contain the values of the test
- * counters as defined in [Vol 6] Part B, Section 7.
- *
- * If the Host issues this command with a Connection_Handle that is not for an
- * established CIS or a BIS, the Controller shall return the error code Unknown
- * Connection Identifier (0x02).
- *
- * If the Host issues this command for a CIS or BIS that is not configured in the
- * ISO Transmit or Receive Test mode, the Controller shall return the error code
- * Unsupported Feature or Parameter Value (0x11).
- *
- * Event(s) generated (unless masked away):
- * When the HCI_LE_ISO_Test_End command has completed, an
- * HCI_Command_Complete event shall be generated.
- *
- * @param[in] p_params Input parameters.
- * @param[out] p_return Extra return parameters.
- *
- * @retval 0 if success.
- * @return Returns value between 0x01-0xFF in case of error.
- * See Vol 2, Part D, Error for a list of error codes and descriptions.
- */
-uint8_t sdc_hci_cmd_le_iso_test_end(const sdc_hci_cmd_le_iso_test_end_t * p_params,
- sdc_hci_cmd_le_iso_test_end_return_t * p_return);
-
-/** @brief LE Set Host Feature.
- *
- * The description below is extracted from Core_v5.3,
- * Vol 4, Part E, Section 7.8.115
- *
- * The HCI_LE_Set_Host_Feature command is used by the Host to set or clear a
- * bit controlled by the Host in the Link Layer FeatureSet stored in the Controller
- * (see [Vol 6] Part B, Section 4.6).
- *
- * The Bit_Number parameter specifies the bit position in the FeatureSet.
- *
- * The Bit_Value parameter specifies whether the feature is enabled or disabled.
- *
- * If Bit_Number specifies a feature bit that is not controlled by the Host, the
- * Controller shall return the error code Unsupported Feature or Parameter Value
- * (0x11).
- *
- * If Bit_Value is set to 0x01 and Bit_Number specifies a feature bit that requires
- * support of a feature that the Controller does not support, the Controller shall
- * return the error code Unsupported Feature or Parameter Value (0x11).
- *
- * If the Host issues this command while the Controller has a connection to
- * another device, the Controller shall return the error code Command Disallowed
- * (0x0C).
- *
- * Event(s) generated (unless masked away):
- * When the HCI_LE_Set_Host_Feature command has completed, an
- * HCI_Command_Complete event shall be generated.
- *
- * @param[in] p_params Input parameters.
- *
- * @retval 0 if success.
- * @return Returns value between 0x01-0xFF in case of error.
- * See Vol 2, Part D, Error for a list of error codes and descriptions.
- */
-uint8_t sdc_hci_cmd_le_set_host_feature(const sdc_hci_cmd_le_set_host_feature_t * p_params);
-
-/** @brief LE Read ISO Link Quality.
- *
- * The description below is extracted from Core_v5.4,
- * Vol 4, Part E, Section 7.8.116
- *
- * This command returns the values of various counters related to link quality that
- * are associated with the isochronous stream specified by the
- * Connection_Handle parameter.
- *
- * This command may be issued on both the Central and Peripheral if the
- * connection handle identifies a CIS and on the Synchronized Receiver if the
- * connection handle identifies a BIS.
- *
- * Each of the remaining return parameters shall contain the current value of the
- * corresponding counter; all the values shall be recorded at the same moment.
- * Each counter shall be a 32-bit unsigned value, shall be initialized to zero when
- * the isochronous stream is created, and shall be incremented as described
- * below. If a counter is not associated with the type of isochronous stream
- * specified, the value of the parameter shall be ignored.
- *
- * Associated
- * Counter Streams When Incremented
- *
- * TX_UnACKed_Packets CIS The Link Layer does not receive an
- * acknowledgment for a CIS Data PDU
- * that it transmitted at least once by its
- * flush point (see [Vol 6] Part B, Section
- * 4.5.13.5).
- *
- * TX_Flushed_Packets CIS The Link Layer does not transmit a spe-
- * cific payload by its flush point.
- *
- * TX_Last_Subevent_- CIS in Peripheral The Link Layer transmits a CIS Data
- * Packets role PDU in the last subevent of a CIS
- * event.
- *
- * Retransmitted_Packets CIS The Link Layer retransmits a CIS Data
- * PDU.
- *
- * Table 7.3: Isochronous streams link quality counters
- * Associated
- * Counter Streams When Incremented
- *
- * CRC_Error_Packets CIS and BIS The Link Layer receives a packet with a
- * CRC error.
- *
- * RX_Unreceived_Packets CIS and BIS The Link Layer does not receive a spe-
- * cific payload by its flush point (on a
- * CIS) or the end of the event it is associ-
- * ated with (on a BIS; see [Vol 6] Part B,
- * Section 4.4.6.6).
- *
- * Duplicate_Packets CIS The Link Layer receives a retransmis-
- * sion of a CIS Data PDU.
- *
- * Table 7.3: Isochronous streams link quality counters
- *
- * If the Connection_Handle parameter does not identify a current CIS connection
- * or a BIS that the Controller is synchronized to, the Controller shall return the
- * error code Unknown Connection Identifier (0x02).
- *
- * Event(s) generated (unless masked away):
- * When the HCI_LE_Read_ISO_Link_Quality command has completed, an
- * HCI_Command_Complete event shall be generated.
- *
- * @param[in] p_params Input parameters.
- * @param[out] p_return Extra return parameters.
- *
- * @retval 0 if success.
- * @return Returns value between 0x01-0xFF in case of error.
- * See Vol 2, Part D, Error for a list of error codes and descriptions.
- */
-uint8_t sdc_hci_cmd_le_read_iso_link_quality(const sdc_hci_cmd_le_read_iso_link_quality_t * p_params,
- sdc_hci_cmd_le_read_iso_link_quality_return_t * p_return);
-
/** @brief LE Enhanced Read Transmit Power Level.
*
* The description below is extracted from Core_v5.4,
diff --git a/softdevice_controller/include/sdc_hci_vs.h b/softdevice_controller/include/sdc_hci_vs.h
index 7b7023abb5..f8a8c75048 100644
--- a/softdevice_controller/include/sdc_hci_vs.h
+++ b/softdevice_controller/include/sdc_hci_vs.h
@@ -75,26 +75,12 @@ enum sdc_hci_opcode_vs
SDC_HCI_OPCODE_CMD_VS_PERIPHERAL_LATENCY_MODE_SET = 0xfd09,
/** @brief See @ref sdc_hci_cmd_vs_write_remote_tx_power(). */
SDC_HCI_OPCODE_CMD_VS_WRITE_REMOTE_TX_POWER = 0xfd0a,
+ /** @brief See @ref sdc_hci_cmd_vs_set_auto_power_control_request_param(). */
+ SDC_HCI_OPCODE_CMD_VS_SET_AUTO_POWER_CONTROL_REQUEST_PARAM = 0xfd0b,
/** @brief See @ref sdc_hci_cmd_vs_set_adv_randomness(). */
SDC_HCI_OPCODE_CMD_VS_SET_ADV_RANDOMNESS = 0xfd0c,
/** @brief See @ref sdc_hci_cmd_vs_compat_mode_window_offset_set(). */
SDC_HCI_OPCODE_CMD_VS_COMPAT_MODE_WINDOW_OFFSET_SET = 0xfd0d,
- /** @brief See @ref sdc_hci_cmd_vs_qos_channel_survey_enable(). */
- SDC_HCI_OPCODE_CMD_VS_QOS_CHANNEL_SURVEY_ENABLE = 0xfd0e,
- /** @brief See @ref sdc_hci_cmd_vs_set_power_control_request_params(). */
- SDC_HCI_OPCODE_CMD_VS_SET_POWER_CONTROL_REQUEST_PARAMS = 0xfd10,
- /** @brief See @ref sdc_hci_cmd_vs_read_average_rssi(). */
- SDC_HCI_OPCODE_CMD_VS_READ_AVERAGE_RSSI = 0xfd11,
- /** @brief See @ref sdc_hci_cmd_vs_central_acl_event_spacing_set(). */
- SDC_HCI_OPCODE_CMD_VS_CENTRAL_ACL_EVENT_SPACING_SET = 0xfd12,
- /** @brief See @ref sdc_hci_cmd_vs_set_conn_event_trigger(). */
- SDC_HCI_OPCODE_CMD_VS_SET_CONN_EVENT_TRIGGER = 0xfd13,
- /** @brief See @ref sdc_hci_cmd_vs_get_next_conn_event_counter(). */
- SDC_HCI_OPCODE_CMD_VS_GET_NEXT_CONN_EVENT_COUNTER = 0xfd14,
- /** @brief See @ref sdc_hci_cmd_vs_allow_parallel_connection_establishments(). */
- SDC_HCI_OPCODE_CMD_VS_ALLOW_PARALLEL_CONNECTION_ESTABLISHMENTS = 0xfd15,
- /** @brief See @ref sdc_hci_cmd_vs_min_val_of_max_acl_tx_payload_set(). */
- SDC_HCI_OPCODE_CMD_VS_MIN_VAL_OF_MAX_ACL_TX_PAYLOAD_SET = 0xfd16,
};
/** @brief VS subevent Code values. */
@@ -102,8 +88,6 @@ enum sdc_hci_subevent_vs
{
/** @brief See @ref sdc_hci_subevent_vs_qos_conn_event_report_t. */
SDC_HCI_SUBEVENT_VS_QOS_CONN_EVENT_REPORT = 0x80,
- /** @brief See @ref sdc_hci_subevent_vs_qos_channel_survey_report_t. */
- SDC_HCI_SUBEVENT_VS_QOS_CHANNEL_SURVEY_REPORT = 0x81,
};
/** @brief Bluetooth roles that are recognized by the coexistence interface. */
@@ -124,19 +108,6 @@ enum sdc_hci_vs_coex_scan_mode
SDC_HCI_VS_COEX_SCAN_MODE_REQUEST_ON_TX = 0x01,
};
-/** @brief Connection Event Trigger Role Selection. */
-enum sdc_hci_vs_conn_event_trigger_role
-{
- /** @brief Unused. */
- SDC_HCI_VS_CONN_EVENT_TRIGGER_ROLE_UNUSED = 0x00,
- /** @brief Connection event trigger for the Scanner. */
- SDC_HCI_VS_CONN_EVENT_TRIGGER_ROLE_SCAN = 0x01,
- /** @brief Connection event trigger for the Initiator. */
- SDC_HCI_VS_CONN_EVENT_TRIGGER_ROLE_INIT = 0x02,
- /** @brief Connection event trigger for connections (Central or Peripheral). */
- SDC_HCI_VS_CONN_EVENT_TRIGGER_ROLE_CONN = 0x03,
-};
-
/** @brief Peripheral latency disable/enable modes. */
enum sdc_hci_vs_peripheral_latency_mode
{
@@ -175,15 +146,8 @@ typedef __PACKED_STRUCT
uint8_t coex_scan_mode_config : 1;
uint8_t peripheral_latency_mode_set : 1;
uint8_t write_remote_tx_power : 1;
+ uint8_t set_auto_power_control_request_param : 1;
uint8_t set_adv_randomness : 1;
- uint8_t qos_channel_survey_enable : 1;
- uint8_t set_power_control_request_params : 1;
- uint8_t read_average_rssi : 1;
- uint8_t central_acl_event_spacing_set : 1;
- uint8_t set_conn_event_trigger : 1;
- uint8_t get_next_conn_event_counter : 1;
- uint8_t allow_parallel_connection_establishments : 1;
- uint8_t min_val_of_max_acl_tx_payload_set : 1;
} sdc_hci_vs_supported_vs_commands_t;
/** @brief Zephyr Static Address type. */
@@ -266,19 +230,6 @@ typedef __PACKED_STRUCT
uint8_t rx_timeout : 1;
} sdc_hci_subevent_vs_qos_conn_event_report_t;
-/** @brief QoS Channel Survey report event.
- *
- * QoS Channel Survey report event
- */
-typedef __PACKED_STRUCT
-{
- /** @brief The measured energy on the Bluetooth Low Energy channels, in dBm, indexed by Channel
- * Index. If no measurement is available for the given channel, channel_energy is set to
- * 127.
- */
- int8_t channel_energy[40];
-} sdc_hci_subevent_vs_qos_channel_survey_report_t;
-
/** @} end of HCI_EVENTS */
/**
@@ -416,7 +367,7 @@ typedef __PACKED_STRUCT
typedef __PACKED_STRUCT
{
/** @brief Connection Handle. */
- uint16_t conn_handle;
+ uint16_t connection_handle;
/** @brief Connection Interval in microseconds. Valid range is 7,500 us to 4,000,000 us in 1,250
* us steps. If LLPM mode is enabled, parameters in the range 1,000 us to 7,000 us in
* 1,000 us steps are also accepted.
@@ -442,7 +393,7 @@ typedef __PACKED_STRUCT
uint8_t enable;
} sdc_hci_cmd_vs_qos_conn_event_report_enable_t;
-/** @brief Set event length for ACL connections command parameter(s). */
+/** @brief Set event length for connections command parameter(s). */
typedef __PACKED_STRUCT
{
/** @brief Allocated event length in microseconds. */
@@ -493,63 +444,33 @@ typedef __PACKED_STRUCT
typedef __PACKED_STRUCT
{
uint16_t conn_handle;
- /** @brief PHY bit number i.e. [1M, 2M, s8, s2] == [1, 2, 3, 4]. */
+ /** @brief Phy value to apply transmit power level adjustment. */
uint8_t phy;
- /** @brief Requested adjustment (in dBm) for the remote to apply to its transmit power. The
- * value can be 0 to utilize the response of the peer to update the information on the
- * transmit power setting of the remote. Note that this is only a request to the peer,
- * which is in control of how, if at all, to apply changes to its transmit power.
- */
+ /** @brief The transmit power level adjustment to request in dBm unit. */
int8_t delta;
} sdc_hci_cmd_vs_write_remote_tx_power_t;
-/** @brief Set advertising randomness command parameter(s). */
-typedef __PACKED_STRUCT
-{
- /** @brief Advertising Handle or 0xFF to set the behavior for the very first advertising event.
- */
- uint8_t adv_handle;
- /** @brief Maximum random delay in microseconds, 0 to disable randomness. */
- uint16_t rand_us;
-} sdc_hci_cmd_vs_set_adv_randomness_t;
-
-/** @brief Set Compatibility mode for window offset command parameter(s). */
-typedef __PACKED_STRUCT
-{
- /** @brief Set to 1 to enable this compatibility mode. */
- uint8_t enable;
-} sdc_hci_cmd_vs_compat_mode_window_offset_set_t;
-
-/** @brief Enable the Quality of Service (QoS) channel survey module. command parameter(s). */
-typedef __PACKED_STRUCT
-{
- /** @brief Set to 0 to disable, 1 to enable, all other values are RFU. */
- uint8_t enable;
- /** @brief Requested average interval for the measurements and reports. Valid range is from 7500
- * to 4000000. If set to 0, the channel survey role will be scheduled at every available
- * opportunity.
- */
- uint32_t interval_us;
-} sdc_hci_cmd_vs_qos_channel_survey_enable_t;
-
-/** @brief Set LE Power Control Request procedure parameters command parameter(s). */
+/** @brief Set Autonomous LE Power Control Request parameters command parameter(s). */
typedef __PACKED_STRUCT
{
/** @brief Enable or Disable controller initiated autonomous LE Power Control Request procedure.
* Disabled by default.
*/
- uint8_t auto_enable;
- /** @brief Enable or Disable received APR handling in controller during LE Power Control Request
- * procedure. Disabled by default.
+ uint8_t enable;
+ /** @brief Beta value used for exponential weighted averaging of RSSI in 12-bit fixed point
+ * fraction. The RSSI is averaged using the following formula, avg[n] = beta * avg[n -
+ * 1] + (1 - beta) * rssi[n] The valid range of beta is [0, 4095]. The beta value used
+ * in computation is beta/4096. For example, for beta to be 0.25 in the above
+ * computation, set the beta parameter in the command to 1024. Default value is 2048.
*/
- uint8_t apr_enable;
- /** @brief The valid range is [0, 4095]. Default value is 2048. */
uint16_t beta;
- /** @brief The lower limit of the RSSI golden range. The RSSI golden range is explained in
- * Core_v5.4, Vol 6, Part B, Section 5.1.17.1. Default value is -70 dBm.
+ /** @brief The lower limit of RSSI golden range that is explained in Core_v5.3, Vol 6, Part B,
+ * Section 5.1.17.1, in dBm units. Default value is -70 dBm.
*/
int8_t lower_limit;
- /** @brief The upper limit of the RSSI golden range. Default value is -30 dBm. */
+ /** @brief The upper limit of RSSI golden range that is explained in Core_v5.3, Vol 6, Part B,
+ * Section 5.1.17.1, in dBm units. Default value is -30 dBm.
+ */
int8_t upper_limit;
/** @brief Target RSSI level in dBm units when the average RSSI level is less than the lower
* limit of RSSI Golden range. Default value is -65 dBm.
@@ -559,93 +480,29 @@ typedef __PACKED_STRUCT
* limit of RSSI Golden range. Default value is -35 dBm.
*/
int8_t upper_target_rssi;
- /** @brief Duration in milliseconds to wait before initiating a new LE Power Control Request
- * procedure by the controller. Default value is 5000 milliseconds. 0 milliseconds value
- * is an invalid value.
+ /** @brief Duration in seconds to wait before initiating a new LE Power Control Request
+ * procedure by the controller. 0 seconds value is an invalid value. Default value is 5
+ * seconds.
*/
- uint16_t wait_period_ms;
- /** @brief Margin between APR value received from peer in LL_POWER_CONTROL_RSP PDU and actual
- * reduction in Transmit power that is applied locally. The applied decrease in local
- * Transmit power will be (received_apr - apr_margin) if received_apr > apr_margin,
- * otherwise no change. Default value is 5 dB.
- */
- uint8_t apr_margin;
-} sdc_hci_cmd_vs_set_power_control_request_params_t;
+ uint8_t wait_period;
+} sdc_hci_cmd_vs_set_auto_power_control_request_param_t;
-/** @brief Read average RSSI command parameter(s). */
-typedef __PACKED_STRUCT
-{
- /** @brief Connection Handle to read the average RSSI for. */
- uint16_t conn_handle;
-} sdc_hci_cmd_vs_read_average_rssi_t;
-
-/** @brief Read average RSSI return parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint16_t conn_handle;
- /** @brief Average RSSI in dBm. */
- int8_t avg_rssi;
-} sdc_hci_cmd_vs_read_average_rssi_return_t;
-
-/** @brief Set Central ACL event spacing command parameter(s). */
-typedef __PACKED_STRUCT
-{
- /** @brief Central ACL event spacing in microseconds. */
- uint32_t central_acl_event_spacing_us;
-} sdc_hci_cmd_vs_central_acl_event_spacing_set_t;
-
-/** @brief Set Connection Event Trigger command parameter(s). */
+/** @brief Set advertising randomness command parameter(s). */
typedef __PACKED_STRUCT
{
- /** @brief Connection handle to set up trigger for. In case @ref
- * sdc_hci_vs_conn_event_trigger_role specifies the Scanner or Initiator, this parameter
- * is ignored.
- */
- uint16_t conn_handle;
- /** @brief Selected role to set triggers for. See @ref sdc_hci_vs_conn_event_trigger_role. */
- uint8_t role;
- /** @brief (D)PPI channel to use. This channel should be regarded as reserved until the
- * connection event (D)PPI task triggering is stopped.
- */
- uint8_t ppi_ch_id;
- /** @brief Task Endpoint to trigger. If this is 0, then the connection event triggering feature
- * is disabled.
+ /** @brief Advertising Handle or 0xFF to set the behavior for the very first advertising event.
*/
- uint32_t task_endpoint;
- /** @brief Connection event counter when the task end point triggering should start. */
- uint16_t conn_evt_counter_start;
- /** @brief The period in events between triggering of the task end point. */
- uint16_t period_in_events;
-} sdc_hci_cmd_vs_set_conn_event_trigger_t;
-
-/** @brief Get Next Connection Event Counter command parameter(s). */
-typedef __PACKED_STRUCT
-{
- /** @brief Connection handle to get the connection event counter value for. */
- uint16_t conn_handle;
-} sdc_hci_cmd_vs_get_next_conn_event_counter_t;
-
-/** @brief Get Next Connection Event Counter return parameter(s). */
-typedef __PACKED_STRUCT
-{
- uint16_t conn_handle;
- uint16_t next_conn_event_counter;
-} sdc_hci_cmd_vs_get_next_conn_event_counter_return_t;
+ uint8_t adv_handle;
+ /** @brief Maximum random delay in microseconds, 0 to disable randomness. */
+ uint16_t rand_us;
+} sdc_hci_cmd_vs_set_adv_randomness_t;
-/** @brief Allow Parallel Connection Establishment command parameter(s). */
+/** @brief Set Compatibility mode for window offset command parameter(s). */
typedef __PACKED_STRUCT
{
+ /** @brief Set to 1 to enable this compatibility mode. */
uint8_t enable;
-} sdc_hci_cmd_vs_allow_parallel_connection_establishments_t;
-
-/** @brief Set the minimum value that will be used as maximum Tx octets for ACL connections command
- * parameter(s).
- */
-typedef __PACKED_STRUCT
-{
- /** @brief Minimum value of maximum ACL TX payload. */
- uint8_t min_val_of_max_acl_tx_payload;
-} sdc_hci_cmd_vs_min_val_of_max_acl_tx_payload_set_t;
+} sdc_hci_cmd_vs_compat_mode_window_offset_set_t;
/** @} end of HCI_COMMAND_PARAMETERS */
@@ -965,25 +822,19 @@ uint8_t sdc_hci_cmd_vs_conn_event_extend(const sdc_hci_cmd_vs_conn_event_extend_
*/
uint8_t sdc_hci_cmd_vs_qos_conn_event_report_enable(const sdc_hci_cmd_vs_qos_conn_event_report_enable_t * p_params);
-/** @brief Set event length for ACL connections.
- *
- * Set the event length for new ACL connections. The event length is the time available for
- * transmission and reception in a single connection event.
- *
- * The maximum data length capabilities will be set based upon this value.
+/** @brief Set event length for connections.
*
- * This API must be called before issuing a command to create a connection,
- * or before starting a connectable advertiser.
+ * Set the event length for new connections. This API must be called before starting a connectable
+ * advertiser or starting an initiator for the event length to applied to the connection once
+ * established.
*
- * The default event length is 7500 us.
+ * The SoftDevice Controller will ensure that the anchor points of master link connections are
+ * spaced
+ * event_length_us apart.
*
- * The event length may be set to a value that is shorter than the time needed
- * for a single packet pair on a given PHY.
- * In that case the controller will reserve time for receiving 27 bytes and transmitting
- * the number of bytes configured with @ref sdc_hci_cmd_vs_min_val_of_max_acl_tx_payload_set().
+ * The default event length is @ref SDC_DEFAULT_EVENT_LENGTH_US.
*
* See also @ref sdc_hci_cmd_vs_conn_event_extend().
- * See also @ref sdc_hci_cmd_vs_central_acl_event_spacing_set().
*
* Event(s) generated (unless masked away):
* When the command has completed, an HCI_Command_Complete event shall be generated.
@@ -1010,7 +861,7 @@ uint8_t sdc_hci_cmd_vs_event_length_set(const sdc_hci_cmd_vs_event_length_set_t
* This API must be called before configuring a periodic advertiser for the event length to be
* applied.
*
- * The default event length is 7500 us.
+ * The default event length is @ref SDC_DEFAULT_EVENT_LENGTH_US.
*
* Event(s) generated (unless masked away):
* When the command has completed, an HCI_Command_Complete event shall be generated.
@@ -1110,6 +961,25 @@ uint8_t sdc_hci_cmd_vs_peripheral_latency_mode_set(const sdc_hci_cmd_vs_peripher
*/
uint8_t sdc_hci_cmd_vs_write_remote_tx_power(const sdc_hci_cmd_vs_write_remote_tx_power_t * p_params);
+/** @brief Set Autonomous LE Power Control Request parameters.
+ *
+ * This command sets the parameters to initiate autonomous LE Power Control Request
+ * procedure by the Link Layer.
+ *
+ * When this command is issued, the controller stores the parameters and
+ * uses them for the subsequent LE Power Control Requests initiated across all the connections.
+ *
+ * Event(s) generated (unless masked away):
+ * When the command has completed, an HCI_Command_Complete event shall be generated.
+ *
+ * @param[in] p_params Input parameters.
+ *
+ * @retval 0 if success.
+ * @return Returns value between 0x01-0xFF in case of error.
+ * See Vol 2, Part D, Error for a list of error codes and descriptions.
+ */
+uint8_t sdc_hci_cmd_vs_set_auto_power_control_request_param(const sdc_hci_cmd_vs_set_auto_power_control_request_param_t * p_params);
+
/** @brief Set advertising randomness.
*
* This vendor specific command is used to change the randomness of advertisers.
@@ -1150,255 +1020,6 @@ uint8_t sdc_hci_cmd_vs_set_adv_randomness(const sdc_hci_cmd_vs_set_adv_randomnes
*/
uint8_t sdc_hci_cmd_vs_compat_mode_window_offset_set(const sdc_hci_cmd_vs_compat_mode_window_offset_set_t * p_params);
-/** @brief Enable the Quality of Service (QoS) channel survey module.
- *
- * This vendor specific command is used to enable or disable the channel survey module.
- *
- * The channel survey module provides measurements of the energy levels on
- * the Bluetooth Low Energy channels. When the module is enabled, @ref
- * sdc_hci_subevent_vs_qos_channel_survey_report_t
- * events will periodically report the measured energy levels for each channel.
- *
- * The measurements are scheduled with lower priority than other Bluetooth Low Energy roles,
- * Radio Timeslot API events and Flash API events.
- *
- * The channel survey module will attempt to do measurements so that the average interval
- * between measurements will be interval_us. However due to the channel survey module
- * having the lowest priority of all roles and modules, this may not be possible. In that
- * case fewer than expected channel survey reports may be given.
- *
- * In order to use the channel survey module, funcref:sdc_support_qos_channel_survey
- * must be called.
- *
- * Event(s) geneated (unless masked away):
- * When the command has completed, an HCI_Command_Complete event shall be generated.
- *
- * @param[in] p_params Input parameters.
- *
- * @retval 0 if success.
- * @return Returns value between 0x01-0xFF in case of error.
- * See Vol 2, Part D, Error for a list of error codes and descriptions.
- */
-uint8_t sdc_hci_cmd_vs_qos_channel_survey_enable(const sdc_hci_cmd_vs_qos_channel_survey_enable_t * p_params);
-
-/** @brief Set LE Power Control Request procedure parameters.
- *
- * This command sets the parameters used in LE Power Control Request
- * procedure by the Link Layer.
- *
- * beta parameter is used to determine the weight of the previous average of RSSI values.
- * A higher value lowers how much the current RSSI weighs into the average, flattening peaks,
- * which also means the controller reacts slower on RSSI changes.
- * The average RSSI is calculated using an exponential weighted averaging in a
- * 12-bit fixed point fraction.
- * avg[n] = gamma * avg[n - 1] + (1 - gamma) * rssi[n]
- * Here, gamma equals beta/4096, and rssi[n] equals the current RSSI.
- * For example, for gamma to be 0.25, set the beta parameter in the command to 1024.
- *
- * Average RSSI and lower_limit parameter are used to calculate APR value the controller sends
- * in LL_POWER_CONTROL_RSP.
- *
- * When auto_enable parameter is set, the controller will keep average RSSI within
- * [lower_limit, upper_limit] bounds. When the average RSSI goes out of these bounds, the
- * controller will autonomously send LL_POWER_CONTROL_REQ requesting to adjust the
- * peer's TX power so average RSSI becomes either lower_target_rssi or upper_target_rssi.
- * The controller will not send such requests more often than specified by wait_period_ms parameter.
- * The wait_period_ms parameter is needed to not repeat send requests for transmit power change
- * without the remote having had the chance to react, as well as to avoid a busy controller.
- * This value should be set depending on needs.
- *
- * When apr_enable parameter is set, the controller will adjust local TX power according to
- * APR value received from the peer in LL_POWER_CONTROL_RSP and the apr_margin parameter.
- *
- * When this command is issued, the controller stores the parameters and
- * uses them for the subsequent LE Power Control Request procedures across all the connections.
- *
- * Event(s) generated (unless masked away):
- * When the command has completed, an HCI_Command_Complete event shall be generated.
- *
- * @param[in] p_params Input parameters.
- *
- * @retval 0 if success.
- * @return Returns value between 0x01-0xFF in case of error.
- * See Vol 2, Part D, Error for a list of error codes and descriptions.
- */
-uint8_t sdc_hci_cmd_vs_set_power_control_request_params(const sdc_hci_cmd_vs_set_power_control_request_params_t * p_params);
-
-/** @brief Read average RSSI.
- *
- * This command reads the average Received Signal Strength Indication (RSSI) value
- * calculated by LE Power Control.
- *
- * The average RSSI is calculated as an exponential weighted average according to
- * the formula given in @ref sdc_hci_cmd_vs_set_power_control_request_params().
- *
- * Event(s) generated (unless masked away):
- * When the command has completed, an HCI_Command_Complete event shall be generated.
- *
- * @param[in] p_params Input parameters.
- * @param[out] p_return Extra return parameters.
- *
- * @retval 0 if success.
- * @return Returns value between 0x01-0xFF in case of error.
- * See Vol 2, Part D, Error for a list of error codes and descriptions.
- */
-uint8_t sdc_hci_cmd_vs_read_average_rssi(const sdc_hci_cmd_vs_read_average_rssi_t * p_params,
- sdc_hci_cmd_vs_read_average_rssi_return_t * p_return);
-
-/** @brief Set Central ACL event spacing.
- *
- * On the central, sets the time ACL connections are spaced apart, assuming they are
- * using the same connection interval.
- *
- * This API must be called before issuing a command to create a connection.
- *
- * The default event spacing is 7500 us.
- * The configured value is retained after issuing a HCI Reset command.
- *
- * Note: The time available for transmission and reception is not configured using this API
- *
- * See also @ref sdc_hci_cmd_vs_event_length_set().
- * See also @ref sdc_hci_cmd_vs_conn_event_extend().
- *
- * Event(s) generated (unless masked away):
- * When the command has completed, an HCI_Command_Complete event shall be generated.
- *
- * @param[in] p_params Input parameters.
- *
- * @retval 0 if success.
- * @return Returns value between 0x01-0xFF in case of error.
- * See Vol 2, Part D, Error for a list of error codes and descriptions.
- */
-uint8_t sdc_hci_cmd_vs_central_acl_event_spacing_set(const sdc_hci_cmd_vs_central_acl_event_spacing_set_t * p_params);
-
-/** @brief Set Connection Event Trigger.
- *
- * Start triggering a given task on radio event start.
- *
- * When enabled, this feature will trigger a (D)PPI task at the start of radio events.
- *
- * When used for connections, the connection event trigger can be configured to trigger
- * every N connection events starting from a given connection event counter.
- *
- * Disabling scanning or disconnecting the connection will reset the connection event
- * trigger configuration.
- *
- * If the selected (D)PPI channel is reserved by the controller, the controller will
- * return the error code Invalid HCI Command Parameters (0x12).
- *
- * If enabling/disabling the connection event trigger and the trigger is already
- * enabled/disabled, the controller will return the error code Command Disallowed (0x0C).
- *
- * If the specified role is not currently active, the controller will return the error code
- * Command Disallowed (0x0C).
- *
- * If the role is 0x3 and conn_handle does not refer to an active connection, the controller
- * will return the error code Unknown Connection Identifier (0x02).
- *
- * If the role is 0x3 and conn_evt_counter_start has already passed, the controller will return
- * the error code Command Disallowed (0x0C).
- *
- * If the role is 0x3 and period_in_events is zero, the controller will return the error code
- * Invalid HCI Command Parameters (0x12).
- *
- * If the role is 0x1 or 0x2 and conn_evt_counter_start or period_in_events is non-zero,
- * the controller will return the error code Invalid HCI Command Parameters (0x12).
- *
- * Event(s) generated (unless masked away):
- * When the command has completed, an HCI_Command_Complete event shall be generated.
- *
- * @param[in] p_params Input parameters.
- *
- * @retval 0 if success.
- * @return Returns value between 0x01-0xFF in case of error.
- * See Vol 2, Part D, Error for a list of error codes and descriptions.
- */
-uint8_t sdc_hci_cmd_vs_set_conn_event_trigger(const sdc_hci_cmd_vs_set_conn_event_trigger_t * p_params);
-
-/** @brief Get Next Connection Event Counter.
- *
- * This command can be used to fetch the upcoming connection event counter value for Centrals or
- * Peripherals.
- *
- * If conn_handle doesn't match an existing connection, the Unknown Connection Identifier (0x02)
- * error code will be returned.
- *
- * Event(s) generated (unless masked away):
- * When the command has completed, an HCI_Command_Complete event shall be generated.
- *
- * @param[in] p_params Input parameters.
- * @param[out] p_return Extra return parameters.
- *
- * @retval 0 if success.
- * @return Returns value between 0x01-0xFF in case of error.
- * See Vol 2, Part D, Error for a list of error codes and descriptions.
- */
-uint8_t sdc_hci_cmd_vs_get_next_conn_event_counter(const sdc_hci_cmd_vs_get_next_conn_event_counter_t * p_params,
- sdc_hci_cmd_vs_get_next_conn_event_counter_return_t * p_return);
-
-/** @brief Allow Parallel Connection Establishment.
- *
- * This command enables the controller to accept establishing connections through
- * the initiator and a periodic advertiser with responses simultaneously.
- *
- * When enabled, HCI commands to create connections may then be used to
- * connect to a synchronized peer while the initiator is running, or to start
- * initiating before a connection establishment to a synchronized device
- * has been completed.
- *
- * By default this functionality is disabled.
- *
- * Event(s) generated (unless masked away):
- * When the command has completed, an HCI_Command_Complete event shall be generated.
- *
- * @param[in] p_params Input parameters.
- *
- * @retval 0 if success.
- * @return Returns value between 0x01-0xFF in case of error.
- * See Vol 2, Part D, Error for a list of error codes and descriptions.
- */
-uint8_t sdc_hci_cmd_vs_allow_parallel_connection_establishments(const sdc_hci_cmd_vs_allow_parallel_connection_establishments_t * p_params);
-
-/** @brief Set the minimum value that will be used as maximum Tx octets for ACL connections.
- *
- * This command sets the minimum value of maximum ACL payload length that can be sent
- * in each packet. If the configured event length is shorter than what is required to
- * send a packet pair of 27 bytes in each direction, the controller will use this value to
- * determine how much it can reduce the payload size to satisfy the event length requirements.
- * LL Control PDUs are not affected by this API.
- *
- * Together with @ref sdc_hci_cmd_vs_event_length_set(), this API allows the controller to schedule
- * ACLs events closer together with other activities.
- *
- * This API must be called before issuing a command to create a connection,
- * or before starting a connectable advertiser.
- *
- * The default and maximum value of this parameter is 27. The minimum supported value
- * of this parameter is 10.
- *
- * Setting this parameter to a lower value will result in more link layer fragmentation,
- * reducing the maximum throughput.
- *
- * Setting this parameter to a value lower than 27 bytes may result in interoperability
- * issues with older Bluetooth products. It is therefore not recommended to use this API
- * for applications interacting with devices qualified for Bluetooth Specification 5.1 or
- * older.
- *
- * The value is preserved when issuing the HCI Reset command.
- *
- * See also @ref sdc_hci_cmd_vs_event_length_set().
- *
- * Event(s) generated (unless masked away):
- * When the command has completed, an HCI_Command_Complete event shall be generated.
- *
- * @param[in] p_params Input parameters.
- *
- * @retval 0 if success.
- * @return Returns value between 0x01-0xFF in case of error.
- * See Vol 2, Part D, Error for a list of error codes and descriptions.
- */
-uint8_t sdc_hci_cmd_vs_min_val_of_max_acl_tx_payload_set(const sdc_hci_cmd_vs_min_val_of_max_acl_tx_payload_set_t * p_params);
-
/** @} end of HCI_VS_API */
/** @} */
diff --git a/softdevice_controller/include/sdc_soc.h b/softdevice_controller/include/sdc_soc.h
index 7a8f428dfb..9cfa771461 100644
--- a/softdevice_controller/include/sdc_soc.h
+++ b/softdevice_controller/include/sdc_soc.h
@@ -10,9 +10,10 @@
* @defgroup sdc_soc SoftDevice Controller SoC Interface
* @ingroup sdc
*
- * The SoftDevice Controller SoC interface provides APIs for block encryption and random numbers.
- * While the SoftDevice Controller is enabled, the application should only use the provided APIs to
- * access NRF_ECB. Not doing so will lead to undefined behavior.
+ * The SoftDevice Controller SoC interface provides APIs for flash access and block encryption
+ * While the SoftDevice Controller is enabled, the application should only use
+ * the provided APIs to access NRF_NVMC or NRF_ECB.
+ * Not doing so will lead to undefined behavior.
* @{
*/
@@ -30,6 +31,72 @@ extern "C" {
#include
#include "nrf_errno.h"
+
+/** @brief Flash command status. */
+enum sdc_soc_flash_cmd_status
+{
+ SDC_SOC_FLASH_CMD_STATUS_SUCCESS = 0,
+ SDC_SOC_FLASH_CMD_STATUS_TIMEOUT = 1,
+};
+
+
+/** @brief Flash command callback.
+ *
+ * The flash command callback will be called when a flash operation is completed.
+ * It will be executed in the same execution priority as @ref mpsl_low_priority_process.
+ *
+ * @param[in] status The status of the flash operation. @sa SDC_SOC_FLASH_CMD_STATUS.
+ */
+typedef void (*sdc_soc_flash_callback_t)(uint32_t status);
+
+
+/** @brief Write data to flash.
+ *
+ * This asynchronous API will ensure that the flash operation will not interfere with radio activity.
+ * The completion will be communicated to the application through the provided callback function.
+ *
+ * @note The data in the p_src buffer should not be modified before the completion callback has
+ * been executed.
+ *
+ * @param[in] addr Flash location to be written.
+ * @param[in] p_src Pointer to buffer with data to be written.
+ * @param[in] size Number of 32-bit words to write. Maximum size is the number of words in one
+ * flash page. See the device's Product Specification for details.
+ * @param[in] on_complete Callback to be called when flash is written.
+ * The callback will be executed in the context as
+ * @ref mpsl_low_priority_process.
+ *
+ * @retval 0 Success
+ * @retval -NRF_EINVAL Either:
+ * - Tried to write to a non existing flash address
+ * - addr or p_src was not word aligned
+ * - Size was 0, or higher than the maximum allowed size
+ * @retval -NRF_EINPROGRESS Previous flash operation is not yet completed
+ */
+int32_t sdc_soc_flash_write_async(uint32_t addr,
+ const void * p_src,
+ uint32_t size,
+ sdc_soc_flash_callback_t on_complete);
+
+
+/** @brief Erase a flash page.
+ *
+ * This asynchronous API will ensure that the flash operation will not interfere with radio activity.
+ * The completion will be communicated to the application through the provided callback function.
+ *
+ * @param[in] addr Start address of the flash page to be erased.
+ * If the address is not aligned with the start of flash page,
+ * the page containing this address will be erased.
+ * @param[in] on_complete Function to be called when page is erased.
+ * The callback will be executed in the context as
+ * @ref mpsl_low_priority_process.
+ *
+ * @retval 0 Success
+ * @retval -NRF_EINVAL Tried to erase a non existing flash page.
+ * @retval -NRF_EINPROGRESS Previous flash operation is not yet completed
+ */
+int32_t sdc_soc_flash_page_erase_async(uint32_t addr, sdc_soc_flash_callback_t on_complete);
+
/** @brief Encrypt a block according to the specified parameters.
*
* The SoftDevice Controller will use NRF_ECB encrypt the block. The encryption type is 128-bit AES.
diff --git a/softdevice_controller/lib/cortex-m33+nodsp/soft-float/libsoftdevice_controller_multirole.a b/softdevice_controller/lib/cortex-m33+nodsp/soft-float/libsoftdevice_controller_multirole.a
index 79ebfad5a8..7f5398a4ac 100644
Binary files a/softdevice_controller/lib/cortex-m33+nodsp/soft-float/libsoftdevice_controller_multirole.a and b/softdevice_controller/lib/cortex-m33+nodsp/soft-float/libsoftdevice_controller_multirole.a differ
diff --git a/softdevice_controller/lib/cortex-m33+nodsp/soft-float/manifest.yaml b/softdevice_controller/lib/cortex-m33+nodsp/soft-float/manifest.yaml
index 60c97576b1..d1dbc5e704 100644
--- a/softdevice_controller/lib/cortex-m33+nodsp/soft-float/manifest.yaml
+++ b/softdevice_controller/lib/cortex-m33+nodsp/soft-float/manifest.yaml
@@ -1,5 +1,5 @@
description: SoftDevice Controller
-git_revision: 136d171100e25d3e2e7e66bdc6c807d8a9eb0307
-ll_subversion_number: '0x2145'
+git_revision: 54781ff3349edbb78544bec8f9431e769df5778f
+ll_subversion_number: '0x2165'
ll_version_number: '0x0D'
-timestamp: '2023-12-22T08:07:20Z'
+timestamp: '2024-01-23T19:45:29Z'
diff --git a/softdevice_controller/lib/cortex-m4/hard-float/libsoftdevice_controller_central.a b/softdevice_controller/lib/cortex-m4/hard-float/libsoftdevice_controller_central.a
index 8eca01cf45..49e83253b2 100644
Binary files a/softdevice_controller/lib/cortex-m4/hard-float/libsoftdevice_controller_central.a and b/softdevice_controller/lib/cortex-m4/hard-float/libsoftdevice_controller_central.a differ
diff --git a/softdevice_controller/lib/cortex-m4/hard-float/libsoftdevice_controller_multirole.a b/softdevice_controller/lib/cortex-m4/hard-float/libsoftdevice_controller_multirole.a
index a75adfc820..bddf088bf5 100644
Binary files a/softdevice_controller/lib/cortex-m4/hard-float/libsoftdevice_controller_multirole.a and b/softdevice_controller/lib/cortex-m4/hard-float/libsoftdevice_controller_multirole.a differ
diff --git a/softdevice_controller/lib/cortex-m4/hard-float/libsoftdevice_controller_peripheral.a b/softdevice_controller/lib/cortex-m4/hard-float/libsoftdevice_controller_peripheral.a
index 45c05922fc..47adde2c2e 100644
Binary files a/softdevice_controller/lib/cortex-m4/hard-float/libsoftdevice_controller_peripheral.a and b/softdevice_controller/lib/cortex-m4/hard-float/libsoftdevice_controller_peripheral.a differ
diff --git a/softdevice_controller/lib/cortex-m4/hard-float/manifest.yaml b/softdevice_controller/lib/cortex-m4/hard-float/manifest.yaml
index 35bbe7848f..e0ec3f8f79 100644
--- a/softdevice_controller/lib/cortex-m4/hard-float/manifest.yaml
+++ b/softdevice_controller/lib/cortex-m4/hard-float/manifest.yaml
@@ -1,5 +1,5 @@
description: SoftDevice Controller
-git_revision: 136d171100e25d3e2e7e66bdc6c807d8a9eb0307
-ll_subversion_number: '0x1145'
+git_revision: 54781ff3349edbb78544bec8f9431e769df5778f
+ll_subversion_number: '0x1165'
ll_version_number: '0x0D'
-timestamp: '2023-12-22T08:00:37Z'
+timestamp: '2024-01-23T19:44:32Z'
diff --git a/softdevice_controller/lib/cortex-m4/soft-float/libsoftdevice_controller_central.a b/softdevice_controller/lib/cortex-m4/soft-float/libsoftdevice_controller_central.a
index 9fbf908371..d42bca7e82 100644
Binary files a/softdevice_controller/lib/cortex-m4/soft-float/libsoftdevice_controller_central.a and b/softdevice_controller/lib/cortex-m4/soft-float/libsoftdevice_controller_central.a differ
diff --git a/softdevice_controller/lib/cortex-m4/soft-float/libsoftdevice_controller_multirole.a b/softdevice_controller/lib/cortex-m4/soft-float/libsoftdevice_controller_multirole.a
index 71f9f54435..eaecd7edb2 100644
Binary files a/softdevice_controller/lib/cortex-m4/soft-float/libsoftdevice_controller_multirole.a and b/softdevice_controller/lib/cortex-m4/soft-float/libsoftdevice_controller_multirole.a differ
diff --git a/softdevice_controller/lib/cortex-m4/soft-float/libsoftdevice_controller_peripheral.a b/softdevice_controller/lib/cortex-m4/soft-float/libsoftdevice_controller_peripheral.a
index 6f37c1db5d..8238589733 100644
Binary files a/softdevice_controller/lib/cortex-m4/soft-float/libsoftdevice_controller_peripheral.a and b/softdevice_controller/lib/cortex-m4/soft-float/libsoftdevice_controller_peripheral.a differ
diff --git a/softdevice_controller/lib/cortex-m4/soft-float/manifest.yaml b/softdevice_controller/lib/cortex-m4/soft-float/manifest.yaml
index 35bbe7848f..e0ec3f8f79 100644
--- a/softdevice_controller/lib/cortex-m4/soft-float/manifest.yaml
+++ b/softdevice_controller/lib/cortex-m4/soft-float/manifest.yaml
@@ -1,5 +1,5 @@
description: SoftDevice Controller
-git_revision: 136d171100e25d3e2e7e66bdc6c807d8a9eb0307
-ll_subversion_number: '0x1145'
+git_revision: 54781ff3349edbb78544bec8f9431e769df5778f
+ll_subversion_number: '0x1165'
ll_version_number: '0x0D'
-timestamp: '2023-12-22T08:00:37Z'
+timestamp: '2024-01-23T19:44:32Z'
diff --git a/softdevice_controller/lib/cortex-m4/softfp-float/libsoftdevice_controller_central.a b/softdevice_controller/lib/cortex-m4/softfp-float/libsoftdevice_controller_central.a
index c3b143ceb7..d7ef36c59c 100644
Binary files a/softdevice_controller/lib/cortex-m4/softfp-float/libsoftdevice_controller_central.a and b/softdevice_controller/lib/cortex-m4/softfp-float/libsoftdevice_controller_central.a differ
diff --git a/softdevice_controller/lib/cortex-m4/softfp-float/libsoftdevice_controller_multirole.a b/softdevice_controller/lib/cortex-m4/softfp-float/libsoftdevice_controller_multirole.a
index a45f321f32..05b23d715e 100644
Binary files a/softdevice_controller/lib/cortex-m4/softfp-float/libsoftdevice_controller_multirole.a and b/softdevice_controller/lib/cortex-m4/softfp-float/libsoftdevice_controller_multirole.a differ
diff --git a/softdevice_controller/lib/cortex-m4/softfp-float/libsoftdevice_controller_peripheral.a b/softdevice_controller/lib/cortex-m4/softfp-float/libsoftdevice_controller_peripheral.a
index befb949599..c718fd40b2 100644
Binary files a/softdevice_controller/lib/cortex-m4/softfp-float/libsoftdevice_controller_peripheral.a and b/softdevice_controller/lib/cortex-m4/softfp-float/libsoftdevice_controller_peripheral.a differ
diff --git a/softdevice_controller/lib/cortex-m4/softfp-float/manifest.yaml b/softdevice_controller/lib/cortex-m4/softfp-float/manifest.yaml
index 35bbe7848f..e0ec3f8f79 100644
--- a/softdevice_controller/lib/cortex-m4/softfp-float/manifest.yaml
+++ b/softdevice_controller/lib/cortex-m4/softfp-float/manifest.yaml
@@ -1,5 +1,5 @@
description: SoftDevice Controller
-git_revision: 136d171100e25d3e2e7e66bdc6c807d8a9eb0307
-ll_subversion_number: '0x1145'
+git_revision: 54781ff3349edbb78544bec8f9431e769df5778f
+ll_subversion_number: '0x1165'
ll_version_number: '0x0D'
-timestamp: '2023-12-22T08:00:37Z'
+timestamp: '2024-01-23T19:44:32Z'
diff --git a/softdevice_controller/limitations.rst b/softdevice_controller/limitations.rst
index 34522d9ae2..1170f29a5a 100644
--- a/softdevice_controller/limitations.rst
+++ b/softdevice_controller/limitations.rst
@@ -6,6 +6,10 @@ Limitations
When working with the SoftDevice Controller, you should be aware of the following limitations.
In addition, see :ref:`nrf:known_issues` for temporary issues that will be fixed in future releases.
+DRGN-17562: One of the LE Transmit Power Reporting Events might not be reported to the host.
+ When multiple LE Transmit Power Reporting Events are generated at the same time for the same PHY, one of these events will be missed.
+ This will occur only when there are simultaneous remote and local power level changes on the same PHY.
+
YOPAN-87: The RSSI value reported by the SoftDevice Controller requires additional temperature compensation
The RSSI value reported by the SoftDevice Controller is the raw value from the radio peripheral.
Some SoCs require compensation of the RSSI value based on the chip temperature.
@@ -61,7 +65,3 @@ DRGN-15989: In some cases, the SDC can connect to the peer it is already connect
DRGN-17724: The AoA transmitter is not supported in LLPM-mode
The AoA transmitter can show unspecified behavior when being used in LLPM-mode.
-
-DRGN-20655: ISO SDUs in Host to Controller direction should not be split into multiple HCI ISO Data packets
- If the Host provides an SDU that has been split into multiple HCI ISO Data packets without a timestamp, the SDC can assign a wrong timestamp to it.
- As a result, this SDU can be never transmitted.