softdevice_controller: rev 3722e7c60757fdbfaddfcd178d108ad6aeca94e1

CHANGELOG.rst contains the list of changes.

Signed-off-by: Martin Tverdal <[email protected]>

mpsl/CHANGELOG.rst

@@ -14,7 +14,8 @@ All the notable changes included in the |NCS| v2.1.3 release are documented in t
 
 Bug fixes
 =========
-* Fixed an issue where the scheduler could put events in the past. (DRGN-17923, DRGN-18105)
+
+* Fixed an issue where the scheduler could put events in the past (DRGN-17923, DRGN-18105).
 
 nRF Connect SDK v2.1.0
 **********************

mpsl/doc/fem.rst

@@ -32,31 +32,30 @@ Simple GPIO
 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
+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 that is applied to the FEM which is needed to achieve the calculated PA gain.
+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
+TX power split using models
 ===========================
 
-The Tx power split can be done using a model.
-This can be done to allow, for example, compensation of external conditions.
-The model can be an external model passed to MPSL or a built-in model.
+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 experimental stage.
+A built-in model is currently provided only for the nRF21540 GPIO SPI FEM implementation and it is in an :ref:`experimental <nrf:software_maturity>` stage.
 The provided model allows for temperature, voltage, and frequency compensation.
 
-The model is passed to MPSL before FEM configuration, and contains two callbacks: ``fetch`` and ``init``.
-After it has finished 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 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
@@ -75,20 +74,20 @@ For the nRF21540, two additional timings can also be configured:
 General usage
 *************
 
-The Power Amplifier and the Low-Noise Amplifier are responsible for, respectively, transmission and reception and are configured and activated independently.
+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/LNA activation and deactivation.
+  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/LNA deactivation.
+  It is any other event type and it can only be used for PA and LNA deactivation.
 
-To prepare a generic event, it is required that the application provides the event register.
-To prepare a timer event, it is required that the application provides the following:
+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.
@@ -97,7 +96,7 @@ To prepare a timer event, it is required that the application provides the follo
 
 Then, the module can configure the timer to activate or deactivate the FEM accordingly, taking also into account the FEM settle time.
 
-See below for an example of activating the LNA for Rx operation, using the following parameters:
+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
@@ -106,20 +105,20 @@ See below for an example of activating the LNA for Rx operation, using the follo
 
 The *RX ramp-up time* is the total time scheduled by the application.
 
-See below for the steps needed to properly configure LNA in this example:
+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``.
+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 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:
 
@@ -135,7 +134,7 @@ In the nRF21540 implementation, the PDN pin is used to power down the FEM intern
 The FEM can be powered down on an explicit application request.
 The FEM is powered back up automatically before PA or LNA are activated.
 
-See below for an example of controlling LNA and PDN during Rx operation, using the following parameters:
+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
@@ -146,23 +145,23 @@ See below for an example of controlling LNA and PDN during Rx operation, using t
 
 The *RX ramp-up time* is the total time scheduled by the application.
 
-See below for the steps needed to properly configure LNA and PDN in this example:
+The steps needed to properly configure LNA and PDN in this example are the following:
 
-* 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 Rx operation.
-* The application starts ``TIMER1``.
+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 LNA and PDN pins for reception
+   :alt: Timing of the LNA and PDN pins for reception
 
-   Timing of LNA and PDN pins for reception
+   Timing of the LNA and PDN pins for reception
 
-The following picture presents the calls between the application, the FEM module, and the hardware in this scenario:
+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
@@ -172,19 +171,22 @@ The following picture presents the calls between the application, the FEM module
 PA gain control
 ===============
 
+FEM implementations with multiple PA gains available can choose which gain to use.
+
 PA switched gain
 ----------------
 
-Optionally, 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 appropriate SPI transfers.
+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.
-For the nRF21540 GPIO SPI implementation, runtime gain control 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 a built-in model.
-Using this model allows for compensation of external conditions like temperature, supply voltage and frequency.
-The model is currently in an experimental stage.
-To use this model, the structure containing the model callbacks needs to be acquired from MPSL by its getter function and then passed to MPSL just like all other models.
+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 <nrf:software_maturity>` 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.

softdevice_controller/CHANGELOG.rst

@@ -9,6 +9,17 @@ Changelog
 
 All the notable changes to this project are documented in this file.
 
+nRF Connect SDK v2.1.3
+**********************
+
+All the notable changes included in the |NCS| v2.1.3 release are documented in this section.
+
+Bug fixes
+=========
+
+* Fixed an issue in MPSL where the controller would assert when a Bluetooth role was running (DRGN-17851).
+* Fixed an issue in MPSL where the controller would abandon a link, causing a disconnect on the remote side (DRGN-18105).
+
 nRF Connect SDK v2.1.2
 **********************
 

softdevice_controller/lib/cortex-m33+nodsp/soft-float/manifest.yaml

@@ -1,5 +1,5 @@
 description: SoftDevice Controller
-git_revision: 295c92f1368192d1b7a9f0f199e94c191f23834a
-ll_subversion_number: '0x21D8'
+git_revision: 3722e7c60757fdbfaddfcd178d108ad6aeca94e1
+ll_subversion_number: '0x21FF'
 ll_version_number: '0x0C'
-timestamp: '2022-10-28T09:05:59Z'
+timestamp: '2022-12-06T08:06:59Z'

softdevice_controller/lib/cortex-m4/hard-float/manifest.yaml

@@ -1,5 +1,5 @@
 description: SoftDevice Controller
-git_revision: 295c92f1368192d1b7a9f0f199e94c191f23834a
-ll_subversion_number: '0x11D8'
+git_revision: 3722e7c60757fdbfaddfcd178d108ad6aeca94e1
+ll_subversion_number: '0x11FF'
 ll_version_number: '0x0C'
-timestamp: '2022-10-28T09:06:02Z'
+timestamp: '2022-12-06T08:08:24Z'

softdevice_controller/lib/cortex-m4/soft-float/manifest.yaml

@@ -1,5 +1,5 @@
 description: SoftDevice Controller
-git_revision: 295c92f1368192d1b7a9f0f199e94c191f23834a
-ll_subversion_number: '0x11D8'
+git_revision: 3722e7c60757fdbfaddfcd178d108ad6aeca94e1
+ll_subversion_number: '0x11FF'
 ll_version_number: '0x0C'
-timestamp: '2022-10-28T09:06:02Z'
+timestamp: '2022-12-06T08:08:24Z'

softdevice_controller/lib/cortex-m4/softfp-float/manifest.yaml

@@ -1,5 +1,5 @@
 description: SoftDevice Controller
-git_revision: 295c92f1368192d1b7a9f0f199e94c191f23834a
-ll_subversion_number: '0x11D8'
+git_revision: 3722e7c60757fdbfaddfcd178d108ad6aeca94e1
+ll_subversion_number: '0x11FF'
 ll_version_number: '0x0C'
-timestamp: '2022-10-28T09:06:02Z'
+timestamp: '2022-12-06T08:08:24Z'