• State Verified Answer
  • Replies 2 replies
  • Subscribers 97 subscribers
  • Views 1262 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 304551
Options

NCS Mesh DFU

Jeremy

Starting with the unaltered application template 'zephyr/samples/bluetooth/mesh', I attempted to add DFU support by following this guide.

I added the following lines to 'prj.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

And I also added the following 3 includes to 'main.c':

#include <zephyr/mgmt/mcumgr/smp_bt.h>
#include "os_mgmt/os_mgmt.h"
#include "img_mgmt/img_mgmt.h"

Even before trying to set up the SMP service UUID or adding the registration hooks, I attempted to build the project, and it already overflows the flash ("region `FLASH' overflowed by 78620 bytes"). This is with debug options disabled, and if I try to turn them on in the build configuration my overflow jumps to 178552 bytes.

I'm new to NCS, but running 'ninja partition_manager_report' returns:

  flash_primary (0x80000 - 512kB): 
+-------------------------------------------------+
| 0x0: mcuboot (0xc000 - 48kB)                    |
+---0xc000: mcuboot_primary (0x39000 - 228kB)-----+
| 0xc000: mcuboot_pad (0x200 - 512B)              |
+---0xc200: mcuboot_primary_app (0x38e00 - 227kB)-+
| 0xc200: app (0x38e00 - 227kB)                   |
+-------------------------------------------------+
| 0x45000: mcuboot_secondary (0x39000 - 228kB)    |
| 0x7e000: settings_storage (0x2000 - 8kB)        |
+-------------------------------------------------+

  sram_primary (0x20000 - 128kB): 
+--------------------------------------------+
| 0x20000000: sram_primary (0x20000 - 128kB) |
+--------------------------------------------+

which looks reasonable at least.

My understanding is that MCUBoot only operates with multiple banks and there is no way to perform a single-bank update? Does this mean that NCS is not suitable for an DFU capable Mesh application on the nRF528333, or is there some more efficient way to set this up? Unfortunately I'm designing for legacy hardware so adding external flash memory is not an option.

Additionally, is it normal for an NCS application image to be so much larger then a nRF5 / nRF Mesh SDK image? Stripping out MCUBoot, just the Mesh example without debug options compiles to use ~308kB of flash, where my nRF5 project implementing custom models and event handling is ~140kB. The nRF5 code is sitting on top of a 160kB SoftDevice which brings things closer, but I don't need to update the SoftDevice to update my application which is a huge advantage.

Thanks,
Jeremy

Parents
  • +1

    Hello Jeremy,

    Unfortunately, it is not possible to update only the application and not the SoftDevice Controller in NCS, because these are not split as they were in the nRF5 SDK. Also, apart from "serial recovery", which would require a serial connection with the nRF, it is not possible to do a single bank solution, because the bootloader is using "background DFU", where the new application image is transferred while the application is running, much like it is in the nRF5 SDK for Mesh DFU. This means that the bootloader doesn't have any means of transferring the image, which means it is not possible to delete the old application and then transfer the new one (as you could in the nRF5 SDK). 

    This is probably not the answer you wanted to hear, but it is the way it is in NCS. I would say that it makes it very difficult to run a DFU with Mesh on an nRF52832/nRF52833 without external flash.

    Best regards,

    Edvin

Reply
  • +1

    Hello Jeremy,

    Unfortunately, it is not possible to update only the application and not the SoftDevice Controller in NCS, because these are not split as they were in the nRF5 SDK. Also, apart from "serial recovery", which would require a serial connection with the nRF, it is not possible to do a single bank solution, because the bootloader is using "background DFU", where the new application image is transferred while the application is running, much like it is in the nRF5 SDK for Mesh DFU. This means that the bootloader doesn't have any means of transferring the image, which means it is not possible to delete the old application and then transfer the new one (as you could in the nRF5 SDK). 

    This is probably not the answer you wanted to hear, but it is the way it is in NCS. I would say that it makes it very difficult to run a DFU with Mesh on an nRF52832/nRF52833 without external flash.

    Best regards,

    Edvin

Children
Related
Terms of service