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

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

Parents
  • 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

  • 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.

Reply
  • 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.

Children
Related