diff --git a/applications/nrf_desktop/bluetooth.rst b/applications/nrf_desktop/bluetooth.rst index e636496329b0..6568d5df34c1 100644 --- a/applications/nrf_desktop/bluetooth.rst +++ b/applications/nrf_desktop/bluetooth.rst @@ -168,7 +168,7 @@ Fast Pair ========= The nRF Desktop peripheral can be built with Google `Fast Pair`_ support. -The configurations that enable Fast Pair are set in the :file:`prj_fast_pair.conf` and :file:`prj_release_fast_pair.conf` files. +The configurations that enable Fast Pair are specified in the files with filenames ending with the ``fast_pair`` and ``release_fast_pair`` suffixes. .. note:: The Fast Pair integration in the nRF Desktop is :ref:`experimental `. @@ -201,6 +201,8 @@ After a successful erase advertising procedure, the peripheral removes all of th Apart from that, the following changes are applied in configurations that support Fast Pair: +* The ``SB_CONFIG_BT_FAST_PAIR`` Kconfig option is enabled in the sysbuild configuration. + For more details about enabling Fast Pair for your application, see the :ref:`ug_bt_fast_pair_prerequisite_ops_kconfig` section in the Fast Pair integration guide. * The static :ref:`partition_manager` configuration is modified to introduce a dedicated non-volatile memory partition used to store the Fast Pair provisioning data. * Bluetooth privacy feature (:kconfig:option:`CONFIG_BT_PRIVACY`) is enabled. * The fast and slow advertising intervals defined in the :ref:`nrf_desktop_ble_adv` are aligned with Fast Pair expectations. diff --git a/applications/nrf_desktop/board_configuration.rst b/applications/nrf_desktop/board_configuration.rst index b6e56e0499ac..c377c4dd5541 100644 --- a/applications/nrf_desktop/board_configuration.rst +++ b/applications/nrf_desktop/board_configuration.rst @@ -17,12 +17,13 @@ The application configuration files define both a set of options with which the Include the following files in this directory: Mandatory configuration files - * Application configuration file for the :ref:`debug build type ` (:file:`prj.conf`). + * Application configuration file for the :ref:`debug build type `. * Configuration files for the selected modules. Optional configuration files * Application configuration files for other build types. * Configuration file for the bootloader. + * Configuration file for the sysbuild. * Memory layout configuration. * DTS overlay file. @@ -43,7 +44,7 @@ nRF52840 Gaming Mouse (``nrf52840gmouse``) * Bluetooth is configured to use Nordic's SoftDevice link layer. * The configuration with the B0 bootloader is set as default. - * The board supports ``debug`` (:file:`prj_fast_pair.conf`) and ``release`` (:file:`prj_release_fast_pair.conf`) :ref:`nrf_desktop_bluetooth_guide_fast_pair` configurations. + * The board supports the ``debug`` (``fast_pair`` file suffix) and ``release`` (``release_fast_pair`` file suffix) configurations for :ref:`nrf_desktop_bluetooth_guide_fast_pair`. Both configurations use the MCUboot bootloader built in the direct-xip mode (``MCUBOOT+XIP``), and they support the firmware updates using the :ref:`nrf_desktop_dfu` and the :ref:`nrf_desktop_dfu_mcumgr`. nRF52832 Desktop Mouse (``nrf52dmouse``) and nRF52810 Desktop Mouse (``nrf52810dmouse``) @@ -58,7 +59,7 @@ Sample mouse, keyboard or dongle (``nrf52840dk/nrf52840``) * The build types allow to build the application as mouse, keyboard or dongle. * Inputs are simulated based on the hardware button presses. * The configuration with the B0 bootloader is set as default. - * The board supports ``debug`` :ref:`nrf_desktop_bluetooth_guide_fast_pair` configuration that acts as a mouse (:file:`prj_fast_pair.conf`). + * The board supports ``debug`` :ref:`nrf_desktop_bluetooth_guide_fast_pair` configuration that acts as a mouse (``fast_pair`` file suffix). The configuration uses the MCUboot bootloader built in the direct-xip mode (``MCUBOOT+XIP``), and supports firmware updates using the :ref:`nrf_desktop_dfu` and the :ref:`nrf_desktop_dfu_mcumgr`. Sample dongle (``nrf52833dk/nrf52833``) @@ -80,7 +81,7 @@ nRF52832 Desktop Keyboard (``nrf52kbd``) * The application is configured to act as a keyboard, with the Bluetooth LE transport enabled. * Bluetooth is configured to use Nordic Semiconductor's SoftDevice link layer. * The preconfigured build types configure the device without the bootloader in debug mode and with B0 bootloader in release mode due to memory size limits. - * The board supports ``release`` :ref:`nrf_desktop_bluetooth_guide_fast_pair` configuration (:file:`prj_release_fast_pair.conf`). + * The board supports ``release`` :ref:`nrf_desktop_bluetooth_guide_fast_pair` configuration (``release_fast_pair`` file suffix). The configuration uses the MCUboot bootloader built in the direct-xip mode (``MCUBOOT+XIP``), and supports firmware updates using the :ref:`nrf_desktop_dfu` and the :ref:`nrf_desktop_dfu_mcumgr`. nRF52840 USB Dongle (``nrf52840dongle/nrf52840``) and nRF52833 USB Dongle (``nrf52833dongle``) @@ -102,7 +103,7 @@ Sample dongle (``nrf5340dk/nrf5340``) Input data comes from Bluetooth and is retransmitted to USB. * The configuration with the B0 bootloader is set as default. -Sample mouse or keyboard (``nrf54l15pdk/nrf54l15/cpuapp``, ``nrf54l15pdk@0.3.0/nrf54l15/cpuapp``) +Sample mouse or keyboard (``nrf54l15pdk/nrf54l15/cpuapp``) * The configuration uses the nRF54L15 Preview Development Kit (PDK). * The build types allow to build the application as a mouse or a keyboard. * Inputs are simulated based on the hardware button presses. diff --git a/applications/nrf_desktop/bootloader_dfu.rst b/applications/nrf_desktop/bootloader_dfu.rst index f50e02004f29..6768e89292ca 100644 --- a/applications/nrf_desktop/bootloader_dfu.rst +++ b/applications/nrf_desktop/bootloader_dfu.rst @@ -72,27 +72,47 @@ See :ref:`nrf_desktop_memory_layout` for details. Configuring the B0 bootloader ============================= -To enable the B0 bootloader, select the :kconfig:option:`CONFIG_SECURE_BOOT` Kconfig option in the application configuration. +To enable the B0 bootloader, select the ``SB_CONFIG_SECURE_BOOT_APPCORE`` Kconfig option in the sysbuild configuration. +This setting automatically enables the ``SB_CONFIG_SECURE_BOOT_BUILD_S1_VARIANT_IMAGE`` Kconfig option, which generates application binaries for both slots in non-volatile memory. -The B0 bootloader additionally requires enabling the following options in the application configuration: +The B0 bootloader additionally requires enabling the following options: -* :kconfig:option:`CONFIG_SB_SIGNING_KEY_FILE` - Required for providing the signature used for image signing and verification. -* :kconfig:option:`CONFIG_FW_INFO` - Required for the application versioning information. -* :kconfig:option:`CONFIG_FW_INFO_FIRMWARE_VERSION` - Enable this option to set the version of the application after you enabled :kconfig:option:`CONFIG_FW_INFO`. - The nRF Desktop application with the B0 bootloader configuration builds two application images: one for the S0 slot and the other for the S1 slot. - To generate the DFU package, you need to update this configuration only in the main application image as the ``s1_image`` child image mirrors it. - You can do that by rebuilding the application from scratch or by changing the configuration of the main image through menuconfig. -* :kconfig:option:`CONFIG_BUILD_S1_VARIANT` - Required for the build system to be able to construct the application binaries for both application's slots in non-volatile memory. +* In the sysbuild configuration: + + * ``SB_CONFIG_SECURE_BOOT_SIGNING_KEY_FILE`` - Required for providing the signature key file used by the build system (to sign the application update images) and by the bootloader (to verify the application signature). + If this Kconfig option does not specify the signature key file, debug signature key files will be used by default. + +* In the application configuration: + + * :kconfig:option:`CONFIG_FW_INFO` - Required for providing information about the application versioning. + * :kconfig:option:`CONFIG_FW_INFO_FIRMWARE_VERSION` - Required for updating the application version. + The nRF Desktop application with the B0 bootloader configuration builds two application images: one for the S0 slot and the other for the S1 slot. + To generate the DFU package, update this configuration only in the main application image. + The ``s1_image`` image will mirror it automatically. + +.. note:: + To ensure that update image will boot after a successful DFU image transfer, the update image's version number must be higher than the version number of the application image running on device. + Otherwise, the update image can be rejected by the bootloader. .. _nrf_desktop_configuring_mcuboot_bootloader: Configuring the MCUboot bootloader ================================== -To enable the MCUboot bootloader, select the :kconfig:option:`CONFIG_BOOTLOADER_MCUBOOT` Kconfig option in the application configuration. +To enable the MCUboot bootloader, select the ``SB_CONFIG_BOOTLOADER_MCUBOOT`` Kconfig option in the sysbuild configuration. -The MCUboot private key path (:kconfig:option:`CONFIG_BOOT_SIGNATURE_KEY_FILE`) must be set only in the MCUboot bootloader configuration file. +You must also set the MCUboot private key path (``SB_CONFIG_BOOT_SIGNATURE_KEY_FILE``) in the sysbuild configuration. The key is used both by the build system (to sign the application update images) and by the bootloader (to verify the application signature using public key derived from the selected private key). +If this Kconfig option is not overwritten in the sysbuild configuration, debug signature key files located in the MCUboot bootloader repository will be used by default. + +To select a specific version of the application, set the :kconfig:option:`CONFIG_MCUBOOT_IMGTOOL_SIGN_VERSION` Kconfig option in the application configuration. +If the nRF Desktop application is configured with the MCUboot in the direct-xip mode, the build system builds two application images: one for the primary slot and the other for the secondary slot, named ``mcuboot_secondary_app``. +You need to update this configuration only in the main application image, as the ``mcuboot_secondary_app`` image mirrors it. + +.. note:: + When the MCUboot bootloader is in the direct-xip mode, the update image must have a higher version number than the application currently running on the device. + This ensures that the update image will be booted after a successful DFU image transfer. + Otherwise, the update image can be rejected by the bootloader. The MCUboot bootloader configuration depends on the selected way of performing image upgrade. For detailed information about the available MCUboot bootloader modes, see the following sections. @@ -116,12 +136,13 @@ Direct-xip mode The direct-xip mode is used for the :ref:`background DFU `. In this mode, the MCUboot bootloader boots an image directly from a given slot, so the swap operation is not needed. -To set the MCUboot mode of operations to the direct-xip mode, make sure to enable the :kconfig:option:`CONFIG_MCUBOOT_BOOTLOADER_MODE_DIRECT_XIP` Kconfig option in the application configuration. -This option automatically enables :kconfig:option:`CONFIG_BOOT_BUILD_DIRECT_XIP_VARIANT` to build application update images for both slots. +To set the MCUboot mode of operations to the direct-xip mode, enable the ``SB_CONFIG_MCUBOOT_MODE_DIRECT_XIP`` Kconfig option in the sysbuild configuration. +This option automatically enables the ``SB_CONFIG_MCUBOOT_BUILD_DIRECT_XIP_VARIANT`` Kconfig option, which builds the application update images for both slots. +The nRF Desktop application configurations do not use the direct-xip mode with the revert mechanism (``SB_CONFIG_MCUBOOT_MODE_DIRECT_XIP_WITH_REVERT``). -Enable the ``CONFIG_BOOT_DIRECT_XIP`` Kconfig option in the bootloader configuration to make the MCUboot run the image directly from both image slots. -The nRF Desktop's bootloader configurations do not enable the revert mechanism (``CONFIG_BOOT_DIRECT_XIP_REVERT``). -When the direct-xip mode is enabled (the :kconfig:option:`CONFIG_MCUBOOT_BOOTLOADER_MODE_DIRECT_XIP` Kconfig option is set in the application configuration), the application modules that control the DFU transport do not request firmware upgrades and do not confirm the running image. +The ``CONFIG_BOOT_DIRECT_XIP`` Kconfig option enables MCUboot to run the image directly from both image slots, and it is automatically applied to the bootloader configuration based on the sysbuild configuration. +Similarly, the :kconfig:option:`CONFIG_MCUBOOT_BOOTLOADER_MODE_DIRECT_XIP` Kconfig option, that informs the application about the MCUboot bootloader's mode, is also applied automatically based on the sysbuild configuration. +When the direct-xip mode is enabled, the application modules that control the DFU transport do not request firmware upgrades or confirm the running image. In that scenario, the MCUboot bootloader simply boots the image with the higher image version. By default, the MCUboot bootloader ignores the build number while comparing image versions. @@ -137,6 +158,7 @@ Serial recovery mode In the :ref:`USB serial recovery ` mode, the MCUboot bootloader uses a built-in foreground DFU transport over serial interface through USB. The application is not involved in the foreground DFU transport, therefore it can be directly overwritten by the bootloader. Because of that, the configuration with the serial recovery mode requires only a single application slot. +To set the MCUboot mode of operations to single application slot, enable the ``SB_CONFIG_MCUBOOT_MODE_SINGLE_APP`` Kconfig option in the sysbuild configuration. Enable the USB serial recovery DFU using the following configuration options: @@ -155,12 +177,12 @@ You must select the ``CONFIG_MCUBOOT_INDICATION_LED`` Kconfig option to enable t By default, both the GPIO pin and the LED are defined in the board's DTS file. See :file:`boards/nordic/nrf52833dongle/nrf52833dongle_nrf52833.dts` for an example of board's DTS file used by the nRF Desktop application. -For an example of bootloader Kconfig configuration file defined by the application, see the MCUboot bootloader ``debug`` configuration defined for nRF52833 dongle (:file:`applications/nrf_desktop/configuration/nrf52833dongle_nrf52833/child_image/mcuboot/prj.conf`). +For an example of a bootloader Kconfig configuration file defined by the application, see the MCUboot bootloader ``debug`` configuration defined for nRF52833 dongle (:file:`applications/nrf_desktop/configuration/nrf52833dongle_nrf52833/images/mcuboot/prj.conf`). .. note:: The nRF Desktop devices use either the serial recovery DFU with a single application slot or the background DFU. Both mentioned firmware upgrade methods are not used simultaneously by any of the configurations. - For example, the ``nrf52840dk/nrf52840`` board in ``prj_mcuboot_smp.conf`` uses only the background DFU and does not enable the serial recovery feature. + For example, the ``nrf52840dk/nrf52840`` board in ``mcuboot_smp`` file suffix uses only the background DFU and does not enable the serial recovery feature. .. _nrf_desktop_suit: @@ -245,13 +267,13 @@ The update image is generated in the build directory when building the firmware MCUboot and B0 bootloaders -------------------------- -The :file:`zephyr/dfu_application.zip` file is used by both B0 and MCUboot bootloader for the background DFU through the :ref:`nrf_desktop_config_channel` and :ref:`nrf_desktop_dfu`. +The :file:`/dfu_application.zip` file is used by both B0 and MCUboot bootloader for the background DFU through the :ref:`nrf_desktop_config_channel` and :ref:`nrf_desktop_dfu`. The package contains firmware images along with additional metadata. If the used bootloader boots the application directly from either slot 0 or slot 1, the host script transfers the update image that can be run from the unused slot. Otherwise, the image is always uploaded to the slot 1 and then moved to slot 0 by the bootloader before boot. .. note:: - Make sure to properly configure the bootloader to ensure that the build system generates the :file:`zephyr/dfu_application.zip` archive containing all of the required update images. + Make sure to properly configure the sysbuild to ensure that the build system generates the :file:`/dfu_application.zip` archive containing all of the required update images. SUIT ---- @@ -369,13 +391,13 @@ Once the device enters the serial recovery mode, you can use the :ref:`mcumgr ` uses the :file:`zephyr/app_update.bin` update image file. + The :ref:`mcumgr ` uses the :file:`/zephyr/nrf_desktop/zephyr.signed.bin` update image file. It is generated by the build system when building the firmware. For example, the following line starts the upload of the new image to the device: .. code-block:: console - mcumgr -t 60 --conntype serial --connstring=/dev/ttyACM0 image upload build-nrf52833dongle/zephyr/app_update.bin + mcumgr -t 60 --conntype serial --connstring=/dev/ttyACM0 image upload build-nrf52833dongle/zephyr/nrf_desktop/zephyr.signed.bin The command assumes that ``/dev/ttyACM0`` serial device is used by the MCUboot bootloader for the serial recovery. diff --git a/applications/nrf_desktop/description.rst b/applications/nrf_desktop/description.rst index 4f8ca5a4c4fb..14ae6f7dd098 100644 --- a/applications/nrf_desktop/description.rst +++ b/applications/nrf_desktop/description.rst @@ -363,7 +363,7 @@ Depending on the development kit you use, you need to select the respective conf .. table-from-rows:: /includes/sample_board_rows.txt :header: heading - :rows: nrf52840dk_nrf52840, nrf52833dk_nrf52833, nrf52833dk_nrf52820, nrf5340dk_nrf5340_cpuapp, nrf54l15pdk_nrf54l15_cpuapp, nrf54l15pdk@0.3.0_nrf54l15_cpuapp, nrf54h20dk_nrf54h20_cpuapp + :rows: nrf52840dk_nrf52840, nrf52833dk_nrf52833, nrf52833dk_nrf52820, nrf5340dk_nrf5340_cpuapp, nrf54l15pdk_nrf54l15_cpuapp, nrf54h20dk_nrf54h20_cpuapp Depending on the configuration, a DK may act either as mouse, keyboard or dongle. For information about supported configurations for each board, see the :ref:`nrf_desktop_board_configuration_files` section. @@ -378,11 +378,12 @@ See :ref:`nrf_desktop_porting_guide` for details. nRF Desktop build types ======================= -The nRF Desktop application does not use a single :file:`prj.conf` file. +The nRF Desktop application uses multiple files to configure each specific build type. +Those files can be easily identified by their :ref:`zephyr:application-file-suffixes`. Before you start testing the application, you can select one of the build types supported by the application. Not every board supports all of the mentioned build types. -See :ref:`app_build_additions_build_types` and :ref:`cmake_options` for more information. +See :ref:`app_build_file_suffixes` and :ref:`cmake_options` for more information. The application supports the following build types: @@ -391,56 +392,56 @@ The application supports the following build types: :header-rows: 1 * - Build type - - File name + - File suffix - Supported board target - Description * - Debug (default) - - :file:`prj.conf` + - none - All from `Requirements`_ - Debug version of the application; the same as the ``release`` build type, but with debug options enabled. * - Release - - :file:`prj_release.conf` + - ``release`` - All from `Requirements`_ - Release version of the application with no debugging features. * - Debug Fast Pair - - :file:`prj_fast_pair.conf` + - ``fast_pair`` - ``nrf52840dk/nrf52840``, ``nrf52840gmouse/nrf52840`` - Debug version of the application with `Fast Pair`_ support. * - Release Fast Pair - - :file:`prj_release_fast_pair.conf` + - ``release_fast_pair`` - ``nrf52kbd/nrf52832``, ``nrf52840gmouse/nrf52840`` - Release version of the application with `Fast Pair`_ support. * - Dongle - - :file:`prj_dongle.conf` + - ``dongle`` - ``nrf52840dk/nrf52840`` - Debug version of the application that lets you generate the application with the dongle role. * - Keyboard - - :file:`prj_keyboard.conf` + - ``keyboard`` - ``nrf52840dk/nrf52840`` - Debug version of the application that lets you generate the application with the keyboard role. * - MCUboot QSPI - - :file:`prj_mcuboot_qspi.conf` + - ``mcuboot_qspi`` - ``nrf52840dk/nrf52840`` - Debug version of the application that uses MCUboot with the secondary slot in the external QSPI FLASH. * - MCUboot SMP - - :file:`prj_mcuboot_smp.conf` + - ``mcuboot_smp`` - ``nrf52840dk/nrf52840``, ``nrf52840gmouse/nrf52840`` - | Debug version of the application that enables MCUmgr with DFU support and offers support for the MCUboot DFU procedure over SMP. | See the :ref:`nrf_desktop_bootloader_background_dfu` section for more information. * - WWCB - - :file:`prj_wwcb.conf` + - ``wwcb`` - ``nrf52840dk/nrf52840`` - Debug version of the application with the support for the B0 bootloader enabled for `Works With ChromeBook (WWCB)`_. * - Triple Bluetooth LE connection - - :file:`prj_3bleconn.conf` + - ``3bleconn`` - ``nrf52840dongle/nrf52840`` - Debug version of the application with the support for up to three simultaneous Bluetooth LE connections. * - Quadruple LLPM connection - - :file:`prj_4llpmconn.conf` + - ``4llpmconn`` - ``nrf52840dongle/nrf52840`` - Debug version of the application with the support for up to four simultaneous Bluetooth LE connections, in Low Latency Packet Mode. * - Release quadruple LLPM connection - - :file:`prj_release_4llpmconn.conf` + - ``release_4llpmconn`` - ``nrf52840dongle/nrf52840`` - Release version of the application with the support for up to four simultaneous Bluetooth LE connections, in Low Latency Packet Mode. @@ -900,7 +901,7 @@ Selecting a build type ====================== Before you start testing the application, you can select one of the :ref:`nrf_desktop_requirements_build_types`, depending on your development kit. -See :ref:`cmake_options` for information about how to select a build type. +See :ref:`app_build_file_suffixes` and :ref:`cmake_options` for information about how to select a build type. .. note:: If nRF Desktop is built with `Fast Pair`_ support, you must provide Fast Pair Model ID and Anti Spoofing private key as CMake options. @@ -1009,7 +1010,7 @@ You can use any preferred HID report rate tool. Building information ~~~~~~~~~~~~~~~~~~~~ -Use the :file:`prj_release.conf` configuration for the HID report rate measurement. +Use the configuration with the ``release`` file suffix for the HID report rate measurement. Debug features, such as logging or assertions, decrease the application performance. Use the nRF Desktop configuration that acts as a HID mouse reference design for the report rate measurement, as the motion data polling is synchronized with sending HID reports. diff --git a/applications/nrf_desktop/doc/dfu.rst b/applications/nrf_desktop/doc/dfu.rst index bb4672380279..cfbe1cc6955a 100644 --- a/applications/nrf_desktop/doc/dfu.rst +++ b/applications/nrf_desktop/doc/dfu.rst @@ -64,9 +64,7 @@ In that case, the DFU module assumes that the MCUboot direct-xip bootloader simp The :ref:`CONFIG_DESKTOP_CONFIG_CHANNEL_DFU_MCUBOOT_DIRECT_XIP ` option is used to inform the DFU module that the device uses the MCUboot bootloader in the direct-xip mode. If the option is enabled, the DFU module reports the ``MCUBOOT+XIP`` bootloader name instead of ``MCUBOOT`` to indicate that the bootloader working in the direct-xip mode is used. The option depends on enabling the MCUboot bootloader (:kconfig:option:`CONFIG_BOOTLOADER_MCUBOOT`) and is enabled by default if the MCUboot direct-xip mode of operations is set (:kconfig:option:`CONFIG_MCUBOOT_BOOTLOADER_MODE_DIRECT_XIP`). - -.. note:: - The configured MCUboot bootloader mode needs to be manually aligned for both bootloader and application image. +See the :ref:`nrf_desktop_bootloader` section for more information on the MCUboot bootloader configuration. Device identification information ================================= diff --git a/applications/nrf_desktop/memory_layout.rst b/applications/nrf_desktop/memory_layout.rst index 14583cee9c3e..f0e3a00768ce 100644 --- a/applications/nrf_desktop/memory_layout.rst +++ b/applications/nrf_desktop/memory_layout.rst @@ -14,7 +14,7 @@ The set of required partitions differs depending on the configuration: * There must be one partition for storing :ref:`zephyr:settings_api`. * If the bootloader is enabled, it adds more partitions to the set. * When using an SoC with multiple cores, the firmware for additional cores adds more partitions to the set. - For example, the network core of the nRF53 SoC uses the ``HCI IPC`` firmware image, which allows to use the core for Bluetooth LE communication. + For example, the network core of the nRF53 SoC uses the :ref:`ipc_radio` image, which allows to use the core for Bluetooth LE communication. .. important:: Before updating the firmware, make sure that the data stored in the settings partition is compatible with the new firmware. @@ -58,7 +58,7 @@ Memory layout in Partition Manager When the :kconfig:option:`CONFIG_PARTITION_MANAGER_ENABLED` Kconfig option is enabled, the nRF Desktop application uses the Partition Manager for the memory layout configuration. The nRF Desktop configurations use static configurations of partitions to ensure that the partition layout does not change between builds. -Add the :file:`pm_static_${BUILD_TYPE}.yml` file to the project's board configuration directory to define the static Partition Manager configuration for given board and build type. +Add the :file:`pm_static_${FILE_SUFFIX}.yml` file to the project's board configuration directory to define the static Partition Manager configuration for given board and build type. For example, to define the static partition layout for the ``nrf52840dk/nrf52840`` board and ``release`` build type, you would need to add the :file:`pm_static_release.yml` file into the :file:`applicatons/nrf_desktop/configuration/nrf52840dk_nrf52840` directory. Take into account the following points: @@ -83,6 +83,7 @@ The Partition Manager supports partitions in external flash. Enabling external flash can be useful especially for memory-limited devices. For example, the MCUboot can use it as a secondary image partition for the :ref:`background firmware upgrade `. The MCUboot moves the image data from the secondary image partition to the primary image partition before booting the new firmware. +To use external flash for the secondary image partition, in addition to defining the proper static Partition Manager configuration, you must enable the ``SB_CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY`` Kconfig option in the sysbuild configuration. For an example of the nRF Desktop application configuration that uses an external flash, see the ``mcuboot_qspi`` configuration of the nRF52840 Development Kit (DK). This configuration uses the ``MX25R64`` external flash that is part of the development kit. diff --git a/applications/nrf_desktop/nRF21540ek_support.rst b/applications/nrf_desktop/nRF21540ek_support.rst index 3983e461b790..18c8bcd55ebe 100644 --- a/applications/nrf_desktop/nRF21540ek_support.rst +++ b/applications/nrf_desktop/nRF21540ek_support.rst @@ -30,11 +30,11 @@ For example, you can build the application for ``nrf52840dk/nrf52840`` with ``nr For the multi-core build, you need to pass the ``SHIELD`` parameter to images built on both application and network core. The network core controls the FEM, but the application core needs to forward the needed pins to the network core. -Use ``hci_ipc_`` as the *childImageName* parameter, because in the nRF Desktop application, network core runs using ``hci_ipc_``. +Use ``ipc_radio_`` as the *image_name* parameter, because in the nRF Desktop application, network core runs using :ref:`ipc_radio`. The command for ``nrf5340dk/nrf5340/cpuapp`` with ``nrf21540ek`` shield would look as follows: .. code-block:: console - west build -b nrf5340dk/nrf5340/cpuapp -- -DSHIELD=nrf21540ek_fwd -Dhci_ipc_SHIELD=nrf21540ek -DCONFIG_CAF_BLE_USE_LLPM=n + west build -b nrf5340dk/nrf5340/cpuapp -- -DSHIELD=nrf21540ek_fwd -Dipc_radio_SHIELD=nrf21540ek -DCONFIG_CAF_BLE_USE_LLPM=n For detailed information about building an application using the nRF21540 EK, see the :ref:`ug_radio_fem_nrf21540ek_programming` section in the Working with RF Front-end modules documentation.