MCUboot partition for Zephyr

Hi, we have a costumer who wants be able to do a firmware update over BLE. We have a running application that takes about 260k of FLASH. This fits in the NRF52832 (512k FLASH) but not with the two slot1/slot2 partitions for MCUboot.

It would help to put the Zephyr part in a separate partition that will not be updated and therefore has not to be mapped. Is there a solution to do so. The dts would lock like:

(The address range is not correct below)

&flash0 {

partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;

boot_partition: partition@0 {
label = "mcuboot";
reg = <0x00000000 0xa000>;
}

zephyr_partition: partition@44000 {
label = "zephyr";
reg = <0x00044000 0x8000>;
};

slot0_partition: partition@a000 {
label = "image-0";
reg = <0x0000a000 0x39000>;
};
slot1_partition: partition@43000 {
label = "image-1";
reg = <0x00043000 0x39000>;
};

scratch_partition: partition@7c000 {
label = "image-scratch";
reg = <0x0007C000 0x1000>;
};
storage_partition: partition@7d000 {
label = "storage";
reg = <0x0007d000 0x00002000>;
};
};
};

Thanks for ideas to manage this situation.

0 Hung Bui over 4 years ago

Hi Andreas,

There is a difference between the Zephyr architecture and our legacy softdevice architecture that Zephyr's stack is not separated from the application. So it's not possible to have a dedicated "stack" area that will not get updated.

So in this case you really need to suggest the customer to reduce the size of the application. Is there any static data that was included in the application that can be moved to the storage area ?
Another option is to move to a chip with larger flash size, the nRF52840 for example.
0 AndreasM over 4 years ago in reply to Hung Bui

Thank for the answer

Unfortunately we cant reduce the application size and we already upgraded from nFT52810 to the bigger nRf52832. To go bigger is a cost issue.

To separate the Zephyr part was the last hope. We have to face it and negotiate with the customer. Update seems not feasible with this constellation.
0 Hung Bui over 4 years ago in reply to AndreasM

I'm afraid that we don't have any other solution besides trying to optimize the code.
Another option is to use the nRF5 SDK and Softdevice. The Softdevice is still a good option with most of the features in Bluetooth 5.2 supported. Of course porting the application back to nRF5 SDK would require considerable amount of work, depends on the application.
0 AndreasM over 4 years ago in reply to Hung Bui

What about following solutions:

1.) Can we use an external Flash to store one of the images?

2.) Can we do the update in two steps. First download a smaller application, that only has the BLE function to download a bigger file with the real application. The benefit would be, that we do not need two images with the same size rather have to images with different size they may overlap.
0 Hung Bui over 4 years ago in reply to AndreasM

Hi Andreas,

1) Yes it's possible. If you can add external flash to the board then you can configure MCUBoot to use the external flash as secondary slot. You can have a look at this case: https://devzone.nordicsemi.com/f/nordic-q-a/72543/mcu-boot-with-external-flash-littles-partition-and-secondary-image-partition

2. This is a good idea. But I'm not 100% sure if it's supported by MCUBoot and by Nordic implementation. You can have a look at the DirectXIP section here. I will need to check with our team to see if #1. You can use Direct XIP 2. You can configure Slot 1 larger size than Slot 2.

I will keep you updated.