Understanding interdependency between app and mcuboot/b0 images

[Kelso]

I've been running into a lot of issues where a change in the configuration for the application results in an answer that basically states:

"You're supposed to add this configuration to both the application and the bootloader."

This type of inter-dependency implies that when I flash the image, without a new bootloader that I should expect the combination to break.

Is there a way for me to draw a cleaner line between what the bootloader is allowed to be aware of and what the application is aware of? 
At the moment, I don't have a clear way to gauge when an issue like this is going to affect me one way or another so I can mitigate it.

I'm seeing these types of build failures in the configuration around flash memory and around which portions of the BLE api are available.

https://devzone.nordicsemi.com/f/nordic-q-a/107256/problem-using-an-external-flash-together-with-mcuboot

https://devzone.nordicsemi.com/f/nordic-q-a/106037/bt_hci_core-bt_hci_cmd_send_sync-opcode-0x0c33-status-0x11-and-bluetooth-init-failed-err--5

My expectation is that in much the same way I don't have to update my router every time google changes their homepage, I shouldn't have to update my bootloader for all firmware updates.

-Carl

[Kelso]

Notable details missing from my initial description:

I am using nRF Connect 2.6.1

The build is using b0, mcuboot, and hci_ipc

I opted to make this a public ticket on the chance it helps others, but will switch to a private one if specific code is needed for this discussion.

[AHaug]

Hi Carl,

I've been running into a lot of issues where a change in the configuration for the application results in an answer that basically states:

"You're supposed to add this configuration to both the application and the bootloader."

This is correct, in cases regarding features that both images (bootloader and application) uses, you need to add configurations to both image's respective configuration files and/or overlays. An example of this is if you're using external flash (for instance for storiing the DFU image within the secondary mcuboot partition).

This type of inter-dependency implies that when I flash the image, without a new bootloader that I should expect the combination to break.

This will depend on the features that you add to your new bootloader. If you for instance change the start address of certain partitions, add new partitions, move around parts, and only update the application, the old bootloader will not know where the new image and any other partition starts since it's expecting the previous versions start address. Due to this we recommend using static partitions. With dynamic partitioning you might risk that partition sizes vary between builds for the application if you add or remove features or optimize certain features' requirements.

If you add configs w.r.t using an external flash to store the new update image to the prj.conf, without having this in the old mcuboot, then the new bootloader will not be aware of the use of external flash for DFU.

Is there a way for me to draw a cleaner line between what the bootloader is allowed to be aware of and what the application is aware of? 
At the moment, I don't have a clear way to gauge when an issue like this is going to affect me one way or another so I can mitigate it.

This is a rougher one to answer, since it comes down to both experience and familiarity with the bootloader and application i.e the scope of your design, as well as the documentation at https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-8-bootloaders-and-dfu-fota/ and the dfu and bootloader documentation we have on docs.nordicsemi. 

My expectation is that in much the same way I don't have to update my router every time google changes their homepage, I shouldn't have to update my bootloader for all firmware updates.

Another angle of this w.r.t updating your bootloader is that you can't update your bootloader unless you have a bootloader chain i.e a first stage bootloader that updates the second stage bootloader that updates the application. Which again leads you back to you having to design your product and add all the features you need before enter production. If you don't have an updatable bootloader, you can't update MCUboot in field and physical serial recovery is your only option.

Let me know if this clarifies some things for you and please feel free to follow up with more comments for the discussion.

Kind regards,
Andreas