Building mesh dfu sample for nRF52840 dongle

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

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

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

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

  • 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

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


  • 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

Related