Add mcuboot to connect SDK BLE sample "central and peripheral"

[Andreas3T]

Hi,

I'm trying to add BLE DFU to the nrf connect SDK sample "central and peripheral" for the nRF52832

I've done the following:

Add configurations to proj.conf

# Enable mcumgr.
CONFIG_MCUMGR=y

# Enable most core commands.
CONFIG_MCUMGR_CMD_IMG_MGMT=y
CONFIG_MCUMGR_CMD_OS_MGMT=y

# Ensure an MCUboot-compatible binary is generated.
CONFIG_BOOTLOADER_MCUBOOT=y

# Allow for large Bluetooth data packets.
CONFIG_BT_L2CAP_TX_MTU=252
CONFIG_BT_BUF_ACL_RX_SIZE=256

# Enable the Bluetooth (unauthenticated) and shell mcumgr transports.
CONFIG_MCUMGR_SMP_BT=y
CONFIG_MCUMGR_SMP_BT_AUTHEN=n

# Some command handlers require a large stack.
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096

Created a directory child_image with an empty mcuboot.conf file

When I build it with the command:

west build -b nrf52dk_nrf52832 --pristine

I get the following error:

zephyr/zephyr_pre0.elf section `text' will not fit in region
FLASH' region `FLASH' overflowed by 27752 bytes

Looking at the resulting size with arm-none-eabi-size of the mcuboot zephyr.elf i get:
text  data bss   dec   hex  filename
33082 500  23545 57127 df27 zephyr.elf

And the sizes for the central and peripheral without mcuboot:
Memory region Used Size   Region Size  %age Used
FLASH:        248516 B    512 KB       47.40%

Is there some memory allocated for the DFU slot which causes the overflow?

Thanks in advance,
Best Regards, Andreas

[Hieu]

Hi Andreas,

Is there some memory allocated for the DFU slot which causes the overflow?

There will also be memory allocated for the MCUboot bootloader as well, it is the combination of those that give you that build failure.

If you run the memory report in a project where you can successfully build with DFU, like the Peripheral LBS, you can see the slots in the Partition Manager report.

To get more spaces, you could try to turn off all features unused. In the Peripheral UART sample, there is the prj_minimal.conf config file, where this is demonstrated.

I tried to borrow most of the configs from Peripheral UART over to Central and Peripheral HR and was able to build with MCUboot enabled. However, the ROM usage is still very high 95%. This is without any feature other than in the sample. Depends on your future plan, that number might be too high, and you might want to consider SoC variants with more flash.

Below is a screenshot of the Partition Manager report from my attempt for your reference.

Hieu

[Andreas3T]

Alright, thanks for the help!

[Hieu]

One more thing, there are some other alternatives I forgot to mention.

To make this a summary, the options are:

1. Use an SoC variant with more flash.
2. Adding an external flash.

The following methods are also technically possible, but they are not officially supported, so realizing them will not be trivial, and technical support for them can be limited.

1. A recovery image as discussed in this case:  BLE Recovery Image  .
2. Single application slot DFU with CONFIG_SINGLE_APPLICATION_SLOT.
   • OTA is not possible out of the box with this.
   • OTA can be possible if you move the SMP Server to the bootloader.
     This is also discussed in the Recovery Image case above.
3. Use Nordic Secure Immutable Bootloader as the only bootloader.
   1. A full DFU solution is not supported out of the box. 
   2. OTA is not possible out of the box with this.
   3. Possibility of moving the SMP Server to the bootloader has not been evaluated. Most likely not trivial.
4. Use the nRF5 SDK Secure Bootloader and a SoftDevice as the only bootloader.
   1. Theoretically possible, not yet evaluated.
   2. BLE and Serial OTA supported possible.
   3. Single slot update possible.

Overall, we still recommend changing SoC variant or adding an external flash. Depends on specific use cases and system architecture, the latter four methods, while challenging, can also be considered.

Sorry I am late with those.

[markuckermann]

I've found I could reduce my build size by a lot by not using the Soft Device for bluetooth.

Not sure why this is never recommended or barely mentioned in the docs, but my build went from 230kB (barely fitting on a nrf52832 with FOTA) to just 166KB!

CONFIG_BT_LL_SOFTDEVICE=n
CONFIG_BT_HCI=y
CONFIG_BT_CTLR=y
CONFIG_BT_LL_SW_SPLIT=y

I'm sure the Soft Device is great but since the new SDK doesn't allow the Bootloader & App to share it, and none of the above options are easily supported, it's hard to justify!

I will keep you updated if this change turns out to be problematic in any way.

[Hieu]

markuckermann Interesting discovery. That option didn't occur to me at all.

The SoftDevice Controller is provided as a prebuilt binary with all its features included; meanwhile the Zephyr Controller can be built to include just the features your required. Therefore, it makes sense that you can achieve a smaller size using that controller.

The SoftDevice Controller is optimized for the nRF52 and nRF53 SoCs, so normally we recommend it for development. However, in a situation where flash size saving is of strong interest, using the Zephyr Controller makes sense. 

[markuckermann]

Maybe this is something that could be added to the documentation and taught to your support reps? In our case, it solves most of the problems we were dealing with just by freeing up a good amount of space. Could have saved ~two weeks of project progress & dev work. 

[Andreas3T]

Yeah, that was quite the find. A table with size comparisons would quite useful.

[variant]

Are there any implications for Bluetooth certification when using the Zephyr Bluetooth Controller?

[Hieu]

Thanks a lot variant for raising a good point. I should have included that in my reply.

cc. Andreas3T & markuckermann 

Nordic qualifies the Zephyr Host and the SoftDevice Controller, which you can use in the qualification process for your products. However, we don't qualify the Zephyr Controller, so projects that use it will have to get qualification for the Controller themselves.

As a reference, see the qualification documentation for the nRF52832.

This is a downside of using the Zephyr Controller. My apology for being unable to think of it. I was too focus on the technical aspect and missed non-technical details.

See also: Qualified Design IDs (QDIDs) and Declaration IDs (DIDs) – Bluetooth SIG Inc

[Hieu]

By the way, another disadvantage is that the Zephyr Controller is incompatible with the multi-protocol support in NCS.

I am not saying this to discourage anyone from using the Zephyr Controller. However, since I am around, and since I had said that it is a good idea to save size, I feel compelled to list all disadvantages I know of.