Multi image configuration with mcuboot doubt

[pau_vilanova]

Hi! I'm working with nRF52833 in a laird dev kit and I'm having problems understanding the multi-image build configuration on nrf Connect SDK with zephyr.

Our project concept is the following:

Having mcuboot on top, and 2 more bootable images.

The first image is the one with the hability to write to the slot 1 of both images.

The second image is the client application.

And I'm having problems on undestranding the project configuration and how child image works.

I'm having doubts in 2 different aspects, which are about project configuration and image management.

In order to understand the first one I'm working with the hello world sample with mcuboot enabled and trying to add an additional image to the project. Doing this I have the following doubts:

- Whats the correct syntax in the dts in order to specify my concept?

    As stated in https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/mcuboot/readme-zephyr.html#building-and-using-mcuboot-with-zephyr  the first updateable image will go as image_0_primary_partition and image_0_secondary_partition and the second as image_1_primary_partition and image_1_secondary_partition. But when I go to the board dts I find the following corresponding to the hello world first image:

That label confuses me.

- Do I need to modify the flash-map stated in https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/mcuboot/design.html#flash-map for multi-image? If so, where is it located in my project?

-Is hello world + mcuboot a multi image build? If so, is mcuboot build in the project as a child? Why I don't find in cmakelists.txt mcuboot child enable and definition as stated in https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/ug_multi_image.html#defining-and-enabling-a-child-image ?

And about the second aspect, image management:

-The smp server example writes the image received in the slot 1 of the current image, is it possible to make it modify the slot 1 of other images? If not, what's the correct approach to my flash structure proposal?

Is there any example or documentation that clarifies what I'm trying to do?

Thanks!

[Simon]

pau_vilanova said:

But, mcuboot is not writing the image to slot 1 like the smp server example, instead is writing it directly to slot 0 and overwriting the application.

In doing so, I cannot test it, and mcuboot is not swapping, just writing new image and booting it. Am I doing something wrong?

Hello and sorry for the delay, I have been gone for the last two months. I think this is the intention. If you perform the dfu through the application, you need two slots in order to have a fallback in case the new update bricks your product. However, if you perform the update through mcuboot, a corrupted firmware update is not an issue, because mcuboot is the fallback (can just perform new update with noncorrupt image).

Best regards,

Simon