MCUBoot’s secondary image on external Flash : Down into the rabbit hole and back

RE: MCUBoot’s secondary image on external Flash : Down into the rabbit hole and back

Håkon Alseth — Wed, 09 Nov 2022 12:41:51 GMT

Hi,

I will continue in the new thread that you created.

Cheers,

Håkon

RE: MCUBoot’s secondary image on external Flash : Down into the rabbit hole and back

ayuzva — Tue, 08 Nov 2022 20:58:42 GMT

After merging my device tree (custom board) and the overlay file. I am no longer getting the abovementioned restarts. So it seems I was not passing the device tree overlay to the mcuboot correctly. However, now I am getting "Remote error: No Entry (5)" when I try to upload an image in the nRF Connect Device Manager. This cooresponds to "MGMT_ERR_ENOENT" of mcumgr. This code is returned from img_mgmt_read_info().

I have opened a thread on this issue:

devzone.nordicsemi.com/.../dfu-over-ble-mcuboot-external-flash-qspi-mgmt_err_enoent

RE: MCUBoot’s secondary image on external Flash : Down into the rabbit hole and back

ayuzva — Tue, 08 Nov 2022 16:30:28 GMT

Hi Håkon Alseth ,

I am having a similar use case (but over BLE) and similar issues. Whenever I start a transfer from nRF Connect Device Manager the target microcontroller immediately restarts. I can confirm that the restart is getting triggered from os_mgmt by SMP. I can also confirm that OTA works just with internal flash.

Unlike the original poster, I am not getting to the point of writing the boot magic number. I am working with nRF52840 SoC and AT25QL641 QSPI Flash chip. I am on v2.1.0 of nRF Connect SDK.

I have already fixed the "partition_manager.cmake" per your comment here:

https://devzone.nordicsemi.com/f/nordic-q-a/91180/nrf9160dk-fota-using-external-flash-ncs-2-0-2/394765

In the device tree I have:

/ {
    chosen {
            nordic,pm-ext-flash = &at25ql641;
    };
};

In child_image/mcuboot.conf I have:

CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY=y
CONFIG_BOOT_MAX_IMG_SECTORS=256
CONFIG_PM_OVERRIDE_EXTERNAL_DRIVER_CHECK=n
CONFIG_FLASH=y
CONFIG_NRFX_QSPI=y
CONFIG_NORDIC_QSPI_NOR=y
CONFIG_NORDIC_QSPI_NOR_STACK_WRITE_BUFFER_SIZE=16

In my partitions.yml I made sure that primary and secondary partitions have the same size:

mcuboot_primary:
  address: 0xc000
  end_address: 0x100000
  orig_span: &id001
  - app
  - mcuboot_pad
  region: flash_primary
  size: 0xf4000
  span: *id001
mcuboot_primary_app:
  address: 0xc200
  end_address: 0x100000
  orig_span: &id002
  - app
  region: flash_primary
  size: 0xf3e00
  span: *id002
mcuboot_secondary:
  address: 0x0
  device: /soc/qspi@40029000/at25ql641@0
  end_address: 0xf4000
  placement:
    align:
      start: 0x4
  region: external_flash
  share_size:
  - mcuboot_primary
  size: 0xf4000

I also noticed that providing "size-in-bytes" parameter to the QSPI driver causes Partition Manager to fail at compilation, but providing "size" parameter works.

I will try to provide more information as I continue to test. Thank you.

RE: MCUBoot’s secondary image on external Flash : Down into the rabbit hole and back

Håkon Alseth — Thu, 21 Oct 2021 08:05:49 GMT

Hi,

[quote user="lodup29"]

Thanks,

I confirm that :

[/quote][quote user="lodup29"]does the trick.[/quote]

Thank you for coming back to us, that is great to hear! I will still follow up internally on improving documentation and configuration around these settings.

Hope you have a wonderful day!

Kind regards,

Håkon

RE: MCUBoot’s secondary image on external Flash : Down into the rabbit hole and back

Louis — Wed, 20 Oct 2021 15:11:47 GMT

Thanks,

I confirm that :

CONFIG_NORDIC_QSPI_NOR_STACK_WRITE_BUFFER_SIZE=16

does the trick.

RE: MCUBoot’s secondary image on external Flash : Down into the rabbit hole and back

Håkon Alseth — Wed, 20 Oct 2021 14:59:29 GMT

My deepest apologies for my mixup, I seemed to have copied the wrong config.

The one I copied is for when using SPIM, not QSPI. The correct one shall then be:

CONFIG_NORDIC_QSPI_NOR_STACK_WRITE_BUFFER_SIZE=16

Kind regards,

Håkon

RE: MCUBoot’s secondary image on external Flash : Down into the rabbit hole and back

Louis — Wed, 20 Oct 2021 12:48:55 GMT

Indeed. It didn't work.

RE: MCUBoot’s secondary image on external Flash : Down into the rabbit hole and back

Louis — Wed, 20 Oct 2021 12:45:29 GMT

I'll give that a try but I'm pretty sure it won't work. The decision to call write_from_nvmc is made at the level of the Flash driver. Unless write_from_nvmc actually succeeded thanks to that.

RE: MCUBoot’s secondary image on external Flash : Down into the rabbit hole and back

Håkon Alseth — Wed, 20 Oct 2021 12:35:21 GMT

Hi,

I'm sorry to hear that the process was this demanding! I will surely report this internally.

[quote user=""]For there, things went smoothly up until the point where boot_request_upgrade is called (either directly or from DFU API). I dug a little deeper and found that it fails attempting to write the boot magic number. Unlike the chunks of firmware updates, the magic number is not hosted in RAM, but in the internal Flash program memory (variable defined as const) and write_from_nvmc instead of nrfx_qspi_write is called. Quite frankly I didn't bother to check why, but write_from_nvmc returns an error that translates to EINVAL (Invalid argument). I just went ahead and changed MCUBoot to :[/quote]

Looking at the sequence, and your description of the problem, it seems that it is unable to write the external flash (secondary slot) magic tags.

As a alternative test, could you try setting this in mcuboot.conf and see if it works w/o changing boot_write_magic() then?

Here's the setting for child_image/mcuboot.conf:

CONFIG_SPI_NRFX_RAM_BUFFER_SIZE=16

Kind regards,

Håkon