nrf5340 multi-image DFU update over BLE 'Remote Error: In Value(3)' ?

Hi guys - need your help on this!

nrf5340 based board with no external flash (so using nrf5340 on chip flash only)

using SDK v2.3.0 on MacOS

testing DFU update using nrf Connect Mobile on iOS v2.6.7, Build 34 
(as well as testing in our own iOS app)

The problem:

DFU OTA over BLE update of the Application Image using "app_update.bin" has worked for a long time & we have no problems with it. This works perfectly BOTH in nrf Connect for iOS well as in our own iOS application. Has worked reliably for more than 1 year now. 

However, occasionally we need to do a "simultaneous" multi-image update of BOTH the Application & Network Cores.
We can't get this to work & have tried many different configuration options. We always get the error "'Remote Error: In Value(3)" in nrfConnect Mobile on iOS (as well as in our own iOS application which includes DFU updates).  Have tried it numerous times with AND without the "Erase App Settings" switch set on (or off). The setting of the "Erase App Settings" seems to make no difference on the error returned.

I have read/studied the following:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/working_with_nrf/nrf53/nrf5340.html#fota-updates 

and

https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/nrf5340

as well as read all the other related cases on devzone. But somehow I/we can't get it to work in our own firmware builds! So I must be missing or overlooked something fundamental!

Below are some screenshots from nrf Connect Mobile for iOS showing "success" when using "app_update_bin" but failure when using "DFU_application.zip". 
I have also included the log from nrf Connect for iOS when it fails with the multi-image update.

Below are copies of our prj.conf, hci_rpmsg.conf & mcuboot.conf

#
# Copyright (c) 2021 WearSense LLC
#

# WEARSENSE FIRMWARE REVISION TO BE UPDATED HERE!!!
CONFIG_BT_DIS_FW_REV_STR="09.21"

# CONFIG_WATCHDOG=y
CONFIG_REBOOT=y

# Activate Power Management (reduce power requirements
# see: https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/optimizing-power-on-nrf53-designs
CONFIG_PM=y
CONFIG_PM_DEVICE=y
CONFIG_PM_DEVICE_RUNTIME=y
CONFIG_BOARD_ENABLE_DCDC_APP=y
CONFIG_BOARD_ENABLE_DCDC_NET=y
CONFIG_BOARD_ENABLE_DCDC_HV=y
CONFIG_SERIAL=n

# Errata 160 included in v2.3.0 - ensure System Clock is enabled
CONFIG_SYS_CLOCK_EXISTS=y

# to enable RTT logging (for debugging) - change next 2 lines to "=y"
# NOTE: set both "=n" for optimal power optimization (so disable for "production" or battery life/power monitor tests)
CONFIG_LOG=n
CONFIG_USE_SEGGER_RTT=n

CONFIG_RESET_ON_FATAL_ERROR=y   # not sure this works for non "Nordic DK" boards!?       
CONFIG_ASSERT=n    # crashes i2c init when turned on (=y) with RTT logging - need to investigate...!?

CONFIG_LOG_DEFAULT_LEVEL=3
# CONFIG_LOG_PROCESS_THREAD_STACK_SIZE=2048

# Debugging configuration
# CONFIG_THREAD_NAME=y
# CONFIG_THREAD_ANALYZER=y
# CONFIG_THREAD_ANALYZER_AUTO=y
# CONFIG_THREAD_ANALYZER_RUN_UNLOCKED=y
# CONFIG_THREAD_ANALYZER_USE_PRINTK=y

# CONFIG_ASSERT_VERBOSE=y
# CONFIG_ASSERT_NO_COND_INFO=n
# CONFIG_ASSERT_NO_MSG_INFO=n

# disable all things related to uarts, usb & console (for max power savings) - CONFIG_SERIAL=n already set above
CONFIG_CONSOLE=n
# CONFIG_STDOUT_CONSOLE=n
# CONFIG_USB_DEVICE_STACK=m
# CONFIG_TFM_LOG_LEVEL_SILENCE=y
# CONFIG_LOG_BACKEND_UART

# set stack & heap sizes.
CONFIG_HEAP_MEM_POOL_SIZE=8192
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=8192
CONFIG_MAIN_STACK_SIZE=4096
CONFIG_BT_RX_STACK_SIZE=4096

# Disable the DK (nordic dev Boards) LED and Buttons library for WearSense boards
CONFIG_DK_LIBRARY=n

# required for generating random number for suffix of original BLE NAME set for device. 
CONFIG_ENTROPY_GENERATOR=y
CONFIG_ENTROPY_DEVICE_RANDOM_GENERATOR=y

# configure Settimgs to be stored in NVS Flash on nrf5340 SoC
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_NVS=y
CONFIG_SETTINGS=y
CONFIG_SETTINGS_NVS=y
CONFIG_SETTINGS_RUNTIME=y

# BLE Settings
CONFIG_BT=y
CONFIG_BT_SETTINGS=n                        # for now we take care of our own BLE settings.
CONFIG_BT_CENTRAL=n
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DEVICE_NAME="WearSense Sensor"    # Name is re-defined & replaced at runtime
CONFIG_BT_DEVICE_NAME_DYNAMIC=y
CONFIG_BT_MAX_CONN=1
CONFIG_BT_MAX_PAIRED=1

# appearance 1344 = "Generic Sensor" 
# (see: https://specificationrefs.bluetooth.com/assigned-values/Appearance%20Values.pdf )
CONFIG_BT_DEVICE_APPEARANCE=1344

# configure BLE "Device Information Service" (BT_DIS) characteristics.
CONFIG_BT_DIS=y
CONFIG_BT_DIS_MODEL="WearSense LS2"
CONFIG_BT_DIS_MANUF="wear-sense.com"
CONFIG_BT_DIS_FW_REV=y
CONFIG_BT_DIS_SETTINGS=y            # allows following values to be assigned at runtime
CONFIG_BT_DIS_SERIAL_NUMBER=y       # assigned at runtime in code
CONFIG_BT_DIS_HW_REV=y              # assigned at runtime in code
CONFIG_BT_DIS_SW_REV=n              # not required for WearSense app. 
CONFIG_BT_DIS_PNP=n                 # not required for WearSense app.

CONFIG_BT_NUS=y         # Enable the NUS service (in advertising)

CONFIG_BT_BAS=y         # Enable the Battery Level service (in advertising)

CONFIG_BT_USER_DATA_LEN_UPDATE=y
#This is the maximum data length with Nordic Softdevice controller
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
#These buffers are needed for the data length max. 
CONFIG_BT_BUF_ACL_TX_SIZE=251
CONFIG_BT_BUF_ACL_RX_SIZE=251
#This is the maximum MTU size with Nordic Softdevice controller
CONFIG_BT_L2CAP_TX_MTU=247

CONFIG_BT_GAP_PERIPHERAL_PREF_PARAMS=y
CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS=y

# set BLE 'connect parameters' for lowest power consumption 
# so lower data transfer speed but low power when connected but not sending data... 
# 36 = 30ms, 48 = 60ms
# 30 = able to 'miss' max of 30 intervals of 60ms each to keep BLE connection alive.
# 600 = 6000 ms - max allowed by Apple (& probably others)
CONFIG_BT_PERIPHERAL_PREF_MIN_INT=36
CONFIG_BT_PERIPHERAL_PREF_MAX_INT=48    
CONFIG_BT_PERIPHERAL_PREF_LATENCY=30
CONFIG_BT_PERIPHERAL_PREF_TIMEOUT=600

CONFIG_NEWLIB_LIBC=y
CONFIG_NEWLIB_LIBC_FLOAT_PRINTF=y
CONFIG_NEWLIB_LIBC_FLOAT_SCANF=y

# Enable mcumgr (used for reset over BLE and OTA firmware updates).
CONFIG_MCUMGR=y

# Ensure an MCUboot-compatible binary is generated.
CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_MCUMGR_SMP_BT=y
CONFIG_MCUMGR_SMP_BT_AUTHEN=n
CONFIG_DFU_MULTI_IMAGE=y
CONFIG_DFU_MULTI_IMAGE_MAX_IMAGE_COUNT=2
CONFIG_NRF53_UPGRADE_NETWORK_CORE=y
CONFIG_MCUBOOT_IMG_MANAGER=y

# Enable core DFU/OTA features.
CONFIG_MCUMGR_CMD_IMG_MGMT=y
CONFIG_MCUMGR_CMD_OS_MGMT=y
CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y

# set BLE 'Connect Interval' Parameters for SMP (used for OTA) to fastest possible transfer speed..
CONFIG_MCUMGR_SMP_BT_CONN_PARAM_CONTROL=y
CONFIG_MCUMGR_SMP_BT_CONN_PARAM_CONTROL_MIN_INT=12
CONFIG_MCUMGR_SMP_BT_CONN_PARAM_CONTROL_MAX_INT=12
CONFIG_MCUMGR_SMP_BT_CONN_PARAM_CONTROL_LATENCY=0
CONFIG_MCUMGR_SMP_BT_CONN_PARAM_CONTROL_TIMEOUT=200 

CONFIG_MCUMGR_SMP_WORKQUEUE_STACK_SIZE=8192
             
# Enable the SAADC ADC support
CONFIG_ADC=y
CONFIG_ADC_ASYNC=y
CONFIG_ADC_NRFX_SAADC=y

CONFIG_FPU=y

# I2C required to read Pressure Sensor & Accelerometer
CONFIG_I2C=y

#
# Copyright (c) 2021 Nordic Semiconductor ASA
#
# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
#

# required for max power savings!
CONFIG_LOG=n #changed
CONFIG_SERIAL=n
CONFIG_CONSOLE=n

CONFIG_IPC_SERVICE=y
# CONFIG_IPC_SERVICE_BACKEND_RPMSG=y
CONFIG_IPC_SERVICE_BACKEND_RPMSG_WQ_STACK_SIZE=4096
CONFIG_BT_RX_STACK_SIZE=4096

# BLE Settings
CONFIG_BT=y
# CONFIG_BT_SETTINGS=n      # for now we take care of our own BLE settings (no pairing, etc).
CONFIG_BT_CENTRAL=n
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_HCI=y
CONFIG_BT_HCI_RAW=y
CONFIG_BT_MAX_CONN=2
CONFIG_BT_CTLR_ASSERT_HANDLER=n     # would like to set this to "y" & handle in application code. Checking with devzone!

#For data length update
CONFIG_BT_USER_DATA_LEN_UPDATE=y
#This is the maximum data length with Nordic Softdevice controller
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
#These buffers are needed for the data length max. 
CONFIG_BT_BUF_ACL_TX_SIZE=251
CONFIG_BT_BUF_ACL_RX_SIZE=251
#This is the maximum MTU size with Nordic Softdevice controller
CONFIG_BT_L2CAP_TX_MTU=247

# CONFIG_MCUBOOT_LOG_LEVEL_WRN=y
CONFIG_SERIAL=n
CONFIG_CONSOLE=n

 

Would really appreciate if you guys could have a quick look at this & let me know what I am missing!

Thanking you in anticipation

Best Regards

Gerard

Parents
  • Hi Gerard,

    I'm looking into reproducing the issue your issue, but in the meanwhile I am curious if you're able to get simultaneous DFU for the 5340 to work with any of the following tests

    1. The 5340 sample from the repository you linked?
    2. Test with any other sample known to work with DFU support such the smp sample with bluetooth (https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/README.html
    3. Try with an Android phone instead? If this is successful, then it is a bug in the iOS version of the application

    Let me know about the results and I'll get relay this to the relevant team(s) and consult closer with them

    Kind regards,
    Andreas

  • Hi Andreas

    Unfortunately I am traveling until Thursday - so don't have all my tools and/or devices handy to test 1 & 2 above. So will have to try that later.

    I had in fact tried it on Android and got the same error. As I originally tried it on a fairly old Android device, I just tried it again (an hour or two ago) on a recent Lenovo Tab M10 HD running Android 11 and the latest nrf Connect app for Android. Same problem.

    Below is a copy of the log from that Lenovo Android tablet (the DFU UI for the nrf Android App is definitely not as nice as the iOS app - it doesn't clearly show the result of the DFU update in the UI! - only the log shows the error)..

    nRF Connect, 2023-06-13
    Rev2 #6 (FC:A5:C3:35:34:F7)
    	19:26:12.961	gatt.close()
    D	19:26:12.962	wait(200)
    V	19:26:13.164	Connecting to FC:A5:C3:35:34:F7...
    D	19:26:13.164	gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, preferred PHY = LE 1M)
    D	19:26:14.297	[Callback] Connection state changed with status: 0 and new state: CONNECTED (2)
    I	19:26:14.297	Connected to FC:A5:C3:35:34:F7
    D	19:26:14.298	[Broadcast] Action received: android.bluetooth.device.action.ACL_CONNECTED
    V	19:26:14.331	Discovering services...
    D	19:26:14.357	gatt.discoverServices()
    I	19:26:14.697	Connection parameters updated (interval: 7.5ms, latency: 0, timeout: 5000ms)
    I	19:26:14.755	PHY updated (TX: LE 2M, RX: LE 2M)
    D	19:26:15.143	[Callback] Services discovered with status: 0
    I	19:26:15.144	Services discovered
    V	19:26:15.183	Generic Attribute (0x1801)
    - Service Changed [I] (0x2A05)
       Client Characteristic Configuration (0x2902)
    - Client Supported Features [R W] (0x2B29)
    - Database Hash [R] (0x2B2A)
    Generic Access (0x1800)
    - Device Name [R W] (0x2A00)
    - Appearance [R] (0x2A01)
    - Peripheral Preferred Connection Parameters [R] (0x2A04)
    Battery Service (0x180F)
    - Battery Level [N R] (0x2A19)
       Client Characteristic Configuration (0x2902)
    Device Information (0x180A)
    - Model Number String [R] (0x2A24)
    - Manufacturer Name String [R] (0x2A29)
    - Serial Number String [R] (0x2A25)
    - Firmware Revision String [R] (0x2A26)
    - Hardware Revision String [R] (0x2A27)
    Nordic UART Service (6e400001-b5a3-f393-e0a9-e50e24dcca9e)
    - TX Characteristic [N] (6e400003-b5a3-f393-e0a9-e50e24dcca9e)
       Client Characteristic Configuration (0x2902)
    - RX Characteristic [W WNR] (6e400002-b5a3-f393-e0a9-e50e24dcca9e)
    SMP Service (8d53dc1d-1db7-4cd3-868b-8a527460aa84)
    - SMP Characteristic [N WNR] (da2e7828-fbce-4e01-ae9e-261174997c48)
       Client Characteristic Configuration (0x2902)
    D	19:26:15.186	gatt.setCharacteristicNotification(00002a05-0000-1000-8000-00805f9b34fb, true)
    D	19:26:15.189	gatt.setCharacteristicNotification(00002a19-0000-1000-8000-00805f9b34fb, true)
    D	19:26:15.192	gatt.setCharacteristicNotification(6e400003-b5a3-f393-e0a9-e50e24dcca9e, true)
    I	19:26:15.254	Connection parameters updated (interval: 48.75ms, latency: 0, timeout: 5000ms)
    I	19:26:19.597	Connection parameters updated (interval: 52.5ms, latency: 30, timeout: 6000ms)
    V	19:32:58.513	[McuMgr] Connecting...
    D	19:32:58.532	[McuMgr] gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, LE 1M)
    D	19:32:58.610	[McuMgr] [Callback] Connection state changed with status: 0 and new state: 2 (CONNECTED)
    I	19:32:58.623	[McuMgr] Connected to FC:A5:C3:35:34:F7
    D	19:32:58.634	[McuMgr] wait(300)
    V	19:32:58.947	[McuMgr] Discovering services...
    D	19:32:58.961	[McuMgr] gatt.discoverServices()
    I	19:32:58.986	[McuMgr] Services discovered
    V	19:32:59.001	[McuMgr] Primary service found
    V	19:32:59.024	[McuMgr] Requesting new MTU...
    D	19:32:59.041	[McuMgr] gatt.requestMtu(498)
    I	19:32:59.858	[McuMgr] MTU changed to: 247
    D	19:32:59.878	[McuMgr] gatt.setCharacteristicNotification(da2e7828-fbce-4e01-ae9e-261174997c48, true)
    V	19:32:59.893	[McuMgr] Enabling notifications for da2e7828-fbce-4e01-ae9e-261174997c48
    D	19:32:59.907	[McuMgr] descriptor.setValue(0x01-00)
    D	19:32:59.921	[McuMgr] gatt.writeDescriptor(00002902-0000-1000-8000-00805f9b34fb)
    I	19:33:01.592	[McuMgr] Data written to descr. 00002902-0000-1000-8000-00805f9b34fb
    I	19:33:01.608	[McuMgr] Notifications enabled
    V	19:33:01.624	[McuMgr] Waiting for value change...
    V	19:33:01.638	[McuMgr] Writing characteristic da2e7828-fbce-4e01-ae9e-261174997c48 (WRITE COMMAND)
    D	19:33:01.654	[McuMgr] characteristic.setValue(0x000000010000FF06A0)
    D	19:33:01.668	[McuMgr] characteristic.setWriteType(WRITE COMMAND)
    D	19:33:01.684	[McuMgr] gatt.writeCharacteristic(da2e7828-fbce-4e01-ae9e-261174997c48)
    I	19:33:01.699	[McuMgr] Data written to da2e7828-fbce-4e01-ae9e-261174997c48
    W	19:33:02.638	[McuMgr] Request timed out
    A	19:33:02.660	[McuMgr] Sending (10 bytes) Header (Op: 0, Flags: 0, Len: 2, Group: 1, Seq: 0, Command: 0) CBOR {}
    V	19:33:02.676	[McuMgr] Writing characteristic da2e7828-fbce-4e01-ae9e-261174997c48 (WRITE COMMAND)
    D	19:33:02.693	[McuMgr] characteristic.setValue(0x0000000200010000BFFF)
    D	19:33:02.708	[McuMgr] characteristic.setWriteType(WRITE COMMAND)
    D	19:33:02.721	[McuMgr] gatt.writeCharacteristic(da2e7828-fbce-4e01-ae9e-261174997c48)
    I	19:33:02.803	[McuMgr] Data written to da2e7828-fbce-4e01-ae9e-261174997c48
    I	19:33:03.325	[McuMgr] Notification received from da2e7828-fbce-4e01-ae9e-261174997c48, value: (0x) 01-00-00-06-00-00-FF-06-BF-62-72-63-08-FF
    A	19:33:03.343	[McuMgr] Received Header (Op: 1, Flags: 0, Len: 6, Group: 0, Seq: 255, Command: 6) CBOR {"rc":8}
    W	19:33:03.360	[McuMgr] Error: NOT_SUPPORTED (8)
    I	19:33:03.484	[McuMgr] Notification received from da2e7828-fbce-4e01-ae9e-261174997c48, value: (0x) 01-00-00-F4-00-01-00-00-BF-66-69-6D-61-67-65-73-9F-BF-64-73-6C-6F-74-00-67-76-65-72-73-69-6F-6E-65-30-2E-30-2E-30-64-68-61-73-68-58-20-6E-63-66-05-46-FC-33-A5-5E-35-85-CC-EC-20-91-D1-71-C2-4F-D1-A8-BA-45-1E-96-9B-7B-B9-6A-30-F0-19-68-62-6F-6F-74-61-62-6C-65-F5-67-70-65-6E-64-69-6E-67-F4-69-63-6F-6E-66-69-72-6D-65-64-F5-66-61-63-74-69-76-65-F5-69-70-65-72-6D-61-6E-65-6E-74-F4-FF-BF-64-73-6C-6F-74-01-67-76-65-72-73-69-6F-6E-65-30-2E-30-2E-30-64-68-61-73-68-58-20-9D-E6-5E-67-CB-B0-0E-A5-92-09-82-3D-D6-7E-DF-29-FF-AA-23-F9-C3-CE-0F-FC-E3-81-3A-03-C5-A2-FE-BD-68-62-6F-6F-74-61-62-6C-65-F5-67-70-65-6E-64-69-6E-67-F4-69-63-6F-6E-66-69-72-6D-65-64-F4-66-61-63-74-69-76-65-F4-69-70-65-72-6D-61-6E-65-6E-74-F4-FF-FF-6B-73-70-6C-69-74
    I	19:33:03.599	[McuMgr] Notification received from da2e7828-fbce-4e01-ae9e-261174997c48, value: (0x) 53-74-61-74-75-73-00-FF
    A	19:33:03.617	[McuMgr] Received Header (Op: 1, Flags: 0, Len: 244, Group: 1, Seq: 0, Command: 0) CBOR {"images":[{"slot":0,"version":"0.0.0","hash":"bmNmBUb8M6VeNYXM7CCR0XHCT9GoukUelpt7uWow8Bk=","bootable":true,"pending":false,"confirmed":true,"active":true,"permanent":false},{"slot":1,"version":"0.0.0","hash":"neZeZ8uwDqWSCYI91n7fKf+qI/nDzg/844E6A8Wi/r0=","bootable":true,"pending":false,"confirmed":false,"active":false,"permanent":false}],"splitStatus":0}
    V	19:33:03.652	[McuMgr] Uploading firmware...
    I	19:33:13.253	Connection parameters updated (interval: 15.0ms, latency: 0, timeout: 2000ms)
    A	19:33:42.548	[McuMgr] 175347 bytes sent in 34969 ms (5.01 kB/s)
    A	19:34:12.929	[McuMgr] 144610 bytes sent in 27111 ms (5.33 kB/s)
    A	19:34:12.971	[McuMgr] Sending (10 bytes) Header (Op: 2, Flags: 0, Len: 2, Group: 63, Seq: 186, Command: 0) CBOR {}
    V	19:34:12.987	[McuMgr] Writing characteristic da2e7828-fbce-4e01-ae9e-261174997c48 (WRITE COMMAND)
    D	19:34:13.003	[McuMgr] characteristic.setValue(0x02000002003FBA00BFFF)
    D	19:34:13.017	[McuMgr] characteristic.setWriteType(WRITE COMMAND)
    D	19:34:13.033	[McuMgr] gatt.writeCharacteristic(da2e7828-fbce-4e01-ae9e-261174997c48)
    I	19:34:13.051	[McuMgr] Data written to da2e7828-fbce-4e01-ae9e-261174997c48
    I	19:34:13.186	[McuMgr] Notification received from da2e7828-fbce-4e01-ae9e-261174997c48, value: (0x) 03-00-00-06-00-3F-BA-00-BF-62-72-63-08-FF
    A	19:34:13.202	[McuMgr] Received Header (Op: 3, Flags: 0, Len: 6, Group: 63, Seq: 186, Command: 0) CBOR {"rc":8}
    W	19:34:13.220	[McuMgr] Error: NOT_SUPPORTED (8)
    V	19:34:13.250	[McuMgr] New state: CONFIRM
    A	19:34:13.269	[McuMgr] Sending (58 bytes) Header (Op: 2, Flags: 0, Len: 50, Group: 1, Seq: 187, Command: 0) CBOR {"confirm":true,"hash":"neZeZ8uwDqWSCYI91n7fKf+qI/nDzg/844E6A8Wi/r0="}
    V	19:34:13.283	[McuMgr] Writing characteristic da2e7828-fbce-4e01-ae9e-261174997c48 (WRITE COMMAND)
    D	19:34:13.300	[McuMgr] characteristic.setValue(0x020000320001BB00BF67636F6E6669726DF5646861736858209DE65E67CBB00EA59209823DD67EDF29FFAA23F9C3CE0FFCE3813A03C5A2FEBDFF)
    D	19:34:13.315	[McuMgr] characteristic.setWriteType(WRITE COMMAND)
    D	19:34:13.331	[McuMgr] gatt.writeCharacteristic(da2e7828-fbce-4e01-ae9e-261174997c48)
    I	19:34:13.367	[McuMgr] Data written to da2e7828-fbce-4e01-ae9e-261174997c48
    I	19:34:13.387	[McuMgr] Notification received from da2e7828-fbce-4e01-ae9e-261174997c48, value: (0x) 03-00-00-F4-00-01-BB-00-BF-66-69-6D-61-67-65-73-9F-BF-64-73-6C-6F-74-00-67-76-65-72-73-69-6F-6E-65-30-2E-30-2E-30-64-68-61-73-68-58-20-6E-63-66-05-46-FC-33-A5-5E-35-85-CC-EC-20-91-D1-71-C2-4F-D1-A8-BA-45-1E-96-9B-7B-B9-6A-30-F0-19-68-62-6F-6F-74-61-62-6C-65-F5-67-70-65-6E-64-69-6E-67-F4-69-63-6F-6E-66-69-72-6D-65-64-F5-66-61-63-74-69-76-65-F5-69-70-65-72-6D-61-6E-65-6E-74-F4-FF-BF-64-73-6C-6F-74-01-67-76-65-72-73-69-6F-6E-65-30-2E-30-2E-30-64-68-61-73-68-58-20-9D-E6-5E-67-CB-B0-0E-A5-92-09-82-3D-D6-7E-DF-29-FF-AA-23-F9-C3-CE-0F-FC-E3-81-3A-03-C5-A2-FE-BD-68-62-6F-6F-74-61-62-6C-65-F5-67-70-65-6E-64-69-6E-67-F5-69-63-6F-6E-66-69-72-6D-65-64-F4-66-61-63-74-69-76-65-F4-69-70-65-72-6D-61-6E-65-6E-74-F5-FF-FF-6B-73-70-6C-69-74
    I	19:34:13.550	[McuMgr] Notification received from da2e7828-fbce-4e01-ae9e-261174997c48, value: (0x) 53-74-61-74-75-73-00-FF
    A	19:34:13.570	[McuMgr] Received Header (Op: 3, Flags: 0, Len: 244, Group: 1, Seq: 187, Command: 0) CBOR {"images":[{"slot":0,"version":"0.0.0","hash":"bmNmBUb8M6VeNYXM7CCR0XHCT9GoukUelpt7uWow8Bk=","bootable":true,"pending":false,"confirmed":true,"active":true,"permanent":false},{"slot":1,"version":"0.0.0","hash":"neZeZ8uwDqWSCYI91n7fKf+qI/nDzg/844E6A8Wi/r0=","bootable":true,"pending":true,"confirmed":false,"active":false,"permanent":true}],"splitStatus":0}
    A	19:34:13.594	[McuMgr] Sending (58 bytes) Header (Op: 2, Flags: 0, Len: 50, Group: 1, Seq: 188, Command: 0) CBOR {"confirm":true,"hash":"xhM+D4xfppfMoSthxdXuZU3MILMoVJ4t8XuBgpQYgb4="}
    V	19:34:13.612	[McuMgr] Writing characteristic da2e7828-fbce-4e01-ae9e-261174997c48 (WRITE COMMAND)
    D	19:34:13.626	[McuMgr] characteristic.setValue(0x020000320001BC00BF67636F6E6669726DF564686173685820C6133E0F8C5FA697CCA12B61C5D5EE654DCC20B328549E2DF17B8182941881BEFF)
    D	19:34:13.641	[McuMgr] characteristic.setWriteType(WRITE COMMAND)
    D	19:34:13.656	[McuMgr] gatt.writeCharacteristic(da2e7828-fbce-4e01-ae9e-261174997c48)
    I	19:34:13.675	[McuMgr] Data written to da2e7828-fbce-4e01-ae9e-261174997c48
    I	19:34:13.697	[McuMgr] Notification received from da2e7828-fbce-4e01-ae9e-261174997c48, value: (0x) 03-00-00-06-00-01-BC-00-BF-62-72-63-03-FF
    A	19:34:13.719	[McuMgr] Received Header (Op: 3, Flags: 0, Len: 6, Group: 1, Seq: 188, Command: 0) CBOR {"rc":3}
    W	19:34:13.733	[McuMgr] Error: IN_VALUE (3)
    V	19:34:13.908	[McuMgr] Disconnecting...
    D	19:34:13.925	[McuMgr] gatt.disconnect()
    D	19:34:13.947	[McuMgr] [Callback] Connection state changed with status: 0 and new state: 0 (DISCONNECTED)
    I	19:34:13.962	[McuMgr] Disconnected
    D	19:34:13.980	[McuMgr] gatt.close()
    I	19:34:18.900	Connection parameters updated (interval: 52.5ms, latency: 30, timeout: 6000ms)
    

    Note line 114, which reads:

    19:34:13.733 [McuMgr] Error: IN_VALUE (3)

    Note that although my original post showed the tests & screenshot for the nrf iOS Connect app, I also tested this using our own iOS app which uses the IOS-nRF-Connect-Device-Manager library (https://github.com/NordicSemiconductor/IOS-nRF-Connect-Device-Manager) - which is probably the same library used by the nrf Connect for iOS app! :) 
    Anyway, I get the same error code when I try using the iOS library as I get in the nrf Connect Mobile apps (for iOS and Android). So the error seems consistent across three different "platforms"!

    Also tried it with numerous different CONFIG options but nothing I do seems to make any difference & I always get the same error - yet updating ONLY the "Application Core" works like a charm (on all 3 "platforms") & has worked for more than 1 year as I mentioned.

    This is really frustrating as you can imagine....

    Hope you can help me resolve this issue as it is holding up our progress to upgrade a number of units already in the field.

    Thanks!

    Gerard

  • Hi Andreas,

    No problem! Glad you haven't given up on me yet! Slight smile

    So looking forward to seeing your lates wisdom & insight early next week.

    Hope you have a great weekend in the meantime..!

    Best Regards

    Gerard

  • Hi again! 

    Edit: Answering your previous batch of question at the top of the chain instead of directly to the post with the questions so it makes chronologically sense

    GerardB said:
    1. OTP Partition on nrf5340.

    "Erase user settings" does not delete the OTP, since the OTP requires a full erase (nrfjprog -e for instance, which erases all user available flash + UICR). If it did delete all flash memory, DFU would not work, since we send this command just before reset into the new DFU images that have been uploaded

    The intended use of Erase App Settings is that if the user flashes a DK or a device with a different application, whatever data was stored before in the flash should be wiped so as to not cause issues with the new application running. It it sent (the Erase App Settings command) after the new images are uploaded and verified but before Reset into the new app! 
     
    PS: The command is used to erase single partition on a flash device. Depending on application it may be storage or dedicated settings partition.

    I believe this should answer this question, but let me know if I have left out anything

    GerardB said:
    2. Serial Recovery not possible - that is why this DFU update is so critical for us.

    Noted, I can see that serial recovery is not an option for you

    GerardB said:
    3. Dynamic vs. Static Partition map.

    I agree with your statement regarding the dynamic partition, it is brilliant in a large portion of use cases, i.e for development, migrating between types of devices at ease and situations such as 'applications that are not flash-restricted, and/or are only performing DFU where modifications has not changed any partitions due to for instance changing configurations, and where you're not migrating in between major SDK versions' (both a very wide and specific situation simultaneously).

    Generally, and not particular to the nRF5340: If you're lucky, then migrating between SDK versions works with dynamic partitioning. If you're unlucky and some configurations have changed in between the major releases leaving you with a different sized partition which skews the entire partition map relative to the old firmware changing for instance the start address of the primary partition In this case you might be left in a situation where MCUBoot still expects the new image to have the same start address as the old image causing issues such as not completing the DFU (i.e reverting back to the original image), to bricking the device.

    As you state, future proofing the application for newer releases of the SDK by using a static partitioning is generally considered a very sound strategy

    GerardB said:
    4. DFU over BLE data transfer rate (for image uploads over BLE).

    I see that some discussion has happened on this questions thanks to input from Sean. Have all your questions in under item 4 in this reply been answered, or should I dig around to see if I find something?

    GerardB said:
    But I have two questions for you if you have a few minutes! :D 

    I assume these questions are directed at Sean (  ), but just to be sure could you clarify if that is the case or if they're directed at me? :) 

    Kind regards;
    Andreas

  • Hi again Andreas,

    Thanks for you last answer. I think I now understand the key issues & simultaneous image updates over BLE seem to work well now with the nrf Connect for Mobile app on iOS.  So you have resolved my original questions/problems! 

    My biggest "open" issue now is actually a related issue regarding the use of the iOSMcuManagerLibrary in my/our SwiftUI based iOS app. The single image update has worked flawlessly (and upload over BLE  is now even faster!) BUT I can't get the simultaneous image updates to work in our app (which is critical going forward). It seems to generate a LOT of iOS/Xcode errors when one tries to use the ".zip" file (versus the .bin file) with this API

    let package = try McuMgrPackage(from: URL(string: "URL for Zip file on Google Cloud")!);

    I know the file URL is correct and I know the file is the same zip file that I used for testing with the nrf Connect for iOS App. 

    It is interesting that multi image update also doesn't work with the "example iOS App" contained in the library itself (I built & tested it!). In fact the documentation for the "example iOS app" (DFU) states that it will only work with nrf51 & nrf52 devices. So maybe the library has problems with nrf5340 and multi-image updates (which includes extracting the images from the zip file)? It is surprising to me that the nrf5340 is not supported by that "example app". 

    But as this thread is getting a little long, I think I need to close it & open a new case for that issue...

    I guess there is no way that you could be assigned to THAT case as well!? :)

    Would be great - as you REALLY are great at understanding the issues & explaining things! THANKS AGAIN - I learnt a LOT in this thread! Thumbsup

    Regards

    Gerard 

  • Hi,

    GerardB said:
    Thanks for you last answer. I think I now understand the key issues & simultaneous image updates over BLE seem to work well now with the nrf Connect for Mobile app on iOS.  So you have resolved my original questions/problems! 

    Glad to hear that!

    GerardB said:

    It is interesting that multi image update also doesn't work with the "example iOS App" contained in the library itself (I built & tested it!). In fact the documentation for the "example iOS app" (DFU) states that it will only work with nrf51 & nrf52 devices. So maybe the library has problems with nrf5340 and multi-image updates (which includes extracting the images from the zip file)? It is surprising to me that the nrf5340 is not supported by that "example app". 

    But as this thread is getting a little long, I think I need to close it & open a new case for that issue...

    If you could create a new case for that issue then we could use that to create a bug report (or feature request depending on what the application developers considers this as), that would be great!

    Regarding if I can be assigned to that case, I can't guarantee that will be the case. The distribution will depend on which team the case will be distributed to, the specifics of the topic and the workload on that teams experts on the given topic, so you might be better of by getting another expert on the topic :) But I will keep my eye out in the queue to see if I can spot the case if and when it comes in

    As for now, you can either leave this thread open if you have any other related questions or flag it as verified/close it if you are content for now! You should be able to reopen the case at a later point in time if any new questions comes up and it will show up in my queue once that happens

    Kind regards,
    Andreas

  • I found the cause of the many iOS errors/warnings.

    In the DFU example, the code at https://github.com/NordicSemiconductor/IOS-nRF-Connect-Device-Manager/blob/master/Example/Example/Util/McuMgrPackage.swift#L113 brutally deletes all files in the iOS caches directory, including the Cache.db created when downloading data using e.g. URLSession.
    Instead, McuMgrPackage should make a new subdirectory inside the caches folder or some other temp space, and unzip into that.

    I will make a PR for that soon.

Reply Children
No Data
Related