Issue with MCUboot + mcumgr FOTA using 2 MB SPI external flash (-19 Failed to open flash area)

Hi Team,

I’m facing an issue when trying to perform BLE FOTA with a 2 MB external SPI flash (SPI4) as the secondary slot for MCUboot.

My setup works fine when using a QSPI 8 MB flash on the Nordic Dev Kit without a custom pm_static.yml — but when switching to SPI-based 2 MB flash on my custom board,
MCUboot cannot access the secondary slot.

Board & Environment
nRF board: Custom board based on nRF5340 

SDK: nRF Connect SDK v2.6.1

Bootloader: MCUboot (child image)

External flash: 2 MB, SPI interface (SPI4 bus)

FOTA method: mcumgr over BLE

Partitioning: Using pm_static.yml to map slot1 to external flash

Problem
When attempting to upload an image with mcumgr, the device logs show that MCUboot treats the secondary slot as unreachable,
and mcumgr fails with -19 (ENODEV) when opening the external flash area.

Log output (relevant section):

[00:00:12.667,205] <dbg> mcumgr_img_grp: img_mgmt_active_slot: (0) => 0
[00:00:12.667,236] <inf> mcuboot_util: Secondary image of image pair (0.) is unreachable. Treat it as empty
[00:00:12.667,266] <dbg> mcumgr_img_grp: img_mgmt_get_next_boot_slot: (0, *) => slot = 0, type = 0
[00:00:12.667,266] <dbg> mcumgr_img_grp: img_mgmt_active_slot: (0) => 0
[00:00:12.667,419] <err> mcumgr_img_grp: Failed to open flash area ID 3: -19


Steps Already Tried:

1.Configured pm_static.yml so mcuboot_secondary maps to the external flash region.

2.Verified SPI4 wiring and device tree configuration for the external flash.

3.Enabled debug logs in both prj.conf and child_image/mcuboot.conf.

4.Confirmed that CONFIG_PM_EXTERNAL_FLASH=y is not available for SPI flash.

5.Checked device-tree that nordic_pm_ext_flash points to the correct SPI NOR device.

Question:
1.Is there a known limitation in NCS/MCUboot for using SPI NOR (non-QSPI) flash as the secondary slot for BLE FOTA?

2.Are there additional configs or hooks needed to make flash_area_open() work with SPI NOR in MCUboot?

3.Could you confirm if the provided pm_static.yml approach is correct for this use case?

I have attached:

Project zip file here 

inter_less8_exer2_solution_120825.zip

pm_static.yml

child_image/mcuboot.overlay

child_image/mcuboot.conf

prj.conf

Parents
  • Hello! 

    There's a couple if items here that I believe might be the root cause to your issues.

    1.Is there a known limitation in NCS/MCUboot for using SPI NOR (non-QSPI) flash as the secondary slot for BLE FOTA?

    2.Are there additional configs or hooks needed to make flash_area_open() work with SPI NOR in MCUboot?

    1. The first is that QSPI is not properly disabled, and the reason is a bit hidden. This should answer both your first and second question about qspi and additional configs.

      You can see that you still have QSPI enabled by examining the generated .config file located at build/zephyr/.config. If you search for "qspi" you can see "CONFIG_DT_HAS_NORDIC_QSPI_NOR_ENABLED=y" (and a couple more items). The reason is simply that it is not sufficient to only disable the qspi node in dts by setting stats="disabled";, you also need to make sure you're not using a configuration that enables QSPI.

      From the solution of the academy course you've set the following:

      # # Enable Bluetooth and SMP for mcumgr
      # CONFIG_MCUMGR_SMP_BT=y
      # CONFIG_MCUMGR_SMP=y
      CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y
      
      # CONFIG_SPI=y
      
      # CONFIG_SPI=y
      # CONFIG_FLASH=y
      # CONFIG_FLASH_MAP=y
      # CONFIG_SPI_NOR=y
      # CONFIG_NORDIC_QSPI_NOR=y
      
      # prj.conf (your application)


      I.e you've not defined CONFIG_SPI and CONFIG_QSPI_NOR for your application, whereas in child_image/mcuboot.conf you have CONFIG_NORDIC_QSPI_NOR=n and CONFIG_SPI=y and CONFIG_SPI_NOR=y. This means that only MCUboot knows that QSPI to be disabled and SPI enabled.

      The second thing is that the configuration CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y implies quite a few configurations. By using the Kconfig search you can see which: https://docs.nordicsemi.com/bundle/ncs-2.6.1/page/kconfig/index.html#CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU 



      In Zephyr, an Imply is stronger than what you define in the prj.conf. In the case of the NCS_SAMPLE configuration it implies QSPI to be enabled even though you think you disable it. 

      Unfortunately for NCS v2.6.1 the academy course w.r.t bootloaders is rather limited, but you can see how to set up an external flash with SPI communication for NCS 2.6.1 here https://github.com/nrfconnect/sdk-nrf/tree/v2.6.2/samples/net/aws_iot/child_image/mcuboot/boards. This is referred to by the course from here: https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-9-bootloaders-and-dfu-fota/topic/exercise-3-dfu-with-external-flash/  
          -----> to here    ---> to here 

      In NCS 2.9.0 and newer, Exercise 3 contains steps for setting up an external flash with SPI communication.
    3.Could you confirm if the provided pm_static.yml approach is correct for this use case?

    I've not had the deepest look at it, but initial lookthrough seems to look fine. Just make sure that your start and end addresses for your partitions are page aligned 

    Kind regards,
    Andreas

Reply
  • Hello! 

    There's a couple if items here that I believe might be the root cause to your issues.

    1.Is there a known limitation in NCS/MCUboot for using SPI NOR (non-QSPI) flash as the secondary slot for BLE FOTA?

    2.Are there additional configs or hooks needed to make flash_area_open() work with SPI NOR in MCUboot?

    1. The first is that QSPI is not properly disabled, and the reason is a bit hidden. This should answer both your first and second question about qspi and additional configs.

      You can see that you still have QSPI enabled by examining the generated .config file located at build/zephyr/.config. If you search for "qspi" you can see "CONFIG_DT_HAS_NORDIC_QSPI_NOR_ENABLED=y" (and a couple more items). The reason is simply that it is not sufficient to only disable the qspi node in dts by setting stats="disabled";, you also need to make sure you're not using a configuration that enables QSPI.

      From the solution of the academy course you've set the following:

      # # Enable Bluetooth and SMP for mcumgr
      # CONFIG_MCUMGR_SMP_BT=y
      # CONFIG_MCUMGR_SMP=y
      CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y
      
      # CONFIG_SPI=y
      
      # CONFIG_SPI=y
      # CONFIG_FLASH=y
      # CONFIG_FLASH_MAP=y
      # CONFIG_SPI_NOR=y
      # CONFIG_NORDIC_QSPI_NOR=y
      
      # prj.conf (your application)


      I.e you've not defined CONFIG_SPI and CONFIG_QSPI_NOR for your application, whereas in child_image/mcuboot.conf you have CONFIG_NORDIC_QSPI_NOR=n and CONFIG_SPI=y and CONFIG_SPI_NOR=y. This means that only MCUboot knows that QSPI to be disabled and SPI enabled.

      The second thing is that the configuration CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y implies quite a few configurations. By using the Kconfig search you can see which: https://docs.nordicsemi.com/bundle/ncs-2.6.1/page/kconfig/index.html#CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU 



      In Zephyr, an Imply is stronger than what you define in the prj.conf. In the case of the NCS_SAMPLE configuration it implies QSPI to be enabled even though you think you disable it. 

      Unfortunately for NCS v2.6.1 the academy course w.r.t bootloaders is rather limited, but you can see how to set up an external flash with SPI communication for NCS 2.6.1 here https://github.com/nrfconnect/sdk-nrf/tree/v2.6.2/samples/net/aws_iot/child_image/mcuboot/boards. This is referred to by the course from here: https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-9-bootloaders-and-dfu-fota/topic/exercise-3-dfu-with-external-flash/  
          -----> to here    ---> to here 

      In NCS 2.9.0 and newer, Exercise 3 contains steps for setting up an external flash with SPI communication.
    3.Could you confirm if the provided pm_static.yml approach is correct for this use case?

    I've not had the deepest look at it, but initial lookthrough seems to look fine. Just make sure that your start and end addresses for your partitions are page aligned 

    Kind regards,
    Andreas

Children
No Data
Related