Firmware patches in the external memory

This guide explains the available options for having the nRF70 Series firmware patches reside in the external memory.

Note

The Partition Manager is a component in the nRF Connect SDK and is responsible for handling the memory partitioning at build time.

This functionality is in the process of being deprecated and replaced by Zephyr’s default devicetree-based memory partitioning. It is recommended that all new designs using Nordic devices, excluding the nRF91 Series devices, are to be built with DTS instead of Partition Manager. Partition Manager will be removed from the nRF Connect SDK by the end of 2026 from the main branch.

For more information on how to configure partitions using DTS and how to migrate your existing configuration to DTS, see the following pages:

Note

External memory refers to the memory that is outside the SoC, for example, an external flash memory chip, or external non-volatile memory (NVM) chip.

Overview

By default, the nRF70 Series firmware patches are built as part of sysbuild, residing in on-chip memory. The firmware patches include code that is executed on the nRF70 Series device. The size of the firmware patches might be considerably large, which limits the amount of on-chip code memory available for the user application. In order to increase the amount of on-chip memory available for user applications, the nRF Wi-Fi driver supports the option of using external memory, if that is available.

Prerequisites

Before using this feature, make sure that the following prerequisites are completed:

  • The external memory must be available and configured in the devicetree.

  • The external memory must be large enough to store the firmware patches, taking into consideration also the patch upgrade requirement, for example, Device Firmware Update (DFU). The maximum size of all the firmware patches combined is 128 KB.

Supported platforms

The following platforms are supported:

  • nRF5340 DK with nRF7002 EK as a shield

  • nRF52840 DK with nRF7002 EK as a shield

  • nRF7002 DK (requires latest version of nRF Util tool)

Available options

There are two supported options for offloading the firmware patches in the external memory feature:

  • Using XIP access

  • Using (Q)SPI transfers to RAM

Note

The nRF7002 DK does not support the XIP access option.

Using XIP access

If the application supports XIP from external memory, then the firmware patches can be loaded as part of the nRF Wi-Fi driver code (RODATA) and then relocated to the external memory. The nRF Wi-Fi driver accesses the firmware patches using XIP feature and downloads the firmware patches to the nRF70 device. To enable this feature, set the SB_CONFIG_WIFI_PATCHES_EXT_FLASH_XIP sysbuild Kconfig option to y. Once the build is complete, the feature can be verified by checking the memory regions summary in the build output. A new memory region called EXTFLASH is added to the memory regions summary, and the firmware patches are placed in this region. The size of the FLASH used is reduced by the size of the firmware patches.

Following is a sample summary of the memory regions:

Memory region         Used Size  Region Size  %age Used
      EXTFLASH:       64544 B         8 MB      0.77%
         FLASH:      618752 B         1 MB     59.01%
           RAM:      170636 B       448 KB     37.20%
      IDT_LIST:          0 GB         2 KB      0.00%

Using (Q)SPI transfers to RAM

The nRF Wi-Fi driver supports the option for offloading the nRF70 firmware patch to external non-XIP memory. In this case the upload of the firmware patch from the external memory to the nRF70 device happens in two stages:

  1. The firmware patch is loaded from the external memory onto internal RAM.

  2. The firmware patch is uploaded to the nRF70 device.

You can enable this feature using the Snippets feature.

Configuration

The following configuration options are available:

You must define the firmware patch region in devicetree so that the build can place the image and the driver can locate it. The partition node must use the node label nrf70_wifi_fw_partition (see the nrf70-fw-patch-ext-flash snippet overlay).

&mx25r64 {
        partitions {
                compatible = "fixed-partitions";
                #address-cells = <1>;
                #size-cells = <1>;

                nrf70_wifi_fw_partition: nrf70_fw_partition: partition@0 {
                        reg = <0x0 0x20000>;
                };
        };
};

Adjust the parent node (for example, &mx25r64), as well as the offsets and sizes, to match your board’s external flash layout. The nrf70-fw-patch-ext-flash snippet provides a working starting point, together with the devicetree chosen property nordic,pm-ext-flash.

Building

See Developing with nRF70 Series for general instructions on building.

Additionally, you can build the sample using the nrf70-fw-patch-ext-flash snippet and set the SB_CONFIG_WIFI_PATCHES_EXT_FLASH_STORE Kconfig option to y.

For example, to build the Wi-Fi: Shell sample for the nRF5340 DK with the nrf70-fw-patch-ext-flash snippet enabled, run the following commands.

With west
west build -p -b nrf5340dk/nrf5340/cpuapp samples/wifi/shell -- -Dshell_SHIELD=nrf7002ek -Dshell_SNIPPET="nrf70-fw-patch-ext-flash"
With CMake
cmake -GNinja -Bbuild -DBOARD=nrf5340dk/nrf5340/cpuapp -Dshell_SHIELD=nrf7002ek -Dshell_SNIPPET="nrf70-fw-patch-ext-flash"
ninja -C build

Programming

To program the firmware image with the firmware patches stored in the external memory, use the following commands.

With west

No changes are needed to the programming command:

west flash
With other tools

You must use the merged.hex file instead of the zephyr.hex file to choose the program image explicitly.

For example, for nRF Util:

nrfutil device program --x-family nrf53 --options chip_erase_mode=ERASE_RANGES_TOUCHED_BY_FIRMWARE,qspi_erase_mode=ERASE_ALL,verify=VERIFY_HASH,reset=RESET_SOFT --firmware build/merged.hex

Updating firmware patches

You can update the firmware patches using all available DFU alternatives described in the main MCUboot and NSIB page. To do it, you need to use MCUboot bootloader and create proper partitions to allow storing and replacing the firmware patches.

To learn how to prepare your application and perform the firmware patch update, see the Firmware patch update page.