Cannot confirm image after swapping from external secondary mcuboot partition

RE: Cannot confirm image after swapping from external secondary mcuboot partition

AHaug — Fri, 28 Jun 2024 07:44:45 GMT

Hi,

[quote user="Joanna"]I have the exact same problem on nRF53833 with external flash. Can you explain in a little detail how you got it to work?[/quote]

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.

[quote user="alexdr5398"]

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.

[/quote]

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

RE: Cannot confirm image after swapping from external secondary mcuboot partition

alexdr5398 — Thu, 27 Jun 2024 13:23:46 GMT

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.

RE: Cannot confirm image after swapping from external secondary mcuboot partition

Joanna — Thu, 27 Jun 2024 12:55:11 GMT

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?

RE: Cannot confirm image after swapping from external secondary mcuboot partition

alexdr5398 — Wed, 22 May 2024 19:10:05 GMT

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.

RE: Cannot confirm image after swapping from external secondary mcuboot partition

alexdr5398 — Fri, 17 May 2024 15:10:17 GMT

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.

RE: Cannot confirm image after swapping from external secondary mcuboot partition

AHaug — Thu, 16 May 2024 12:20:25 GMT

Hi,

[quote user="alexdr5398"]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.[/quote]

The sample is a generic BLE SMP sample using SPI over BLE that you can find here https://github.com/aHaugl/samples_for_NCS/tree/main/bootloader/SPI_samples/smp_ble_feat_spi (disclaimer: this is an unofficial sample that I've made, so it is not tested similarly to the official SDK samples)

[quote user="alexdr5398"]The flash region for mcuboot is being overflowed because the dynamic partitioner chose 48K for the mcuboot partition, but that is too small I believe because we need to compile in our drivers for the external flash chip.[/quote]

Ah, then I understand the reason for why the MCUboot partition size is set larger than our default 48kB selected by the dynamic partitioner.

[quote user=""]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.[/quote]

From what I can see from the API documentation you refer to I agree. boot_write_img_confirmed returning 0 should mark the image as "good to go" after the upgrade, leading me to believe that there is something in the DFU-target that reverts the image. Are you able to track down where and when the REVERT flag gets set into mcuboot_swap_type?

Kind regards,
Andreas

RE: Cannot confirm image after swapping from external secondary mcuboot partition

alexdr5398 — Wed, 15 May 2024 16:59:54 GMT

Hi Andreas,

I increased the size of the mcuboot partition to 56K and it was able to create the dynamic partition and compile successfully. Unfortunately, that did not solve the issue. There are exactly the same symptoms as before. It boots into the new image, but cannot confirm it.

Here is what the new partition looks like:

  external_flash (0x80000 - 512kB):
+------------------------------------------+
| 0x0: mcuboot_secondary (0x72000 - 456kB) |
| 0x72000: external_flash (0xe000 - 56kB)  |
+------------------------------------------+

  flash_primary (0x80000 - 512kB):
+-------------------------------------------------+
| 0x0: mcuboot (0xe000 - 56kB)                    |
+---0xe000: mcuboot_primary (0x72000 - 456kB)-----+
| 0xe000: mcuboot_pad (0x200 - 512B)              |
+---0xe200: mcuboot_primary_app (0x71e00 - 455kB)-+
| 0xe200: app (0x71e00 - 455kB)                   |
+-------------------------------------------------+

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

and the pm_static.yml:

app:
  address: 0xe200
  end_address: 0x80000
  region: flash_primary
  size: 0x7e100
external_flash:
  address: 0x72000
  end_address: 0x80000
  region: external_flash
  size: 0xe000
mcuboot:
  address: 0x0
  end_address: 0xe000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0xe000
mcuboot_pad:
  address: 0xe000
  end_address: 0xe200
  placement:
    align:
      start: 0x1000
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0xe000
  end_address: 0x80000
  orig_span: &id001
  - mcuboot_pad
  - app
  region: flash_primary
  size: 0x72000
  span: *id001
mcuboot_primary_app:
  address: 0xe200
  end_address: 0x80000
  orig_span: &id002
  - app
  region: flash_primary
  size: 0x71e00
  span: *id002
mcuboot_secondary:
  address: 0x0
  device: DT_CHOSEN(nordic_pm_ext_flash)
  end_address: 0x72000
  placement:
    align:
      start: 0x4
  region: external_flash
  share_size:
  - mcuboot_primary
  size: 0x72000
sram_primary:
  address: 0x20000000
  end_address: 0x20020000
  region: sram_primary
  size: 0x20000

RE: Cannot confirm image after swapping from external secondary mcuboot partition

alexdr5398 — Wed, 15 May 2024 14:16:53 GMT

Actually it does look like the external flash is being detected using dynamic partitioning. The flash region for mcuboot is being overflowed because the dynamic partitioner chose 48K for the mcuboot partition, but that is too small I believe because we need to compile in our drivers for the external flash chip.

RE: Cannot confirm image after swapping from external secondary mcuboot partition

alexdr5398 — Wed, 15 May 2024 13:32:19 GMT

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.

RE: Cannot confirm image after swapping from external secondary mcuboot partition

AHaug — Wed, 15 May 2024 11:55:29 GMT

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