Building mesh dfu sample for nRF52840 dongle

[AndyM]

Hello

I am trying to build  the Zephyr mesh distributor sample on the nRF 52840 dongle

It builds and runs just find on the nRF52840 DK

But when I try to build for the dongle I get a link error the image is too big to fit in the flash and a lot of other warnings

Tried to disable logging to make the image smaller  - no luck

Log below

Please help

Thank you

---------nrf5284dongle-build.zip-----------------------------------

[tesc]

Hi,

Is this the full build log?

What is the build configuration, and which of the three options do you intend to use for programming the Dongle?

Please note that the nRF52 Dongle is a bit special compared to DKs, as it doesn't contain any interface MCU (on-board programmer). When you choose the nrf52840dongle/nrf52840 board target, the board configuration will assume that you want to keep the existing bootloader which the Dongle was shipped with. This in turn will reduce the remaining available flash.

If you have a debugger and want a full 100 % nRF Connect SDK solution on the Dongle (i.e. no nRF5 based bootloader,) then option 3 (using an external debug probe) is the alternative which will let you use the nRF52840 SoC on the Dongle the corresponding way it is used on a DK. Please note that in addition to the option of soldering an SWD header onto the Dongle, there is also the possibility to connect using a TagConnect cable. For programmer, most J-Link programmers should do, including using the on-board programmer (interface MCU) on a DK from the Debug Out port on the DK.

While written for nRF5 SDK (and not nRF Connect SDK), the nRF52840 Dongle Programming Tutorial also provides some useful information regarding the nRF52840 Dongle. In particular the section Using an external debugger has some useful information regarding how the nRF52840 Dongle works. Please note that the code-related specifics are for nRF5 SDK, but the overall concepts still apply. In nRF Connect SDK, the board specific configurations (such as REGOUT0, the existence of a preprogrammed bootloader, etc.) are handled by the board configuration and/or Kconfig configurations.

Regards,
Terje

[AndyM]

Yes, this is the full build log

I just need to make it easy for end users to program the dongle with the nRF Connect for Desktop programmer app or nrfutil command line tool. So soldering a debug header is not a good option for me. My guess is that my flash space problem is due to the large size of the bootloader that the dongle comes with (about 100K) 

Questions about option 2 (using mcuboot)

1. The docs don't say if mcuboot will be replacing the bootloader or it will be just added 

2. The mesh distributor sample already builds the mcuboot application. Can you elaborate how that would work? Will I have  versions of the mcuboot  if I first load mcuboot on the board as described in option 2?

Thanks

[tesc]

Hi,

For reference, the options are:

1. Using the Built-In Bootloader Only
2. Using MCUboot in Serial Recovery Mode
3. Using an External Debug Probe

For those options, the flash usage is, roughly speaking:

1. Built-in bootloader only:
   1. nRF5 SDK bootloader
   2. application
2. MCUboot in Serial Recovery Mode
   1. nRF5 SDK bootloader
   2. MCUboot
   3. application
3. Using an External Debug Probe
   1. MCUboot
   2. application

Options 1 and 2 can be done without connecting to the Dongle from an external programmer, since all firmware updates uses the nRF5 SDK DFU bootloader which the Dongle is shipped with.

With option 3 you do need a programmer initially, to change from the nRF5 SDK DFU bootloader over to MCUboot. After that first initial step, software updates may happen over serial (e.g. USB), so from that point on the programmer is not needed. This option gives the most freedom for what you do on the device, but the drawback is the need for using a programmer for the first iteration.

With options 1 and 2, the nRF5 SDK DFU bootloader stays on the Dongle. With option 2, you have MCUboot on top of that, and MCUboot can be updated (through use of the nRF5 SDK DFU bootloader.)

AndyM said:

I just need to make it easy for end users to program the dongle with the nRF Connect for Desktop programmer app or nrfutil command line tool.

For this, it sounds like options 1 or 2 are the best choices. Option 1 might have some flash savings compared to option 2.

Regards,
Terje

[AndyM]

The problem is that I'm trying to build the mesh distributor sample which pulls in mcuboot and a lot of other things that make the code so big that it does not fit in the flash. The log  I provided is from a failed build of that sample without any modifications, for the dongle target.
Perhaps you can suggest what functionality can be disabled so the code builds?

Here is the current prj.conf file'

Thank you

#

# Copyright (c) 2022 Nordic Semiconductor ASA

#

# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause

#

# General configuration

CONFIG_BT_COMPANY_ID=0x0A0A

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048

CONFIG_NVS=y

CONFIG_SETTINGS=y

CONFIG_NVS_LOOKUP_CACHE=y

CONFIG_SETTINGS_NVS_NAME_CACHE=y

CONFIG_HWINFO=y

CONFIG_DK_LIBRARY=y

CONFIG_LOG=y

# Bootloader configuration

CONFIG_BOOTLOADER_MCUBOOT=y

CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y

CONFIG_MCUBOOT_GENERATE_CONFIRMED_IMAGE=y

CONFIG_MCUBOOT_IMGTOOL_SIGN_VERSION="1.0.0+0"

# Bluetooth configuration

CONFIG_BT=y

CONFIG_BT_DEVICE_NAME="Mesh DFU"

CONFIG_BT_L2CAP_TX_BUF_COUNT=8

CONFIG_BT_OBSERVER=y

CONFIG_BT_PERIPHERAL=y

CONFIG_BT_SETTINGS=y

CONFIG_BT_ECC=y

CONFIG_BT_TINYCRYPT_ECC=y

# Disable unused Bluetooth features

CONFIG_BT_CTLR_LE_ENC=n

CONFIG_BT_DATA_LEN_UPDATE=n

CONFIG_BT_PHY_UPDATE=n

CONFIG_BT_CTLR_CHAN_SEL_2=n

CONFIG_BT_CTLR_PRIVACY=n

CONFIG_BT_CTLR_PHY_2M=n

# Bluetooth Mesh configuration

# per Nordic devzone.nordicsemi.com/.../mesh-dfu-timeout

CONFIG_BT_MESH_SEG_BUFS=1000

CONFIG_BT_MESH=y

CONFIG_BT_MESH_RELAY=y

CONFIG_BT_MESH_FRIEND=y

CONFIG_BT_MESH_MSG_CACHE_SIZE=256

CONFIG_BT_MESH_ADV_BUF_COUNT=128

CONFIG_BT_MESH_TX_SEG_MAX=10

CONFIG_BT_MESH_RX_SEG_MAX=10

CONFIG_BT_MESH_TX_SEG_MSG_COUNT=2

CONFIG_BT_MESH_RX_SEG_MSG_COUNT=2

CONFIG_BT_MESH_PB_GATT=y

CONFIG_BT_MESH_PB_ADV=y

CONFIG_BT_MESH_GATT_PROXY=y

CONFIG_BT_MESH_SHELL=y

CONFIG_BT_MESH_DK_PROV=y

CONFIG_BT_MESH_PROXY_USE_DEVICE_NAME=y

CONFIG_BT_MESH_MODEL_EXTENSIONS=y

# self provisioning support

CONFIG_BT_MESH_CDB=y

CONFIG_BT_MESH_CFG_CLI=y

# Bluetooth Mesh models

CONFIG_BT_MESH_BLOB_SRV=y

CONFIG_BT_MESH_BLOB_IO_FLASH=y

CONFIG_BT_MESH_BLOB_CLI=y

CONFIG_BT_MESH_DFU_SRV=y

CONFIG_BT_MESH_DFU_METADATA=y

CONFIG_BT_MESH_DFU_METADATA_ON_BUILD=n

CONFIG_BT_MESH_DFU_CLI=y

CONFIG_BT_MESH_DFD_SRV=y

CONFIG_BT_MESH_SAR_CFG_SRV=y

# Reconfigure transport SAR for DFU

# Increase probability of delivering segmented messages

CONFIG_BT_MESH_SAR_TX_UNICAST_RETRANS_COUNT=0x5

CONFIG_BT_MESH_SAR_TX_UNICAST_RETRANS_WITHOUT_PROG_COUNT=0x3

# Reduce amount of generated SegAcks

CONFIG_BT_MESH_SAR_RX_ACK_RETRANS_COUNT=0x0

CONFIG_BT_MESH_SAR_RX_ACK_DELAY_INC=0x7

CONFIG_BT_MESH_SAR_RX_SEG_INT_STEP=0xf

CONFIG_BT_MESH_SAR_RX_SEG_THRESHOLD=0x1f

# Debug configuration

# enable uart driver

# enable console

CONFIG_LOG_BACKEND_UART=y

CONFIG_LOG_BACKEND_RTT=y

CONFIG_PRINTK=y

#CONFIG_PRINTK_SYNC=y

#CONFIG_STDOUT_CONSOLE=y

CONFIG_BT_MESH_LOG_LEVEL_DBG=y

CONFIG_BT_MESH_MODEL_LOG_LEVEL_DBG=y

CONFIG_BT_MESH_DFU_LOG_LEVEL_DBG=y

#CONFIG_BT_MESH_PROVISIONEE_LOG_LEVEL_INF=y

# Additional simultaneous connections for SMP BT.

CONFIG_BT_MAX_CONN=3

CONFIG_BT_CTLR_ADV_SET=6

CONFIG_BT_EXT_ADV_MAX_ADV_SET=6

# One extra identity for SMP service

CONFIG_BT_ID_MAX=2

# MCUmgr shell support

#CONFIG_SHELL_BACKEND_RTT=y

#CONFIG_MCUMGR_GRP_SHELL=y

#CONFIG_SHELL_BACKEND_DUMMY=y

#CONFIG_SHELL_BACKEND_DUMMY_BUF_SIZE=1000

#CONFIG_SEGGER_RTT_BUFFER_SIZE_DOWN=100

# MCUmgr UART transport

CONFIG_BASE64=y

#This causes shell to stop working

#CONFIG_MCUMGR_TRANSPORT_UART=y

CONFIG_SHELL_BACKEND_SERIAL=y

CONFIG_SHELL_BACKENDS=y

CONFIG_SHELL_VT100_COLORS=n

CONFIG_SHELL_VT100_COMMANDS=y

CONFIG_SHELL_CMDS=y

CONFIG_SHELL=y

CONFIG_SHELL_LOG_BACKEND=n  #enable logging via UART

CONFIG_SHELL_PROMPT_UART="mdist:~$ "

CONFIG_UART_ASYNC_API=y

CONFIG_SHELL_ECHO_STATUS=y

CONFIG_SHELL_BACKEND_SERIAL_API_INTERRUPT_DRIVEN=y

[AndyM]

Any updates? Thanks 

[Marte Myrvold]

Hi,

Have you looked at our Memory footprint optimization guide? This gives recommendations for how to reduce the memory footprint of your application.

Best regards,
Marte

[AndyM]

Yes. Most of them apply to RAM although some do apply to flash
Tried several, no luck

Question

The distributor sample has the mcuboot bootloader. 
What happens if I overwrite the Open DFU bootloader that is present on the dongle and just use  the mcuboot to start my app ?
Any side effects I should be aware of?

[tesc]

Hi,

Using MCUboot only is basically the option "3. Using an External Debug Probe" mentioned earlier in this thread. It does require you to connect with a programmer for the initial programming. After that, further DFU can be done over USB using MCUboot. Please note that any application must then be built for use with MCUboot only, which has implications for memory layout.

If at some point you want to "factory reset" the dongle into the state it was shipped with from us, then you need to use a programmer in order to get back to the nRF5 based DFU bootloader. Apart from that, if you are happy with using MCUboot, then the Dongle will now work just as any other custom product out in the field.

Regards,
Terje

[AndyM]

My main hurdle now is that the image does not fit - about 7000 bytes short. Suppose I solve that problem and now I have the image that contains mcuboot and my application. If I load it on a dongle using nRF programmer, will my app run? I need mcuboot  because I plan to use the dongle to distribute firmware updates via mesh