Cannot confirm image after swapping from external secondary mcuboot partition

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
)

  • There is nothing in our firmware that could be setting the flag after it boots into the new image. The only dfu target or mcuboot api calls after it boots into the new image are simply checking if the image is confirmed and reading the swap type.

    I have also tried using `boot_request_upgrade(BOOT_UPGRADE_PERMANENT)` rather than `boot_request_upgrade(BOOT_UPGRADE_TEST)` and the image still does not get confirmed and will revert upon the next reset.

    I have also noticed that after an OTA update was attempted, subsequent `west flash` will also result in an image that is not confirmed. `west flash --recover` will fix it and result in image that is confirmed with a swap time of `none`

    It seems to me like there are issues with our custom flash drivers? Since I know this API does work on other projects with an external flash chip.

  • Kind of any unsatisfying resolution, but I eventually solved it by delete my project and initializing it from the manifest file again.

    I must have made an unintentional change while looking through the zephyr or nrf source files that caused this issue.

  • Hi,

    I have the exact same problem on nRF53833 with external flash. Can you explain in a little detail how you got it to work?

  • Hi,

    I simply deleted the entire project and pulled everything again from the manifest repo. I must have accidentally edited some zephyr source files at some point without realizing and cloning the repo fresh again cleared those changes.

  • Hi, 

    Joanna said:
    I have the exact same problem on nRF53833 with external flash. Can you explain in a little detail how you got it to work?

    If removing the project does not resolve the issue for you, then please feel free to create a new case with some more information about the errors you're seeing. 

    alexdr5398 said:

    Kind of any unsatisfying resolution, but I eventually solved it by delete my project and initializing it from the manifest file again.

    I must have made an unintentional change while looking through the zephyr or nrf source files that caused this issue.

    I reread the solution now as I had a new look at the case and I must say I agree with your sentiment about it being an unsatisfying resolution, heh.. But anyways I'm glad that it worked out

    Kind regards,
    Andreas

Related