Hello,
I have an application that is using mcuboot for bootloader and its a zephyr based application.
I am at a stage, where I able to enter dfu mode by pressing the button on my board and powering on the board. I am able to update signed application via mcumgr (via serial)
When i go though the mcumanager documentation(docs.zephyrproject.org/.../mcumgr.html), it says:
"This tool is provided for evaluation use only and is not recommended for use in a production environment. It has known issues and will not respect the MCUmgr protocol properly e.g. when an error is received, instead of aborting will, in some circumstances, sit in an endless loop of sending the same command over and over again. A universal replacement for this tool is currently in development and once released, support for the go tool will be dropped entirely."
I am build this for production purposes, where user can update their board using windows or mac. But reading the above, makes me think that mcumgr is not ideal to be rolled out to production?
Hence, I started looking into alternatives and looks like dfu-util is stable enough, so I made no changes to my application and tried DFU using dfu-util, but I am not having any success.
When i set my device in bootloader mode, and issue a command "dfu-util -l" I get an error saying: "dfu-util: Cannot open DFU device 2fe3:0005"
I read through some of your posts and it looks like i need to setup my device correctly inorder to make it work with dfu-util? following the example in: zephyr/samples/subsys/usb/dfu/ ?
my current mcuboot.conf and prj.conf files that work with mcumgr are as follows:
prj.cnf
# Config logger
CONFIG_LOG=y
CONFIG_UART_CONSOLE=y
CONFIG_LOG_DEFAULT_LEVEL=3
CONFIG_CONSOLE=n
CONFIG_STDOUT_CONSOLE=y
CONFIG_UART_CONSOLE=y
# Config bluetooth
CONFIG_BT=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DEBUG_LOG=n
CONFIG_BT_DEVICE_NAME="FFRemoteID"
CONFIG_BT_BROADCASTER=y
CONFIG_BT_EXT_ADV=y
CONFIG_BT_EXT_ADV_MAX_ADV_SET=5
# bluetooth 5 long range
CONFIG_BT_CTLR_PHY_CODED=y
CONFIG_BT_CTLR_ADV_DATA_LEN_MAX=255
# Config UART
CONFIG_SERIAL=y
CONFIG_UART_INTERRUPT_DRIVEN=y
# Use internal 32 MGHz crystal
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
# Enable mcumgr.
# CONFIG_MCUMGR=y
CONFIG_BOOTLOADER_MCUBOOT=y
mcuboot.cnf
CONFIG_SIZE_OPTIMIZATIONS=y
CONFIG_SINGLE_APPLICATION_SLOT=y
# Enable MCUboot Serial Recovery
CONFIG_MCUBOOT_SERIAL=y
CONFIG_UART_CONSOLE=n
# Point Serial Recovery to CDC_ACM
CONFIG_BOOT_SERIAL_CDC_ACM=y
CONFIG_MCUBOOT_INDICATION_LED=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
# Enable wait for DFU functionality
# CONFIG_BOOT_SERIAL_WAIT_FOR_DFU=y
# CONFIG_BOOT_SERIAL_WAIT_FOR_DFU_TIMEOUT=10000
CONFIG_BOOT_USB_DFU_GPIO=y
NOTE: all of my dev work has been done on ubuntu 22, using v2.4.0 toolchain, but I am trying to make this application such that a user can update this using windows or mac
can you please answer my questions:
- what changes do i need to make to my prj.cnf and mcuboot.cnf file so that it works with dfu-util?
- I tried running the example application in: zephyr/samples/subsys/usb/dfu/ , but when i set CONFIG_BOOTLOADER_MCUBOOT=y , I don't see a merged.hex file getting generated so I am assuming the example is not working the way it is supposed to? I am building the application using nfrconnect extension on VS code. Is there anything I am not doing correctly?
- Is mcumgr not recommended for production applications?
- is dfu-util not compatible/recommended for nrf52840 chips (its mounted on my custom board)? I ask this because I was going over your one of the tickets (https://devzone.nordicsemi.com/f/nordic-q-a/103932/i-m-trying-to-perform-usb-dfu-with-nrf-connect-sdk-ver2-4-2-but-an-error-occurs-with-duf-util ) and it sounded like your support tech was recommending using mcumgr over dfu-util?
- can you please point me to any example that talks about configuring app for DFU? I have gone through the existing examples, and most/all of them use mcumgr for dfu
- Is there a recommended procedure/application that you recommend for a reliable DFU for nrf52840 chips, running zephyr application and using mcuboot. once its in production and out to the world?
I am being very cautious because I dont want out users to get locked out and not be able to update their chips if and ever we have an update. I am looking for a solution that I know will work forever.
Please let me know if you need any more details from me.
Kind regards,
Viresh Duvvuri
