No Bootable Image Found: "No fw_info struct found" Error on nRF52832 with Partition Manager and MCUboot

I’m working on an nRF52832-based project using the Nordic SDK (v3.5.99-ncs1-1) and MCUboot for OTA updates. I have a 512KB internal flash and 4MB external SPI flash (P25Q32H) configured. Partition Manager is enabled, and I’m using both internal and external flash for primary and secondary image storage. However, upon booting, I consistently get the following error message:

*** Booting nRF Connect SDK v3.5.99-ncs1-1 ***
Attempting to boot slot 0.
No fw_info struct found.
Attempting to boot slot 1.
No fw_info struct found.
No bootable image found. Aborting boot.

It seems that MCUboot is unable to find a valid firmware image in either slot. Below are the details of my partition setup and configuration:

DTS File

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// Copyright (c) 2024 Nordic Semiconductor ASA
// SPDX-License-Identifier: Apache-2.0
/dts-v1/;
#include <nordic/nrf52832_qfaa.dtsi>
#include "fde_x2-pinctrl.dtsi"
/ {
model = "FDE_x2";
compatible = "sollatek,fde-x2";
chosen {
zephyr,sram = &sram0;
zephyr,flash = &flash0;
zephyr,code-partition = &boot_partition;
zephyr,shell-uart = &uart0;
zephyr,gpio = &gpio0;
zephyr,console = &uart0;
zephyr,uart-mcumgr = &uart0;
nordic,pm-ext-flash = &dev_spi_flash;
};
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

pm_static.yml

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
EMPTY_0:
address: 0x18200
end_address: 0x19000
placement:
before:
- s1_pad
region: flash_primary
size: 0xe00
EMPTY_1:
address: 0x29200
end_address: 0x2a000
placement:
before:
- mcuboot_pad
region: flash_primary
size: 0xe00
app:
address: 0x2a200
end_address: 0x80000
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

prj.conf

Fullscreen
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

mcuboot.conf

Fullscreen
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


What I’ve Tried So Far:

  • I’ve ensured that the partition sizes between the internal and external flash for slot 0 and slot 1 are the same (448KB).
  • The external SPI flash is properly configured and recognized in the device tree (jedec,spi-nor compatible).
  • Partition Manager seems to generate the correct memory map, and I have verified this by inspecting build/zephyr/pm.yml.
  • I am able to flash the primary image (image_0_partition) using the west flash command, but the bootloader still cannot detect any valid firmware in either slot.

My Questions:

  1. What could be causing the bootloader to not find the fw_info struct in either slot 0 or slot 1?
  2. Is there any additional configuration required to ensure that the fw_info is properly embedded in the image so that MCUboot can detect it?
  3. Do I need any specific settings in the prj.conf file to make sure the bootloader can correctly identify and boot from the internal or external flash?
  4. Is there a recommended way to debug and confirm whether the firmware image is being properly written and contains the expected metadata?

Any help or guidance would be greatly appreciated!


Additional Info:

  • Chip: nRF52832 (512KB internal flash, 64KB SRAM)
  • SDK Version: 2.6.1
  • External Flash: P25Q32H (4MB SPI NOR flash)
  • MCUboot: Enabled via Partition Manager
  • Toolchain: Zephyr with west build system

Thank you for your assistance!

Parents
  • Hello,

    How did you flash your device? Does the output from this action indicate that there were any issues?

    Can you please try to read back the flash from the nRF52832 using the nRF Command Line Tools command:

    nrfjprog --readcode my_flash_readout.hex

    And compare this to what you program. Feel free to upload your build folder (or at least the .hex files from it) and the readback hex file if you want me to have a look. 

    Also, can you try to add some lines to ncs\nrf\samples\bootloader\src:

    Fullscreen
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    What address does it print for s0_addr and s1_addr?

    Best regards,

    Edvin

  • Also, can you provide the full build log?

    Best regards,

    Edvin

Reply Children
  • Hi Edvin,

    thanks for your answer. I managed to find the solution by debugging the bootload and understanding the memory addresses it tries to load. I have rebuild my partitions and its working fine now.

    Edvin, can you please validate if my settings are correct? What about the CONFIG_SECURE_BOOT=n, is it safe to leave it disabled? 


    Here are the working files in case someone else want to use a similar setup (NRF52832 + 32Mbit External SPI Flash + NCS 2.6.1)

    DTS File partitions

    Fullscreen
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    pm_static.yml

    Fullscreen
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Relative part on prj.conf

    Fullscreen
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • Hello,

    CONFIG_SECURE_BOOT=n means that you do not enable the first stage bootloader. Please see:
    https://docs.nordicsemi.com/bundle/ncs-latest/page/kconfig/index.html#CONFIG_SECURE_BOOT

    As you probably know, the normal bootloader, the MCUBOOT bootloader is in charge of updating the application (actually just to perform the swapping of the application. The transfer of the new application image happens in the application itself). The MCUBOOT bootloader can not, however, update itself. For this, we use the first stage bootloader, which is enabled by setting CONFIG_SECURE_BOOT=y. This is a small bootloader intended to update the MCUBOOT bootloader (but again, can not update itself).

    So the error message that you posted in the initial post was coming from the first stage bootloader, often referred to as NSIB. A colleague of mine, Sigurd, has a few demo samples showing the different parts of the bootloader(s):

    https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples

    The "updateable bootloader" shows the first stage bootloader. The readme.MD file contains a few links to some documentation.

    It is absolutely possible to not use the first stage bootloader in a product, but should you at some time wish to for example change the bootloader keys, the you need to update the MCUBOOT bootloader, and for this, you need the first stage bootloader/NSIB.

    Best regards,

    Edvin