[nRF5340 DK] What is empty_0 and empty_1 in flash partition? Why use static partition for firmware update?

[bckim]

1. What is empty_0 and empty_1 in Partition Manager? And How is the empty partition size determined?

2. I can't understand the sentence below.  What does mean the application image to be upgraded must be linked to the same address? 

Is it possible to link to the same address only by using a static partition?

By default, the Partition Manager dynamically places the partitions in memory. However, if you have a deployed product that consists of multiple images, where only a subset of the included images can be upgraded through a firmware update mechanism, the upgradable images must be statically configured. For example, if a device includes a non-upgradable first-stage bootloader and an upgradable application, the application image to be upgraded must be linked to the same address as the one that is deployed.

[AHaug]

Hi,

I've picked up your case and I'm working on writing an answer for you. I will get back to you tomorrow with more information.

Kind regards,
Andreas

[AHaug]

Hi again, apologies for the extra day of wait time

1. What is empty_0 and empty_1 in Partition Manager? And How is the empty partition size determined?

My colleague has answered this in this case:  RE: Interpretation of the partition manager report 

Let me know if the answer given by Simon leaves you with any unanswered questions and I'll answer them for you! 

2. I can't understand the sentence below.  What does mean the application image to be upgraded must be linked to the same address? 

To explain the sentence in the The static configuration doc I will use the memory report as well as to refer to this repository written by a colleague of me https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples 

As you see the memory report you have a slot for the bootloader, a primary slot and a secondary slot. In the case where you have a project with a bootloader and an upgradable application, the bootloader will be placed at the start address, followed by some padding (at least of the size to fill out the page the bootloader ends at), and then the application in the primary slot. The secondary slot, is as you probably know, there for storing the DFU image (upgrade image), and needs to be at least the same size as the primary image.

When you want to upgrade the original application running on your device, you must make sure that the new image starts at the same address as the original image, i.e. at the start address of the primary slot. Due to how the build system works, if you ever attempt to build an identical application without the bootloader, the build system will write that the application image should run from the earliest available start address. This address is not the same address as in the device you want to update which has a bootloader at the start address.

So to avoid this issue, you will have to generate the upgrade image in such a way that it is linked to the same address as the original image/the image that is already deployed. You can do this by either using the same bootloader as the original image (which will be identical in size, making the padding the same). Or if you're upgrading your application from NCS versions or you don't have the same bootloader available, you can use the pm-static.yml file from the original build where you've defined where the application/primary slot is located, and use this to generate a new upgrade image which now has a start address identical to the deployed image

Let me know if this answers the question

Kind regards,
Andreas

[bckim]

Thank you for your detailed answer. You were very helpfull!!