FOTA

Hi,

I'm trying to implement a simple FOTA BLE with MCUBOOT following the instructions in the documentation.

I'm using Visual Studio Code NRF extensions as an IDE, and NRF Connect for Mobile app to do the actual FOTA.

I see that Visual Studio Code is flashing successfully the merged.hex file on the device,

but when I try to do the FOTA of app_update.bin file via the NRF Connect for Mobile app I observe  the following behavior:

1. First FOTA attempt: The file is successfully uploaded, but connection gets disconnected during the validation phase

2. Following FOTA attempts: the connection is disconnected almost immediately, before the file is uploaded.

App prj.conf is:

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096
CONFIG_BT=y
CONFIG_BT_DEBUG_LOG=y
CONFIG_BT_SMP=y
CONFIG_BT_SIGNING=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DIS=n
CONFIG_BT_ATT_PREPARE_COUNT=5
CONFIG_BT_BAS=n
CONFIG_BT_HRS=n
CONFIG_BT_PRIVACY=y
CONFIG_BT_DEVICE_NAME="Dride-4K"
CONFIG_BT_DEVICE_APPEARANCE=833
CONFIG_BT_DEVICE_NAME_DYNAMIC=y
CONFIG_BT_DEVICE_NAME_MAX=256
CONFIG_BT_KEYS_OVERWRITE_OLDEST=y
CONFIG_BT_SETTINGS=y

CONFIG_BT_L2CAP_TX_MTU=512
CONFIG_BT_BUF_ACL_RX_SIZE=512

CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_NVS=y
CONFIG_SETTINGS=y

CONFIG_PRINTK=y
CONFIG_LOG=y
#CONFIG_LOG_PRINTK=y
CONFIG_LOG_MODE_IMMEDIATE=y

CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_SECURE_BOOT=y
CONFIG_BUILD_S1_VARIANT=y
CONFIG_MCUMGR=y
CONFIG_MCUMGR_CMD_OS_MGMT=y
CONFIG_MCUMGR_CMD_IMG_MGMT=y
CONFIG_MCUMGR_SMP_BT=y
CONFIG_MCUMGR_SMP_BT_AUTHEN=n
CONFIG_IMG_MANAGER=y
CONFIG_MCUBOOT_IMG_MANAGER=y

zephyr's prj.conf is:

CONFIG_CONSOLE_HANDLER=y
CONFIG_SYSTEM_CLOCK_DISABLE=y
CONFIG_SYS_POWER_MANAGEMENT=n

CONFIG_MAIN_STACK_SIZE=10240
CONFIG_MBEDTLS_CFG_FILE="mcuboot-mbedtls-cfg.h"

CONFIG_BOOT_SWAP_SAVE_ENCTLV=n
CONFIG_BOOT_ENCRYPT_RSA=n
CONFIG_BOOT_ENCRYPT_EC256=n
CONFIG_BOOT_ENCRYPT_X25519=n

CONFIG_BOOT_UPGRADE_ONLY=n
CONFIG_BOOT_BOOTSTRAP=n

### mbedTLS has its own heap
# CONFIG_HEAP_MEM_POOL_SIZE is not set

### We never want Zephyr's copy of tinycrypt.  If tinycrypt is needed,
### MCUboot has its own copy in tree.
# CONFIG_TINYCRYPT is not set
# CONFIG_TINYCRYPT_ECC_DSA is not set
# CONFIG_TINYCRYPT_SHA256 is not set

CONFIG_FLASH=y
CONFIG_FPROTECT=y

### Various Zephyr boards enable features that we don't want.
# CONFIG_BT is not set
# CONFIG_BT_CTLR is not set
# CONFIG_I2C is not set

CONFIG_LOG=y
CONFIG_PRINTK=y
CONFIG_LOG=y
#CONFIG_LOG_MODE_MINIMAL=y # former CONFIG_MODE_MINIMAL
### Ensure Zephyr logging changes don't use more resources
#CONFIG_LOG_DEFAULT_LEVEL=0
### Decrease footprint by ~4 KB in comparison to CBPRINTF_COMPLETE=y
#CONFIG_CBPRINTF_NANO=y

CONFIG_BOOT_SIGNATURE_KEY_FILE="/path/to/key/file/file.pem"
CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y

main.c:

...

void enable_fota() {
	os_mgmt_register_group();
	img_mgmt_register_group();
	smp_bt_register();
}

void main(void)
{
	int result;

	result = bt_enable(NULL);
	if (result) {
		printk("Bluetooth init failed (err %d)\n", result);
		return;
	}

	enable_fota();

	...

	while (1) {
		k_sleep(K_SECONDS(1));
		...
	}
}

NRF Connect for Mobile first FOTA attempt log:

Subsequent attempts log:

Any help appreciated!

Vitaliy

Parents
  • Hi Vitaliy, 

    Could you let me know which SDK version you are using ? 
    I would suggest to test without the immutable Bootloader (remove CONFIG_SECURE_BOOT=y
    CONFIG_BUILD_S1_VARIANT=y).

    If you simply test the \zephyr\samples\subsys\mgmt\mcumgr\smp_svr (configured with Bluetooth support) example do you see the same issue ? 

  • Hi Hung,

    1. I'm using SDK 1.7.1

    2. Same behavior observed without secure boot

    3. Same behavior observed with smp_svr

    However not it seems to be working! I only played with the state of the switches on the dev board, and now it seems to be working! And I cannot reproduce the previous state where it failed. Is there any HW switch which can effect the DFU process? Perhaps write protects partially flash or anything similar?

    I will continue testing to make sure that the issue is resolved, would appreciate your feedback on what might have caused it, to make sure it will not happen again in production :)

  • Hi Vitaliy, 
    I was suspecting that if you update the exact same image and if the image is already stored in one of the slot the bootloader will skip the image. It's what I have observed. But in my case the image is updated on the first time and run properly and if I tried to update same image again the connection immediately disconnect after the hash is sent. 

Reply Children
Related