Using MCUBoot with nRF5340

RE: Using MCUBoot with nRF5340

a.tv — Thu, 11 Sep 2025 10:41:09 GMT

Hej!
I wanted to thank you for this example! It's the only example that I found that actually worked for my 5340 board and it gave me a lot of inspiration on how I need to configure my project.

Thanks a lot!

RE: Using MCUBoot with nRF5340

Vidar Berg — Tue, 22 Oct 2024 12:03:13 GMT

Hi Torsten,

[quote user="Torsten Robitzki"]Thanks for the example, but it doesn't build correctly (board is unknown). When I change the board to `nrf5340dk/nrf5340/cpuapp` I get some configuration warnings:[/quote]

Sorry, I see now that it is only compatible with the SPI NOR driver, not the QSPI NOR driver. This means that if you want to test it, you would have to place the external flash device on a SPI bus and use the `jedec,spi-nor` binding instead of "nordic,qspi-nor". The SPI flash sample works with QSPI, but it does not read the JDEC information.

[quote user="Torsten Robitzki"]That's the major problem with examples. You never know, which bit is really important. Is the name of the key file important? Sure, I could have copied your entire example, but then I would also end up with an application, that does exactly what your example does. Unfortunately, that's not what my customer needs ;-)[/quote]

I understand the challenges, and I hope this is something we can improve on. This is particularly a problem with the 53 series, as there are quite a few additional configuration options to handle multi-image DFU.

Best regards,

Vidar

RE: Using MCUBoot with nRF5340

Torsten Robitzki — Tue, 22 Oct 2024 11:11:45 GMT

Hi Vidar,

the linker error above happens, when I use a different name for the external flash memory. Only, when I name that chip mx25r64, I do not get that linker error.

Thanks for the example, but it doesn't build correctly (board is unknown). When I change the board to `nrf5340dk/nrf5340/cpuapp` I get some configuration warnings:

warning: SPI_NOR (defined at soc/gaisler/gr716a/Kconfig.defconfig:18, drivers/flash/Kconfig.nor:4)
was assigned the value 'y' but got the value 'n'. Check these unsatisfied dependencies: ((FLASH &&
SOC_GR716A) || (DT_HAS_JEDEC_SPI_NOR_ENABLED && FLASH))

The `CONFIG_NORDIC_QSPI_NOR` configuration was explicitly set to `y`. Then I change the device name to `flash_ext: MT25QU01GBBB@0 `:

&qspi {
    /*
     * Name of the device has to be mx25r64; Otherwise,
     * the driver is not found during linking
     */
/*    mx25r64: mx25r6435f@0 {*/
    flash_ext: MT25QU01GBBB@0 {
        compatible = "nordic,qspi-nor";
        reg = < 0x0 >;
        writeoc = "pp4io";
        readoc = "read4io";
        sck-frequency = < 90000000 >;
        jedec-id = [ 20 BB 21 ];
        sfdp-bfp = [ E5 20 F1 FF FF FF FF 03 44 EB 08 6B 08 3B 04 BB EE FF FF FF FF FF 00 FF FF FF 00 FF 0C 20 0F 52 10 D8 00 FF 23 72 F5 00 82 ED 04 CC 44 83 68 44 30 B0 30 B0 F7 C4 D5 5C 00 BE 29 FF F0 D0 FF FF ];
        size = < 0x8000000 >;
        has-dpd;
        t-enter-dpd = < 0x2710 >;
        t-exit-dpd = < 0x88b8 >;
    };
};

/ {
    chosen {
/*        nordic,pm-ext-flash = &mx25r64;*/
        nordic,pm-ext-flash = &flash_ext;
    };
};

I get an undefined symbol to `__device_dts_ord_142`.

Yes, your example used `SB_CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y` and I even tried that setting and your keys on my course to find some configuration that builds. And as soon as it build, I changed it back to my keys and thus to the algorithm, I've picked.

That's the major problem with examples. You never know, which bit is really important. Is the name of the key file important? Sure, I could have copied your entire example, but then I would also end up with an application, that does exactly what your example does. Unfortunately, that's not what my customer needs ;-)

Anyway: Thanks a lot! This was extremely helpful. Thanks for your patience! I think, we can close this.

best regards

Torsten

RE: Using MCUBoot with nRF5340

Vidar Berg — Tue, 22 Oct 2024 10:16:23 GMT

Hi Torsten,

[quote user="Torsten Robitzki"]my idea, was to define some device, similar to the mx25r64 (with a changed jedec-id, frequency, etc.) and then to pick that device with the `nordic,pm-ext-flash` in the chosen section:[/quote]

Thanks for the clarification. The name should not matter as long as the actual configuration parameters match your flash ic. The JESD216 flash sample can be used to verify the configuration.

[quote user="Torsten Robitzki"]

but this results in a linker error: "undefined reference to `__device_dts_ord_142`"

When I rename the device above to `mx25r64: mx25r6435f@0`, everything works fine (including the jedec test in the driver). So anyway, I have a solution. I will add some comment to the configuration.

[/quote]

The error suggests that the Kconfig symbol for this driver is not enabled (https://docs.zephyrproject.org/latest/build/dts/troubleshooting.html#undefined-reference-to-device-dts-ord-n). I assume '142' is referring to the flash_ext node in your build. So maybe CONFIG_NORDIC_QSPI_NOR did not get selected?

[quote user="Torsten Robitzki"]

For the bootloader itself: I found out, after some lengthy debugging, that the primary image was flashed with a RSA3072 hash, while MCUBoot was looking for a RSA2048 hash. The MCUBoot error message was: "Image in the primary slot is not valid!".

After changing algorithm and key to ECDSA_P256, the bootloader is starting the application.

[/quote]

I would have assumed that this would lead to a build error, but it seems like that is not the case. I had SB_CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y in my sample.

Best regards,

Vidar

RE: Using MCUBoot with nRF5340

Torsten Robitzki — Mon, 21 Oct 2024 14:59:34 GMT

Hi Vidar,

my idea, was to define some device, similar to the mx25r64 (with a changed jedec-id, frequency, etc.) and then to pick that device with the `nordic,pm-ext-flash` in the chosen section:

&qspi {
    flash_ext: MT25QU01GBBB@0 {
        compatible = "nordic,qspi-nor";
        reg = < 0x0 >;
        writeoc = "pp4io";
        readoc = "read4io";
        sck-frequency = < 90000000 >;
        jedec-id = [ 20 BB 21 ];
        sfdp-bfp = [ E5 20 F1 FF FF FF FF 03 44 EB 08 6B 08 3B 04 BB EE FF FF FF FF FF 00 FF FF FF 00 FF 0C 20 0F 52 10 D8 00 FF 23 72 F5 00 82 ED 04 CC 44 83 68 44 30 B0 30 B0 F7 C4 D5 5C 00 BE 29 FF F0 D0 FF FF ];
        size = < 0x4000000 >;
        has-dpd;
        t-enter-dpd = < 0x2710 >;
        t-exit-dpd = < 0x88b8 >;
    };
};

/ {
    chosen {
        nordic,pm-ext-flash = &flash_ext;
    };
};

but this results in a linker error: "undefined reference to `__device_dts_ord_142`"

When I rename the device above to `mx25r64: mx25r6435f@0`, everything works fine (including the jedec test in the driver). So anyway, I have a solution. I will add some comment to the configuration.

After changing algorithm and key to ECDSA_P256, the bootloader is starting the application.

Thanks a lot for your help,

Torsten

RE: Using MCUBoot with nRF5340

Vidar Berg — Mon, 21 Oct 2024 10:09:53 GMT

Hi Torsten,

[quote user="Torsten Robitzki"]I managed to add the used external NOR flash chip to the configuration (I had to name it mx25r64, even thought, it is a totally different chip.[/quote]

The chosen must point to the flash device you have in your QSPI devictree node if it is not the same as the one on the DK.

[quote user="Torsten Robitzki"]Now, all binaries (Application, Network, MCUBoot and b0n) are building. The bootloader starts, but refuses to start the binary in the primary slot:[/quote]

Please create a new file named mcuboot.conf in your sysbuild folder that contain the following lines:

# Configure MCUboot features
CONFIG_BOOT_MAX_IMG_SECTORS=256
CONFIG_MCUBOOT_DOWNGRADE_PREVENTION=y
CONFIG_BOOT_ECDSA_TINYCRYPT=y

# Enable flash simulator
CONFIG_PCD_APP=y
CONFIG_FLASH_SIMULATOR=y
CONFIG_FLASH_SIMULATOR_DOUBLE_WRITES=y
CONFIG_FLASH_SIMULATOR_STATS=n

CONFIG_NORDIC_QSPI_NOR=y
CONFIG_NORDIC_QSPI_NOR_FLASH_LAYOUT_PAGE_SIZE=4096

CONFIG_BOOT_IMAGE_ACCESS_HOOKS=y
CONFIG_BOOT_IMAGE_ACCESS_HOOK_NRF5340=y

CONFIG_MULTITHREADING=y

The do a pristine build.

Best regards,

Vidar

RE: Using MCUBoot with nRF5340

Torsten Robitzki — Mon, 21 Oct 2024 09:07:58 GMT

Hi Vidar,

I managed to add the used external NOR flash chip to the configuration (I had to name it mx25r64, even thought, it is a totally different chip. Otherwise, I got linker errors: `undefined reference to `__device_dts_ord_142'`).

Now, all binaries (Application, Network, MCUBoot and b0n) are building. The bootloader starts, but refuses to start the binary in the primary slot:

00> *** Booting MCUboot v2.1.0-dev-f30dce197f34 ***
00> *** Using nRF Connect SDK v2.7.99-cs2-d73b286ff6d9 ***
00> *** Using Zephyr OS v3.6.99-1b696c108812 ***
00> [00:00:00.324,035] <inf> mcuboot: Starting bootloader
00> [00:00:00.324,432] <wrn> mcuboot: Failed reading sectors; BOOT_MAX_IMG_SECTORS=128 - too small?
00> [00:00:00.325,195] <inf> mcuboot: Image index: 1, Swap type: none
00> [00:00:00.325,500] <err> mcuboot: Image in the primary slot is not valid!
00> [00:00:00.325,531] <err> mcuboot: Unable to find bootable image

At the primaries start address, there is an application (at least it looks like a vector table). So I guess, that MCUBoot is not able to correctly verify the image.

During the build of MCUboot, there are log messages, that indicate, that the bootloader is build with the correct keys embedded:

MCUBoot bootloader key file: <absoulte path to pem file>
MCUBoot bootloader encryption key file: <absoulte path to pem file>

While during the build of the application, I see this warning, that let me suspect, that maybe for the build of the application an other key is used.

      --------------------------------------------------------------
      --- WARNING: Using generated NSIB public/private key-pair. ---
      --- It should not be used for production.                  ---
      --- See SB_CONFIG_SECURE_BOOT_SIGNING_KEY_FILE             ---
      --------------------------------------------------------------

Interesting enough, I saw the same discrepancy with your example. So, I toke an nRF5340 eval board and installed your example. But in that case, the application is running (I see a blinking LED and a connectable BLE service).

As the primary is stored in internal flash memory, I suspect, that it could not be a problem of the configuration of the external flash memory.

Any idea, as to what could be the problem here?

best regards

Torsten

RE: Using MCUBoot with nRF5340

Vidar Berg — Fri, 18 Oct 2024 13:20:31 GMT

[quote userid="4223" url="~/f/nordic-q-a/115570/using-mcuboot-with-nrf5340/506935"]Ok, got it now, I missed, that I have to add the same overlay snipped to the configuration of the bootloader (which totally makes sense). As we are not going to support different hardwares, this probably does not need to be as complicated as in your example.[/quote]

In that case, you can just add a file named 'mcuboot.overlay' in the sybuild directory which contains the lines below. Just remember to do a pristine/clean build after adding it to allow the build system to detect it.

/ {
	chosen {
		nordic,pm-ext-flash = &mx25r64;
	};
};

You too! thanks!

RE: Using MCUBoot with nRF5340

Torsten Robitzki — Fri, 18 Oct 2024 13:11:59 GMT

Yes, there is a QSPI nor flash on the device and it works. No, haven't managed, to get that into the final dts file. It is in the final dts file of your example.

Ok, got it now, I missed, that I have to add the same overlay snipped to the configuration of the bootloader (which totally makes sense). As we are not going to support different hardwares, this probably does not need to be as complicated as in your example. Will figure out, how to do that and will report progress.

Thanks a lot for your help!!! :-) I wish you a nice and relaxing weekend!

RE: Using MCUBoot with nRF5340

Vidar Berg — Fri, 18 Oct 2024 13:05:00 GMT

The settings you listed are not relevant to the problem. Does you have a QSPI flash device on your device?

[quote userid="4223" url="~/f/nordic-q-a/115570/using-mcuboot-with-nrf5340/506929"]Does this nordic_pm_ext_flash maps to `nordic,pm-ext-flash = &mx25r64;` in the chosen section?[/quote]

Yes. Did you manage to add this chosen for your bootloader?

RE: Using MCUBoot with nRF5340

Torsten Robitzki — Fri, 18 Oct 2024 12:59:38 GMT

Sorry, but I can not directly use your configuration (that's a general problem of this documentation-by-example approach), because I have an application, that requires certain configurations and I need to somehow merge your configurations with the ones, required by my app.

`CONFIG_NCS_SAMPLES_DEFAULTS` was applied for testing. Later, I probably have to remove this "catch-all" option and have to figure out, which parts of this are relevant.

`CONFIG_BT`, `CONFIG_BT_PERIPHERAL` have the same values, `CONFIG_BT_DEVICE_NAME` is set, but to a different value.

`CONFIG_BT_LBS`, `CONFIG_BT_LBS_POLL_BUTTON` and `CONFIG_DK_LIBRARY` are not used, as I don't want to receive the firmware updates via that BLE service.

`CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE` is set to the exact value.

Adding `CONFIG_NCS_SAMPLES_DEFAULTS` does not solve the issue.

I made an other observation: When I change the device name in `device: DT_CHOSEN(nordic_pm_ext_flash)` from the `pm_static.yml` into something, that not exists, I do not get any build errors.

Does this nordic_pm_ext_flash maps to `nordic,pm-ext-flash = &mx25r64;` in the chosen section?

RE: Using MCUBoot with nRF5340

Vidar Berg — Fri, 18 Oct 2024 12:39:43 GMT

Yes, but the app.overlay is normally not applied to the mcuboot build, only the main application. I see you are also disabling the QSPI node. Is the mx25r64 not on your QSPI bus?

[quote userid="4223" url="~/f/nordic-q-a/115570/using-mcuboot-with-nrf5340/506916"]The only warning I receive from the `* Running CMake for mcuboot *` is about the RTT configuration. For the application cmake run, I got this warning:[/quote]

It looks like you are missing the CONFIG_IMG_MANAGER. Did you use my configurations from peripheral_lbs_fota_enc/boards/nrf5340dk_nrf5340_cpuapp.conf?

RE: Using MCUBoot with nRF5340

Torsten Robitzki — Fri, 18 Oct 2024 12:34:38 GMT

This is the start of my `app.overlay`:

 &zephyr_udc0 {
    cdc_acm_uart0 {
        compatible = "zephyr,cdc-acm-uart";
    };
};

/ {
    chosen {
        nordic,pm-ext-flash = &mx25r64;
    };
};

/*
   Disable QSPI peripheral, to not get the Zephyr QSPI driver linked in,
   which would clash with drivers/flash_memory.cpp
 */
&qspi {
    status = "disabled";
};

...

I've disabled the qspi-disable part of the overlay file, but still there are some entries in `flash_map` with `fa_dev` set to 0 (and the resulting dts still does not contain the required chosen value):

(gdb) p/x *flash_map@flash_map_entries
$3 = {{
    fa_id = 0x0,
    pad16 = 0x0,
    fa_off = 0x0,
    fa_size = 0x10000,
    fa_dev = 0x94b0
  }, {
    fa_id = 0x1,
    pad16 = 0x0,
    fa_off = 0x0,
    fa_size = 0x40000,
    fa_dev = 0x949c
  }, {
    fa_id = 0x2,
    pad16 = 0x0,
    fa_off = 0x0,
    fa_size = 0xe0000,
    fa_dev = 0x0
  }, {
    fa_id = 0x3,
    pad16 = 0x0,
    fa_off = 0x10000,
    fa_size = 0x200,
    fa_dev = 0x94b0
  }, {
    fa_id = 0x4,
    pad16 = 0x0,
    fa_off = 0x10000,
    fa_size = 0xe0000,
    fa_dev = 0x94b0
  }, {
    fa_id = 0x5,
    pad16 = 0x0,
    fa_off = 0x10200,
    fa_size = 0xdfe00,
    fa_dev = 0x94b0
  }, {
    fa_id = 0x6,
    pad16 = 0x0,
    fa_off = 0x10200,
    fa_size = 0xdfe00,
    fa_dev = 0x94b0
  }, {
    fa_id = 0x7,
    pad16 = 0x0,
    fa_off = 0x40000,
    fa_size = 0x0,
    fa_dev = 0x949c
  }, {
    fa_id = 0x8,
    pad16 = 0x0,
    fa_off = 0xe0000,
    fa_size = 0x40000,
    fa_dev = 0x0
  }, {
    fa_id = 0x9,
    pad16 = 0x0,
    fa_off = 0xf0000,
    fa_size = 0x10000,
    fa_dev = 0x94b0
  }, {
    fa_id = 0xa,
    pad16 = 0x0,
    fa_off = 0x120000,
    fa_size = 0x6e0000,
    fa_dev = 0x0
  }}

The number of entries in the array corresponds with the number of entries in pm_static.yml, but the order seems to be different.

The only warning I receive from the `* Running CMake for mcuboot *` is about the RTT configuration. For the application cmake run, I got this warning:

    warning: UPDATEABLE_IMAGE_NUMBER (defined at /Users/todi/bloomlife/zephyr-
    workspace/nrf/samples/common/mcumgr_bt_ota_dfu/Kconfig:88, subsys/dfu/Kconfig:95) was assigned the
    value '2' but got the value ''. Check these unsatisfied dependencies:
    (((BOARD_THINGY53_NRF5340_CPUAPP || BOARD_THINGY53_NRF5340_CPUAPP_NS) && SOC_SERIES_NRF53X &&
    NCS_SAMPLE_MCUMGR_BT_OTA_DFU) || (!MCUBOOT && IMG_MANAGER)) (=n). See
    http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_UPDATEABLE_IMAGE_NUMBER and/or look up
    UPDATEABLE_IMAGE_NUMBER in the menuconfig/guiconfig interface. The Application Development Primer,
    Setting Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be
    helpful too.

Could that be a hint as to where the problem is?

RE: Using MCUBoot with nRF5340

Vidar Berg — Fri, 18 Oct 2024 12:11:58 GMT

Thanks. It appears that you are missing the 'nordic,pm-ext-flash' property in your zephyr.dts. Without this, the bootloader will not know which flash device to use for accessing the partitions in 'external_flash'. In my sample, I had a board overlay to set this 'chosen' (/peripheral_lbs_fota_enc/sysbuild/mcuboot/boards/nrf5340dk_nrf5340_cpuapp.overlay)

/ {
	chosen {
		nordic,pm-ext-flash = &mx25r64;
	};
};

RE: Using MCUBoot with nRF5340

Torsten Robitzki — Fri, 18 Oct 2024 12:04:01 GMT

Currently, I try to use a static portions. Thanks for looking into this. Files are renamed to be accepted by your forums software.devzone.nordicsemi.com/.../4530.zephyr.dts

devzone.nordicsemi.com/.../6505.pm_5F00_static.yml.txt devzone.nordicsemi.com/.../4034_2E00_.config.txt

RE: Using MCUBoot with nRF5340

Vidar Berg — Fri, 18 Oct 2024 11:44:05 GMT

Logging over RTT can be unreliable when there are multiple images in the boot chain, as the next image in the boot sequence may overwrite the RTT log buffer in RAM. However, a common reason for the bootloader failing to boot the app and entering FIH_PANIC is that there were an error in configuring the external flash. Can you provide your generated zephyr.dts and .config file? These are located in build/mcuboot/zephyr.

Also, are you currently testing with or without a static partitioning file? Either way, please provide the partition file as well if possible.

RE: Using MCUBoot with nRF5340

Torsten Robitzki — Fri, 18 Oct 2024 11:10:06 GMT

With your configuration, I was at least able to build all images without error. Now, I'm debugging the bootloader. I'm not able to enable RTT logging. But currently, the startup stops by an attempt to iterate over all images. All flash areas are opened and a few of the 11 flash areas do not have the fa_dev in struct flash_area set.

This flash_map seem to be build in flash_map_partion_manager.c and there, fa_dev is assigned by `DEVICE_DT_GET_OR_NULL(DT_MTD_FROM_FIXED_PARTITION(part))` which somehow implies, that a value of 0 is expected for that map.

Now, I wonder, why that member is assigned to 0, if later, at runtime, a value != 0 is expected and how can I figure out, what is going wrong.

RE: Using MCUBoot with nRF5340

Vidar Berg — Thu, 17 Oct 2024 11:34:59 GMT

Yes, B0n is required for netcore DFU. It is enabled through the SB_CONFIG_SECURE_BOOT_NETCORE symbol in sysbuild.conf

RE: Using MCUBoot with nRF5340

Torsten Robitzki — Thu, 17 Oct 2024 11:32:31 GMT

I'm not even able to trigger the error above. My `pm_static.yml` works in your example, albeit the resulting partition_manager_report look different. I guess, I have to revisit every switch and configuration bit and make two clean builds with every change.

Largest difference, I see is that my build does not include the `b0n` (which I think is required for the update of the bluetooth HCI controller on the radio core).

RE: Using MCUBoot with nRF5340

Vidar Berg — Thu, 17 Oct 2024 09:49:34 GMT

I'm not sure if I have experienced the same. Could you please try and see if you experience the same with the sample I provided? The linker error for PM_MCUBOOT_PRIMARY_1_ADDRESS will be raised if the flash RAM partition is missing.

RE: Using MCUBoot with nRF5340

Torsten Robitzki — Thu, 17 Oct 2024 09:37:59 GMT

Thank you! I will go through that example.

An other, very annoying observation I made: In the corse to, basically "try and error", figuring out some settings that fixes build errors, I found, that the build is not reproducible!

Currently, I have a state, where I completely delete the build folder, start the build with `--pristine` added to the `west build` command and get alternating, two different errors. The one error, is the error above, while building the application.After I received that error, I delete the build folder again and rerun the build command. Every second time, I receive a linker error, while linking the application (a missing symbol, probably not defined due to the first issue).

As the second error is a linker error, this can not be any effect from parallel build, where the order of build steps could change. I disable the usage of `ccache`, but the behavior does not change. :-/

RE: Using MCUBoot with nRF5340

Vidar Berg — Thu, 17 Oct 2024 08:26:22 GMT

Hello,

I've created a demo based on the peripheral_lbs sample, please see attached below.

Demo sample

devzone.nordicsemi.com/.../peripheral_5F00_lbs_5F00_enc_5F00_fota.zip

Disclaimers

- DFU with encrypted images is not a feature that has been tested or validated by Nordic ( nRF52840 + NCS + MCUBoot, CC310-enabled image encryption? ) .

- The cmake signing script does not sign encrypt the netcore image. This can be fixed by patching relevant cmake script.

- The application_dfu.zip generated by the build contains signed but not encrypted images. Use the /build/peripheral_lbs_fota_enc/zephyr/zephyr.signed.encrypted.bin binary instead (application image). The netcore image which is signed but not encrypted is called signed_by_mcuboot_and_b0_ipc_radio.bin and is located in build/.

- I have not done any extensive testing of this demo, just verified that I was able to update the appcore FW.

Best regards,

Vidar