nRF53: BT and MCUboot SINGLE_APPLICATION_SLOT cannot be combined

[maximevince]

Combining BT in the main application, and SINGLE_APPLICATION_SLOT on an nRF53 build will cause the ` hci_rpmsg` build to fail with error:

[25/246] Generating ../../zephyr/net_core_app_update.bin, ../../zephyr/net_core_app_signed.hex, ../../zephyr/net_core_app_test_update.hex, ../../zephyr/net_core_app_moved_test_update.hex
FAILED: zephyr/net_core_app_update.bin zephyr/net_core_app_signed.hex zephyr/net_core_app_test_update.hex zephyr/net_core_app_moved_test_update.hex apps/hello_world/build/zephyr/net_core_app_update.bin apps/hello_world/build/zephyr/net_core_app_signed.hex apps/hello_world/build/zephyr/net_core_app_test_update.hex apps/hello_world/build/zephyr/net_core_app_moved_test_update.hex 
cd apps/hello_world/build/modules/mcuboot && /usr/bin/python3.10 bootloader/mcuboot/scripts/imgtool.py sign --key bootloader/mcuboot/root-rsa-2048.pem --header-size 0x200 --align 4 --version 0.0.0+0 --pad-header --slot-size  apps/hello_world/build/hci_rpmsg/zephyr/signed_by_b0_app.hex apps/hello_world/build/zephyr/net_core_app_signed.hex && /home/vinz/zephyr-sdk-0.13.2/arm-zephyr-eabi/bin/arm-zephyr-eabi-objcopy --input-target=ihex --output-target=binary --gap-fill=0xff apps/hello_world/build/hci_rpmsg/zephyr/signed_by_b0_app.hex apps/hello_world/build/zephyr/net_core_app_to_sign.bin && /usr/bin/python3.10 bootloader/mcuboot/scripts/imgtool.py sign --key bootloader/mcuboot/root-rsa-2048.pem --header-size 0x200 --align 4 --version 0.0.0+0 --pad-header --slot-size  apps/hello_world/build/zephyr/net_core_app_to_sign.bin apps/hello_world/build/zephyr/net_core_app_update.bin && /usr/bin/python3.10 bootloader/mcuboot/scripts/imgtool.py sign --key bootloader/mcuboot/root-rsa-2048.pem --header-size 0x200 --align 4 --version 0.0.0+0 --pad-header --slot-size  --pad apps/hello_world/build/hci_rpmsg/zephyr/signed_by_b0_app.hex apps/hello_world/build/zephyr/net_core_app_test_update.hex && /home/vinz/zephyr-sdk-0.13.2/arm-zephyr-eabi/bin/arm-zephyr-eabi-objcopy --input-target=ihex --output-target=ihex --change-address=-16811520 --gap-fill=0xff apps/hello_world/build/zephyr/net_core_app_test_update.hex apps/hello_world/build/zephyr/net_core_app_moved_test_update.hex
Usage: imgtool.py sign [OPTIONS] INFILE OUTFILE
Try 'imgtool.py sign -h' for help.

Error: Invalid value for '-S' / '--slot-size': apps/hello_world/build/hci_rpmsg/zephyr/signed_by_b0_app.hex is not a valid integer. Please use code literals prefixed with 0b/0B, 0o/0O, or 0x/0X as necessary.
ninja: build stopped: subcommand failed.

Reproduced easily like this:

* Configure any main application (e.g. hello_world) and set CONFIG_BOOTLOADER_MCUBOOT=y and CONFIG_BT=y

* Configure the mcuboot bootloader (through child_image/mcuboot.conf) with: CONFIG_SINGLE_APPLICATION_SLOT=y

This makes the hci_rpmsg build fail, and it seems that the wrong value is given to the --slot-size parameter of imgtool. (no value, actually).

It seems Nordic-specific, since Partition Manager should give the slot size to scripts/west_commands/sign.py, and this somehow fails.

[Hung Bui]

Hi Maxime, 

It's not supported. Please have a look at this case: https://devzone.nordicsemi.com/f/nordic-q-a/74661/is-there-any-feasibility-for-use-bluetooth-dfu-with-single_application_slot

[maximevince]

Hi Hung Bui,

Thanks for the reply, however that ticket is not really relevant.
I am not looking for Bluetooth FOTA using MCUboot, I get that it's not possible to do FOTA from the application, without a second slot to store the new application.

My use case is a SINGLE_SLOT, with MCUboot allowing to upgrade the application in that single slot, e.g. using USB-DFU or serial recovery.

The application itself should still be able to use Bluetooth, right? It has nothing to do with the bootloader being used...

As a counter-example, please consider the following:

* Configure any main application (e.g. hello_world) and set CONFIG_BOOTLOADER_MCUBOOT=y (but CONFIG_BT=n)

* Configure the mcuboot bootloader (through child_image/mcuboot.conf) with: CONFIG_SINGLE_APPLICATION_SLOT=y and CONFIG_BOOT_USB_DFU_WAIT=y and CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x10000)

This will compile and work fine! You can now upgrade the single slot application over USB-DFU.

This is exactly what I want, but it fails to compile as soon as I add `CONFIG_BT=y` to the main application; which should be unrelated!

[Hung Bui]

Hi Maxime, 

It's regardless if you are planning to do FOTA or Serial DFU, as long as it's the application handle the DFU process, then it has to be dual bank update. 

The bootloader in NCS SDK is a little bit different from the bootloader in nRF5 SDK. That the receiving of new image is done via the application, not via the bootloader (MCUBoot). The MCUBoot main job is only to verify, test and swap images. 

However, there is a "recovery" mode in MCUBoot that you can add the code of receiving new image into MCUBoot. This feature will do DFU update with single bank mode. This mean the original application will be replaced directly with the new image received by the MCUBoot. Please have a look at the serial_recovery.conf in \bootloader\mcuboot\boot\zephyr. 

To enter recovery mode a button need to be pressed when booting up, you need to define CONFIG_BOOT_SERIAL_DETECT_PIN . I would suggest to have a look at nrf52840dongle_nrf52840.conf file . We have recovery mode supported with the dongle.