Cannot confirm image after swapping from external secondary mcuboot partition

[alexdr5398]

Hello,

I have an nrf52833 that interfaces with an external flash module. It is configured  to store mcuboot's secondary partition. I am able to write the secondary image and after it swaps, it does boot into this image correctly, but I am not able to confirm the image.

I am using the dfu target api for the firmware image and the mcuboot image control api to confirm the image. The function ` boot_write_img_confirmed` returns 0 which supposedly means that it was successful, however reading the `mcuboot_swap_type` function still returns `revert` and the next time the chip is reset, it reverts to the old image.

I am using this same process on the Laird P100 which also uses an external flash and it works correctly.

I found other posts with this issue where the solution was switching from a dynamic partition to a static one. I am indeed already using a static partition, although it might be another related issue.

Here is the output of `west build -t partition_manager_report`

  external_flash (0x80000 - 512kB):
+------------------------------------------+
| 0x0: external_flash (0x80000 - 512kB)    |
| 0x0: mcuboot_secondary (0x6e000 - 440kB) |
+------------------------------------------+

  flash_primary (0x80000 - 512kB):
+--------------------------------------------------+
| 0x0: mcuboot (0x12000 - 72kB)                    |
+---0x12000: mcuboot_primary (0x6e000 - 440kB)-----+
| 0x12000: mcuboot_pad (0x200 - 512B)              |
+---0x12200: mcuboot_primary_app (0x6de00 - 439kB)-+
| 0x12200: app (0x6de00 - 439kB)                   |
+--------------------------------------------------+

  sram_primary (0x20000 - 128kB):
+--------------------------------------------+
| 0x20000000: sram_primary (0x20000 - 128kB) |
+--------------------------------------------+

and here's the full `pm_static.yml`

mcuboot:
  address: 0x0
  end_address: 0x12000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0x12000
app:
  address: 0x12200
  end_address: 0x80000
  region: flash_primary
  size: 0x6de00
mcuboot_pad:
  address: 0x12000
  end_address: 0x12200
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0x12000
  end_address: 0x80000
  orig_span: &id001
  - mcuboot_pad
  region: flash_primary
  sharers: 0x1
  size: 0x6e000
  span: *id001
mcuboot_primary_app:
  address: 0x12200
  end_address: 0x80000
  orig_span: &id002
  - app
  region: flash_primary
  size: 0x6de00
  span: *id002
sram_primary:
  address: 0x20000000
  end_address: 0x20020000
  region: sram_primary
  size: 0x20000
external_flash:
  address: 0x0
  region: external_flash
  size: 0x80000
  device: AT25X
mcuboot_secondary:
  address: 0x0
  region: external_flash
  device: AT25X
  size: 0x6e000

Here are the mcuboot configs that we are using

CONFIG_CLOCK_CONTROL_NRF_CALIBRATION_PERIOD=6000
CONFIG_CLOCK_CONTROL_NRF_CALIBRATION_MAX_SKIP=20
CONFIG_MAIN_STACK_SIZE=10240

CONFIG_FLASH=y
CONFIG_SPI=y

CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y
CONFIG_BOOT_SIGNATURE_KEY_FILE="@MCUBOOT_KEY_FILE@"
CONFIG_CLOCK_CONTROL_NRF=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY=y
CONFIG_PM_OVERRIDE_EXTERNAL_DRIVER_CHECK=y
CONFIG_REBOOT=y
CONFIG_MULTITHREADING=y
CONFIG_SPI_NOR_FLASH_LAYOUT_PAGE_SIZE=4096
CONFIG_SPI_NOR_IDLE_IN_DPD=y
CONFIG_PM=n
CONFIG_PM_DEVICE=y

CONFIG_CPP=y
CONFIG_STD_CPP20=y

CONFIG_RTT_CONSOLE=n

CONFIG_LOG_MODE_MINIMAL=n
CONFIG_CONSOLE=y
CONFIG_LOG_PRINTK=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_STDOUT_CONSOLE=y
CONFIG_LOG_BACKEND_RTT=y
CONFIG_LOG_BACKEND_UART=n
CONFIG_DEBUG=y


CONFIG_LOG=y
CONFIG_LOG_MODE_IMMEDIATE=y # former CONFIG_MODE_MINIMAL
### Ensure Zephyr logging changes don't use more resources
CONFIG_LOG_DEFAULT_LEVEL=3
CONFIG_THREAD_NAME=y
### Decrease footprint by ~4 KB in comparison to CBPRINTF_COMPLETE=y
CONFIG_CBPRINTF_NANO=y

CONFIG_BOOT_UPGRADE_ONLY=n

CONFIG_DISABLE_FLASH_PATCH=y
CONFIG_BOOT_BOOTSTRAP=n
CONFIG_FPROTECT=n
CONFIG_BOOT_SWAP_SAVE_ENCTLV=n
CONFIG_MBEDTLS_CFG_FILE="mcuboot-mbedtls-cfg.h"

It is configured using CMake and added like so:

set(mcuboot_CONF_FILE
	${gen_dir}/mcuboot.conf
)

[AHaug]

Hi,

I believe that what's causing the issue is an incorrect static partitioning map. In your case both MCUboot_secondary and external flash starts at 0x0 in your case, while from the sample below it is defined differently: Do note that the sample uses dynamic partitioning and is set up for the nRF52840, but similarly you could set this up for the nRF52833 (albeit with only 512kB of flash).

  external_flash (0x800000 - 8192kB):
+---------------------------------------------+
| 0x0: mcuboot_secondary (0xf0000 - 960kB)    |
| 0xf0000: external_flash (0x710000 - 7232kB) |
+---------------------------------------------+

  flash_primary (0x100000 - 1024kB):
+--------------------------------------------------+
| 0x0: mcuboot (0x10000 - 64kB)                    |
+---0x10000: mcuboot_primary (0xf0000 - 960kB)-----+
| 0x10000: mcuboot_pad (0x200 - 512B)              |
+---0x10200: mcuboot_primary_app (0xefe00 - 959kB)-+
| 0x10200: app (0xefe00 - 959kB)                   |
+--------------------------------------------------+

  sram_primary (0x40000 - 256kB):
+--------------------------------------------+
| 0x20000000: sram_primary (0x40000 - 256kB) |
+--------------------------------------------+

In general what I typically do (and recommend to customers) is to develop everything with a dynamic partitioning (up until where you need to do static) and, then copy the generated dynamic partition into their static partition and tweak where you need.

I do also note that you MCUBoot bootloader slot is 72kB, which is quite large (default in our samples is 48kB, and you can get minimal configurations down to 21kB), so in case you wish to do other optimizations w.r.t flash I recommend you to have a look at https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/test_and_optimize/optimizing/index.html and https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/protocols/matter/end_product/bootloader.html#mcuboot_minimal_configuration 

Let me know if resolving the static partition map fixes the issue

Kind regards,
Andreas

[alexdr5398]

Hello, Thanks for the quick reply.

Using dynamic partitioning is a good suggestion. When I switch to it (by removing `pm_static.yml`) the application no longer compiles because the flash region is overrun. It looks like it's no longer using the external flash chip. Unfortunately, I'm not the one who original set up this project, so I'm not totally familiar with how the external flash is set up. I know we had to write custom zephyr drivers for it though.

Which sample are you referring to that has that partition map? That might be a good reference to see how dynamic partitioning works with the external flash.