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!

[maximevince]

Thanks, I know how MCUboot works.

I *want* to use the serial recovery mode (actually USB DFU, completely embedded inside of MCUboot),
NOT the firmware upgrade using the application.

In my example there is NO firmware upgrade related code in the application! (No mcumgr, no dual slots needed)

> This feature will do DFU update with single bank mode

This is exactly what I want, and the issue I am trying to raise here, is that this is not supported on nRF53, whenever your main application is using BLE.

Just try to compile your own example for nRF53.

Please re-read my original post, and try to understand what I am reporting here.

[Hung Bui]

Hi Maxime, 
Could you please explain why "this is not supported on nRF53" ? 

I don't see any reason this wouldn't work on nRF53. 

Have you added:

CONFIG_MCUBOOT_SERIAL=y
CONFIG_BOOT_SERIAL_UART=y
CONFIG_UART_CONSOLE=n

Into MCUBoot configuration ?  (and the configuration inside child_image\mcuboot.conf )

Single slot is used automatically when doing recovery mode, you don't need to add SINGLE_APPLICATION_SLOT into the application. 

[maximevince]

Hi Hung Bui,

Thanks for the reply. Yes I tested this, can you please re-read my original post?

Have you tried?  Here is exactly how to reproduce the issue:

* 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 (+ any other options you want, like CONFIG_BOOT_SERIAL_UART=y or CONFIG_BOOT_SERIAL_DETECT_PIN etc...)

Compile using:

west build --board=nrf5340dk_nrf5340_cpuappns -p always

 

Can I ask you please to run these commands on the the latest nRF SDK, and you will run into the issue I first reported. (i.e. hci_rpmsg build fails)

I do not *expect* an issue, but there still is one...

[Hung Bui]

Hi Maxime, 

I still don't really get you, why you need to add CONFIG_SINGLE_APPLICATION_SLOT ? 

Even though it's available in MCUBoot it's not supported in our current nRF Connect SDK. 

You don't need to add CONFIG_SINGLE_APPLICATION_SLOT, if you are planning to do recovery mode (which is single bank DFU).

[maximevince]

Okay,

I actually want to have CONFIG_SINGLE_APPLICATION_SLOT, so that I have the bigger single partition, for maximum application size, because my application is really big. (I'd like to use the roughly twice bigger slot size, versus what a dual-slot setup would give me)

* I understand and accept that I cannot do BLE FOTA anymore. But I still want to be able to use normal BLE operations in my application (thus the CONFIG_BT=y).

* I want to do DFU only through MCUboot, using USB-DFU/serial recovery (never through the application!)

[maximevince]

So, is there a way to achieve this, without specifying CONFIG_SINGLE_APPLICATION_SLOT ?

AFAIK, once I enable CONFIG_BOOTLOADER_MCUBOOT, the Nordic Partition Manager will configure dual slots, right?

[Hung Bui]

It's possible to change the partitions layout. You can simply edit the auto generated partitions.yml to make mcuboot_primary bigger and mcuboot_secondary smaller. After that you save the file as pm_static.yml and place it in the root folder where the prj.conf is. 

But in your case I would suggest to use external flash as secondary slot. This way you can still do BLE DFU. I have made an example for that here.

[maximevince]

Thanks, I'll try the pm_static way. 

My board doesn't have external flash, so that's not an option.