BLE Firmware update using NRF Connect SDK alongside Zephyr RTOS on VS Code.

[Chris_1]

I am trying to implement a firmware update feature via BLE to my already existing application whereby nrf52840 is connecting to an android device via BLE and is sucsessfully sending and receiving data. 

I was trying to follow this: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.3.2/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/README.html#smp-svr-sample-build but I cannot figure out how to create a service where the DFU function is available just as it is possible when programming the NRF52840 using the NRF SDK without the RTOS on Segger.  I also read about the MCUBoot. I added these commands to "prj.conf" file to enable it.

CONFIG_BOOTLOADER_MCUBOOT=y

CONFIG_IMG_MANAGER=y

CONFIG_MCUBOOT_IMG_MANAGER=y

CONFIG_MCUMGR=y

CONFIG_MCUMGR_SMP_BT=y

CONFIG_MCUMGR_SMP_BT_AUTHEN=n

CONFIG_MCUMGR_CMD_IMG_MGMT=y

CONFIG_MCUMGR_CMD_OS_MGMT=y

It is also worth mentioning that I do not want to use an external flash for this project to store the image of the firmware.

In this case, the application takes longer to boot up but I cannot figure out how to make it work. Any help would be appreciated.

Thanks.

[Hung Bui]

Hi Christopher, 

Please follow our guide here on how to integrate the SMP service in your application. 
Basically you need to enable the CONFIG_s and then call smp_bt_register() to register the service. 

[Chris_1]

Many Thanks for your reply. I managed to get it working however, it is taking a very long time to start after system reset. Is there a way to fix this ?

My current proj.conf file is as follows:

CONFIG_BT=y

#CONFIG_BT_DEBUG_LOG=y

#CONFIG_BT_MAX_CONN=1

#CONFIG_BT_L2CAP_TX_BUF_COUNT=5

CONFIG_BT_PERIPHERAL=y

CONFIG_BT_DEVICE_NAME="My_DeviceBT_TEST_HJ840"

#CONFIG_BT_DEVICE_APPEARANCE=962

CONFIG_HEAP_MEM_POOL_SIZE=4096

#CONFIG_BT_CTLR_TX_PWR_MINUS_40=y

#CONFIG_DK_LIBRARY=y

# This example requires more workqueue stack

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096

CONFIG_PM_CPU_OPS=y

CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=n

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=y

CONFIG_CLOCK_CONTROL_NRF_K32SRC_50PPM=n

##CONFIG_TIMESLICING=y

#CONFIG_TIMESLICE_SIZE=50000

#CONFIG_TIMESLICE_PRIORITY=0

CONFIG_GPIO=y

CONFIG_I2C=y

CONFIG_I2C_NRFX=y

CONFIG_SPI=y

# 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

[Hung Bui]

Hi again,

Could you give some more detail on how long it takes ? When you integrate MCUBoot , it will boot first and may do some verification but it shouldn't take a significant time (few hundred ms).Have you checked the log to see at which step it spend it time. You should be able to see the MCUboot log. 

If you have done a DFU , then MCUboot will have to swap the image and the process may take time depends on the size of the image (can be 30 40 seconds)

Have you tried to test with smp_svr to see if the example have the same problem ?