MCU Boot XIP from external memory/Reduce Swap time

[LukeC]

SDK 2.4.2

IC: nRF52840

QSPI Flash: MX25R64

Issue: I am using MCUBoot with the secondary image located in external QSPI flash.  My application image is 941kb and therefore too big to use the internal flash.

I do not have usb/serial access to the device so I need a recovery mechanism to swap images if the update fails. 


Questions:

1.  My current image transfer time is greater than 1 minute.  I am guessing this is due to the erase/program time of the MX25R64.  Is this normal for an image of my size or are the further optimations I can do to speed this up?

 

2. Is it possible to use  XIP to external flash to avoid the image swap?   When I use CONFIG_BOOT_DIRECT_XIP my flash size overflows.  I assume this means the partition manager is attempting to use the internal flash for both slots and not the external flash for the secondary image. 

3. Perhaps someone has experience with a different SPI flash chip that has faster erase/program cycles?  I saw Windbond is advertising very fast program time on new parts.  

https://www.winbond.com/hq/support/online-learning/articles-item/qspinand-ultra-fast-write-speed-for-over-the-air-on-automotive.html?__locale=en 

[AHaug]

Hi,

1.  My current image transfer time is greater than 1 minute.  I am guessing this is due to the erase/program time of the MX25R64.  Is this normal for an image of my size or are the further optimations I can do to speed this up?

The transfer speed is also dependent on the baud rate you set, I assume that you're using the default value of 115200? You could try to go up to 1M (as long as the mx25 supports that)

2. Is it possible to use  XIP to external flash to avoid the image swap?   When I use CONFIG_BOOT_DIRECT_XIP my flash size overflows.  I assume this means the partition manager is attempting to use the internal flash for both slots and not the external flash for the secondary image. 

Are you referring to https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.5.0/mcuboot/design.html#equal-slots-direct-xip? If so, then as far as I know this is for cases where you have both mcuboot primary and secondary on the internal SoC flash and not split into a primary partition on the internal flash and the secondary on external flash.

As for Execute in place, a feature for the nRF5340, is not supported for the nRF52840. Do note if you consider to swap to the 5340 there will be limitations regarding what and how you use the execute in place feature

3. Perhaps someone has experience with a different SPI flash chip that has faster erase/program cycles?  I saw Windbond is advertising very fast program time on new parts.  

Yes, it might be the case that some flash devices are faster than the MX25R64 that we use on our DKs, but that will be up to you and/or other users on the forum to experiment with and discuss

I hope this is enough to get you started and please feel free to ask follow up questions if you have any related to this topic

Kind regards,
Andreas

[LukeC]

AHaug said:

The transfer speed is also dependent on the baud rate you set, I assume that you're using the default value of 115200? You could try to go up to 1M (as long as the mx25 supports that)

I am not concerned with the transfer speed of the image to the device (e.g. in my case over BLE). I am concerned with the speed of the image swap after the update. This is the time mcuboot takes to swap the old slot 0 image with the new slot 1 image. 

Right now after the update, the image swap time for the update is greater than 1 minute.  This is on top of the time it takes for the image to transfer over BLE. This seems pretty long for Quad SPI flash.  I know it is slower than the internal flash, but this seems to be a lot longer/less efficient than I would expect.

My primary concern was that this might indicate that my mcuboot setup is not as optimized as it should be.  I would like confirmation that the image swap from external spi flash to the internal flash of an image of ~920 kb should take this long. 

NOTE: The initial erase time is around 14 seconds:

[AHaug]

Hi,

LukeC said:

I am not concerned with the transfer speed of the image to the device (e.g. in my case over BLE). I am concerned with the speed of the image swap after the update. This is the time mcuboot takes to swap the old slot 0 image with the new slot 1 image. 

That makes more sense than the transport speed of the image. Thanks for clarifying

So I've asked around some regarding what to be expected and if there are any other ways to speed this up. 

In case you didn't already know: MCUboot uses swap by default, meaning that it swaps a section of the old image with a section of the new image until it is complete. This allows for a fallback to be in place in case the new image for some reason is rejected after it has been swapped from the secondary application slot to the primary application slot. This process takes quite a while, specially for larger images, which is to be expected.

An option to speed this up is to enable BOOT_UPGRADE_ONLY in MCUboot https://github.com/nrfconnect/sdk-mcuboot/blob/adab597a0eb0eb9c030a7b797748a49ca89988c2/boot/zephyr/Kconfig#L223. This allows you to overwrite the image instead of swapping, which should be faster. The downside is the removal of the said fallback recovery.

Let me know if this clarifies things for you

Kind regards,
Andreas

[LukeC]

Yes, I am aware of the UPDATE_ONLY option.  My device needs some recovery option since I cannot use the serial recovery.

This would save me about 45 seconds, but remove the option to swap images.  I could try to load a golden image to the serial flash and add a recovery mechanism using that image to mcuboot.  I am unsure if that is worth it as it will add time on the device programming side. 

[AHaug]

Hi,

Noted, if fallback/dual bank is a must, then we're either left with swap with or without scratch https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/mcuboot/design.html#swap-using-scratch as well as try to increase the qspi frequency.

From our own experience there are no significant gains to be had w.r.t the time it takes in between the two swap options or by increasing the qspi frequency, but it could be worth experimenting with on your end as well. The majority of the time sink is the flash erasing and writing itself

Probably not the answer you were hoping for, but I hope it clarifies your question anyways

Kind regards,
Andreas