dfu with zephyr rtos using mcumgr

[ziv123]

hello Nordic

i am working with nrf52840, zephyr rtos.

i can preform dfu via mcumgr cli (command line interface) or via nrfConnect application on my cell phone.

however, i need to be writing (in rust) a dfu over ble mechanism, like the mcumgr (which to my understanding from looking at the data transfer below, the nrfConnect is using as well)

data transmission on the nrfConnect application:

nRF Connect, 2021-11-09
Canary_EP_-1 (F3:5E:20:33:B0:0D)
V 13:02:22.762 Connecting to F3:5E:20:33:B0:0D...
D 13:02:22.762 gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE)
D 13:02:23.922 [Callback] Connection state changed with status: 0 and new state: CONNECTED (2)
D 13:02:23.924 [Broadcast] Action received: android.bluetooth.device.action.ACL_CONNECTED
I 13:02:23.959 Connected to F3:5E:20:33:B0:0D
V 13:02:24.042 Discovering services...
D 13:02:24.042 gatt.discoverServices()
D 13:02:25.318 [Callback] Services discovered with status: 0
I 13:02:25.318 Services discovered
V 13:02:25.350 Generic Attribute (0x1801)
- Service Changed [I] (0x2A05)
   Client Characteristic Configuration (0x2902)
Generic Access (0x1800)
- Device Name [R W] (0x2A00)
- Appearance [R] (0x2A01)
- Peripheral Preferred Connection Parameters [R] (0x2A04)
Battery Service (0x180F)
- Battery Level [R] (0x2A19)
Unknown Service (b65452a2-66a6-418a-cc40-31d4da2db50b)
- Unknown Characteristic [R W] (4d853009-03b8-f6a6-3643-307a87f67bac)
Current Time Service (0x1805)
- Current Time [N R W] (0x2A2B)
   Client Characteristic Configuration (0x2902)
Unknown Service (52e2788e-5525-81b3-604c-a378379128bf)
- Unknown Characteristic [N R W] (704718fd-ffc2-b79c-5940-bbb0bef9d1b5)
   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)
Unknown Service (00001523-ca77-eca5-6347-d8cb280e2c68)
- Unknown Characteristic [R W] (00001524-ca77-eca5-6347-d8cb280e2c68)
- Unknown Characteristic [N R] (00001525-ca77-eca5-6347-d8cb280e2c68)
   Client Characteristic Configuration (0x2902)
Tx Power (0x1804)
- Tx Power Level [R] (0x2A07)
SMP Service (8d53dc1d-1db7-4cd3-868b-8a527460aa84)
- SMP Characteristic [N WNR] (da2e7828-fbce-4e01-ae9e-261174997c48)
   Client Characteristic Configuration (0x2902)
D 13:02:25.350 gatt.setCharacteristicNotification(00002a05-0000-1000-8000-00805f9b34fb, true)
D 13:02:25.353 gatt.setCharacteristicNotification(00002a2b-0000-1000-8000-00805f9b34fb, true)
D 13:02:25.355 gatt.setCharacteristicNotification(704718fd-ffc2-b79c-5940-bbb0bef9d1b5, true)
D 13:02:25.357 gatt.setCharacteristicNotification(00001525-ca77-eca5-6347-d8cb280e2c68, true)
V 13:02:47.859 [McuMgr] Connecting...
D 13:02:47.914 [McuMgr] gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE)
D 13:02:47.953 [McuMgr] [Callback] Connection state changed with status: 0 and new state: 2 (CONNECTED)
I 13:02:47.968 [McuMgr] Connected to F3:5E:20:33:B0:0D
D 13:02:47.979 [McuMgr] wait(300)
V 13:02:48.308 [McuMgr] Discovering services...
D 13:02:48.322 [McuMgr] gatt.discoverServices()
I 13:02:48.405 [McuMgr] Services discovered
V 13:02:48.416 [McuMgr] Primary service found
V 13:02:48.433 [McuMgr] Requesting new MTU...
D 13:02:48.440 [McuMgr] gatt.requestMtu(515)
I 13:02:48.524 [McuMgr] MTU changed to: 252
D 13:02:48.535 [McuMgr] gatt.setCharacteristicNotification(da2e7828-fbce-4e01-ae9e-261174997c48, true)
V 13:02:48.548 [McuMgr] Enabling notifications for da2e7828-fbce-4e01-ae9e-261174997c48
D 13:02:48.557 [McuMgr] gatt.writeDescriptor(00002902-0000-1000-8000-00805f9b34fb, value=0x01-00)
I 13:02:48.668 [McuMgr] Data written to descr. 00002902-0000-1000-8000-00805f9b34fb, value: (0x) 01-00
I 13:02:48.678 [McuMgr] Notifications enabled
V 13:02:48.706 [McuMgr] Writing characteristic da2e7828-fbce-4e01-ae9e-261174997c48 (WRITE COMMAND)
D 13:02:48.716 [McuMgr] gatt.writeCharacteristic(da2e7828-fbce-4e01-ae9e-261174997c48)
I 13:02:48.728 [McuMgr] Data written to da2e7828-fbce-4e01-ae9e-261174997c48, value: (0x) 00-00-00-02-00-01-00-00-BF-FF
A 13:02:48.739 [McuMgr] "Operation: READ
Flags: 0
Length: 2
Group Id: 1 (IMAGE)
Sequence Num: 0
Command Id: 0 (STATE)
Message: {}" sent
I 13:02:48.822 [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-34-2E-31-64-68-61-73-68-58-20-20-2F-53-64-6E-8A-B9-87-B9-2D-19-54-7C-10-38-87-A8-20-35-11-E8-31-2C-7F-B3-2E-3E-E0-6E-08-21-B7-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-34-2E-31-64-68-61-73-68-58-20-A2-91-E8-D0-E4-88-EC-F0-32-9B-E6-D5-5A-50-6D-F9-EA-63-B2-BE-D7-86-F0-68-E0-2D-9A-88-18-32-DA-25-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-53-74-61-74-75
I 13:02:48.831 [McuMgr] Notification received from da2e7828-fbce-4e01-ae9e-261174997c48, value: (0x) 73-00-FF
A 13:02:48.876 [McuMgr] "{"images":[{"slot":0,"version":"0.4.1","hash":"IC9TZG6KuYe5LRlUfBA4h6ggNRHoMSx/sy4+4G4IIbc=","bootable":true,"pending":false,"confirmed":true,"active":true,"permanent":false},{"slot":1,"version":"0.4.1","hash":"opHo0OSI7PAym+bVWlBt+epjsr7XhvBo4C2aiBgy2iU=","bootable":true,"pending":false,"confirmed":false,"active":false,"permanent":false}],"splitStatus":0}" received
V 13:02:48.963 [McuMgr] Uploading firmware...
V 13:05:24.983 [McuMgr] Writing characteristic da2e7828-fbce-4e01-ae9e-261174997c48 (WRITE COMMAND)
D 13:05:24.996 [McuMgr] gatt.writeCharacteristic(da2e7828-fbce-4e01-ae9e-261174997c48)
I 13:05:25.009 [McuMgr] Data written to da2e7828-fbce-4e01-ae9e-261174997c48, value: (0x) 02-00-00-32-00-01-00-00-BF-67-63-6F-6E-66-69-72-6D-F4-64-68-61-73-68-58-20-8A-B4-65-7D-20-CD-52-CB-8D-66-4E-D9-15-7D-A0-EC-41-06-02-0C-E0-84-F8-62-2F-D9-76-A1-DB-27-31-21-FF
A 13:05:25.033 [McuMgr] "Operation: WRITE
Flags: 0
Length: 50
Group Id: 1 (IMAGE)
Sequence Num: 0
Command Id: 0 (STATE)
Message: {"confirm":false,"hash":"irRlfSDNUsuNZk7ZFX2g7EEGAgzghPhiL9l2odsnMSE="}" sent
I 13:05:25.159 [McuMgr] Notification received from da2e7828-fbce-4e01-ae9e-261174997c48, value: (0x) 03-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-34-2E-31-64-68-61-73-68-58-20-20-2F-53-64-6E-8A-B9-87-B9-2D-19-54-7C-10-38-87-A8-20-35-11-E8-31-2C-7F-B3-2E-3E-E0-6E-08-21-B7-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-34-2E-31-64-68-61-73-68-58-20-8A-B4-65-7D-20-CD-52-CB-8D-66-4E-D9-15-7D-A0-EC-41-06-02-0C-E0-84-F8-62-2F-D9-76-A1-DB-27-31-21-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-F4-FF-FF-6B-73-70-6C-69-74-53-74-61-74-75
I 13:05:25.171 [McuMgr] Notification received from da2e7828-fbce-4e01-ae9e-261174997c48, value: (0x) 73-00-FF
A 13:05:25.204 [McuMgr] "{"images":[{"slot":0,"version":"0.4.1","hash":"IC9TZG6KuYe5LRlUfBA4h6ggNRHoMSx/sy4+4G4IIbc=","bootable":true,"pending":false,"confirmed":true,"active":true,"permanent":false},{"slot":1,"version":"0.4.1","hash":"irRlfSDNUsuNZk7ZFX2g7EEGAgzghPhiL9l2odsnMSE=","bootable":true,"pending":true,"confirmed":false,"active":false,"permanent":false}],"splitStatus":0}" received
V 13:05:25.220 [McuMgr] Writing characteristic da2e7828-fbce-4e01-ae9e-261174997c48 (WRITE COMMAND)
D 13:05:25.225 [McuMgr] gatt.writeCharacteristic(da2e7828-fbce-4e01-ae9e-261174997c48)
I 13:05:25.233 [McuMgr] Data written to da2e7828-fbce-4e01-ae9e-261174997c48, value: (0x) 02-00-00-02-00-00-00-05-BF-FF
A 13:05:25.241 [McuMgr] "Operation: WRITE
Flags: 0
Length: 2
Group Id: 0 (OS)
Sequence Num: 0
Command Id: 5 (RESET)
Message: {}" sent
I 13:05:25.299 [McuMgr] Notification received from da2e7828-fbce-4e01-ae9e-261174997c48, value: (0x) 03-00-00-02-00-00-00-05-BF-FF
A 13:05:25.329 [McuMgr] "{}" received
D 13:05:26.020 [McuMgr] [Callback] Connection state changed with status: 8 and new state: 0 (DISCONNECTED)
D 13:05:26.023 [Callback] Connection state changed with status: 8 and new state: DISCONNECTED (0)
E 13:05:26.023 Error 8 (0x8): GATT CONN TIMEOUT
I 13:05:26.023 Disconnected
W 13:05:26.105 [McuMgr] Error: (0x8): GATT CONN TIMEOUT
D 13:05:26.129 [Broadcast] Action received: android.bluetooth.device.action.ACL_DISCONNECTED
I 13:05:26.144 [McuMgr] Disconnected
D 13:05:26.159 [McuMgr] gatt.close()
V 13:05:26.192 [McuMgr] Connecting...
D 13:05:26.202 [McuMgr] gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE)
D 13:05:53.785 [McuMgr] [Callback] Connection state changed with status: 0 and new state: 2 (CONNECTED)
D 13:05:53.786 [Broadcast] Action received: android.bluetooth.device.action.ACL_CONNECTED
I 13:05:53.809 [McuMgr] Connected to F3:5E:20:33:B0:0D
D 13:05:53.822 [McuMgr] wait(300)
V 13:05:54.154 [McuMgr] Discovering services...
D 13:05:54.162 [McuMgr] gatt.discoverServices()
I 13:05:55.177 [McuMgr] Services discovered
V 13:05:55.205 [McuMgr] Primary service found
V 13:05:55.230 [McuMgr] Requesting new MTU...
D 13:05:55.238 [McuMgr] gatt.requestMtu(515)
I 13:05:55.329 [McuMgr] MTU changed to: 252
D 13:05:55.339 [McuMgr] gatt.setCharacteristicNotification(da2e7828-fbce-4e01-ae9e-261174997c48, true)
V 13:05:55.351 [McuMgr] Enabling notifications for da2e7828-fbce-4e01-ae9e-261174997c48
D 13:05:55.359 [McuMgr] gatt.writeDescriptor(00002902-0000-1000-8000-00805f9b34fb, value=0x01-00)
I 13:05:55.426 [McuMgr] Data written to descr. 00002902-0000-1000-8000-00805f9b34fb, value: (0x) 01-00
I 13:05:55.433 [McuMgr] Notifications enabled
V 13:05:55.470 [McuMgr] Writing characteristic da2e7828-fbce-4e01-ae9e-261174997c48 (WRITE COMMAND)
D 13:05:55.476 [McuMgr] gatt.writeCharacteristic(da2e7828-fbce-4e01-ae9e-261174997c48)
I 13:05:55.481 [McuMgr] Data written to da2e7828-fbce-4e01-ae9e-261174997c48, value: (0x) 02-00-00-0B-00-01-00-00-BF-67-63-6F-6E-66-69-72-6D-F5-FF
A 13:05:55.487 [McuMgr] "Operation: WRITE
Flags: 0
Length: 11
Group Id: 1 (IMAGE)
Sequence Num: 0
Command Id: 0 (STATE)
Message: {"confirm":true}" sent
I 13:05:55.579 [McuMgr] Notification received from da2e7828-fbce-4e01-ae9e-261174997c48, value: (0x) 03-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-34-2E-31-64-68-61-73-68-58-20-8A-B4-65-7D-20-CD-52-CB-8D-66-4E-D9-15-7D-A0-EC-41-06-02-0C-E0-84-F8-62-2F-D9-76-A1-DB-27-31-21-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-34-2E-31-64-68-61-73-68-58-20-20-2F-53-64-6E-8A-B9-87-B9-2D-19-54-7C-10-38-87-A8-20-35-11-E8-31-2C-7F-B3-2E-3E-E0-6E-08-21-B7-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-53-74-61-74-75
I 13:05:55.586 [McuMgr] Notification received from da2e7828-fbce-4e01-ae9e-261174997c48, value: (0x) 73-00-FF
A 13:05:55.631 [McuMgr] "{"images":[{"slot":0,"version":"0.4.1","hash":"irRlfSDNUsuNZk7ZFX2g7EEGAgzghPhiL9l2odsnMSE=","bootable":true,"pending":false,"confirmed":true,"active":true,"permanent":false},{"slot":1,"version":"0.4.1","hash":"IC9TZG6KuYe5LRlUfBA4h6ggNRHoMSx/sy4+4G4IIbc=","bootable":true,"pending":false,"confirmed":false,"active":false,"permanent":false}],"splitStatus":0}" received
V 13:05:55.659 [McuMgr] Disconnecting...
D 13:05:55.675 [McuMgr] gatt.disconnect()
D 13:05:55.692 [McuMgr] [Callback] Connection state changed with status: 0 and new state: 0 (DISCONNECTED)
I 13:05:55.716 [McuMgr] Disconnected
D 13:05:55.737 [McuMgr] gatt.close()
D 13:05:55.783 gatt.close()
D 13:05:55.786 wait(200)
V 13:05:55.991 Connecting to F3:5E:20:33:B0:0D...
D 13:05:55.992 gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE)
D 13:05:56.106 [Callback] Connection state changed with status: 0 and new state: CONNECTED (2)
I 13:05:56.106 Connected to F3:5E:20:33:B0:0D
V 13:05:56.141 Discovering services...
D 13:05:56.141 gatt.discoverServices()
D 13:05:57.277 [Callback] Services discovered with status: 0
I 13:05:57.277 Services discovered
V 13:05:57.308 Generic Attribute (0x1801)
- Service Changed [I] (0x2A05)
   Client Characteristic Configuration (0x2902)
Generic Access (0x1800)
- Device Name [R W] (0x2A00)
- Appearance [R] (0x2A01)
- Peripheral Preferred Connection Parameters [R] (0x2A04)
Battery Service (0x180F)
- Battery Level [R] (0x2A19)
Unknown Service (b65452a2-66a6-418a-cc40-31d4da2db50b)
- Unknown Characteristic [R W] (4d853009-03b8-f6a6-3643-307a87f67bac)
Current Time Service (0x1805)
- Current Time [N R W] (0x2A2B)
   Client Characteristic Configuration (0x2902)
Unknown Service (52e2788e-5525-81b3-604c-a378379128bf)
- Unknown Characteristic [N R W] (704718fd-ffc2-b79c-5940-bbb0bef9d1b5)
   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)
Unknown Service (00001523-ca77-eca5-6347-d8cb280e2c68)
- Unknown Characteristic [R W] (00001524-ca77-eca5-6347-d8cb280e2c68)
- Unknown Characteristic [N R] (00001525-ca77-eca5-6347-d8cb280e2c68)
   Client Characteristic Configuration (0x2902)
Tx Power (0x1804)
- Tx Power Level [R] (0x2A07)
SMP Service (8d53dc1d-1db7-4cd3-868b-8a527460aa84)
- SMP Characteristic [N WNR] (da2e7828-fbce-4e01-ae9e-261174997c48)
   Client Characteristic Configuration (0x2902)
D 13:05:57.309 gatt.setCharacteristicNotification(00002a05-0000-1000-8000-00805f9b34fb, true)
D 13:05:57.311 gatt.setCharacteristicNotification(00002a2b-0000-1000-8000-00805f9b34fb, true)
D 13:05:57.312 gatt.setCharacteristicNotification(704718fd-ffc2-b79c-5940-bbb0bef9d1b5, true)
D 13:05:57.314 gatt.setCharacteristicNotification(00001525-ca77-eca5-6347-d8cb280e2c68, true)
D 13:06:21.226 [Callback] Connection state changed with status: 8 and new state: DISCONNECTED (0)
E 13:06:21.226 Error 8 (0x8): GATT CONN TIMEOUT
I 13:06:21.227 Disconnected
D 13:06:21.439 [Broadcast] Action received: android.bluetooth.device.action.ACL_DISCONNECTED

i tried finding the same commands of the mcumgr cli (image list -> image upload -> image list -> image test -> reset -> confirm, as explained here: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/guides/device_mgmt/mcumgr.html#mcumgr-cli ) in the nrfConnect and could not really find all the correlations, 

also when printing the commands while running the mcumgr cli, i read some data which i don't understand it's origen or meaning, for example, for the image confirm command, i see the device receives this bytes:

/// edit this function in the smp_ct.c file:
static ssize_t smp_bt_chr_write(struct bt_conn *conn,
				const struct bt_gatt_attr *attr,
				const void *buf, uint16_t len, uint16_t offset,
				uint8_t flags)
{
	struct smp_bt_user_data *ud;
	struct net_buf *nb;

	LOG_INF("in smp_bt write UUID - %d\n",attr->uuid->type);
	LOG_INF("in smp_bt write len - %d\n",len);
	LOG_INF("in smp_bt  offset - %d\n",offset);
	LOG_INF("in smp_bt buff ");
	if( 100 > len)
	{
		for( uint16_t i = 0; i < len; i++)
		{
			LOG_INF("%x, ", ((uint8_t*)buf)[i]);
		}
	}
...
///////// resulting with this prints:

I: in smp_bt write UUID - 2
00> 
00> I: in smp_bt write len - 24
00> 
00> I: in smp_bt  offset - 0
00> 
00> I: in smp_bt buff 
00> I: 2, 
00> I: 0, 
00> I: 0, 
00> I: 10, 
00> I: 0, 
00> I: 1, 
00> I: 42, 
00> I: 0, 
00> I: a2, 
00> I: 67, 
00> I: 63, 
00> I: 6f, 
00> I: 6e, 
00> I: 66, 
00> I: 69, 
00> I: 72, 
00> I: 6d, 
00> I: f5, 
00> I: 64, 
00> I: 68, 
00> I: 61, 
00> I: 73, 
00> I: 68, 
00> I: f6, 
00> I: Swap type: revert
00> I: Swap type: revert
00> I: Swap type: none
00> I: Swap type: none

which correlats to the prints i take in running the mcumgr cli:

sudo ./mcumgr --conntype ble --connstring 'peer_id=e8:7d:90:dc:db:65' image confirm  
in npm, BodyByets, data = [] 
in npm, BodyByets, data = [162 103 99 111 110 102 105 114 109 245 100 104 97 115 104 246] 
in sens util TxRxMgmt sesn: &{cfg:{MgmtProto:0 AdvFilter:0x71dac0 PreferredMtu:512 ConnTimeout:10000000000 ConnTries:3 WriteRsp:false TxFilter:<nil> RxFilter:<nil>} cln:0xc00028a0a0 txvr:0xc0000d5b80 mtx:{state:0 sema:0} attMtu:252 nmpReqChr:0xc0003200b0 nmpRspChr:0xc0003200b0 resReqChr:<nil> resRspChr:<nil>}
in sens util TxRxMgmt nmpMsg: &{Hdr:{Op:2 Flags:0 Len:16 Group:1 Seq:66 Id:0} Body:0xc000180210}
in txReq rsp: &{NmpBase:{hdr:{Op:3 Flags:0 Len:244 Group:1 Seq:66 Id:0}} Rc:0 Images:[{NmpBase:{hdr:{Op:0 Flags:0 Len:0 Group:0 Seq:0 Id:0}} Image:0 Slot:0 Version:0.5.0 Hash:[71 18 86 1 155 68 31 143 2 103 144 173 169 105 192 24 44 58 29 41 99 245 38 59 25 98 241 144 250 41 187 131] Bootable:true Pending:false Confirmed:true Active:true Permanent:false} {NmpBase:{hdr:{Op:0 Flags:0 Len:0 Group:0 Seq:0 Id:0}} Image:0 Slot:1 Version:0.5.0 Hash:[244 2 53 28 132 194 234 206 9 167 41 163 57 194 86 134 182 89 167 49 224 148 50 208 224 104 162 159 41 137 176 166] Bootable:true Pending:false Confirmed:false Active:false Permanent:false}] SplitStatus:N/A}
Images:
 image=0 slot=0
    version: 0.5.0
    bootable: true
    flags: active confirmed
    hash: 471256019b441f8f026790ada969c0182c3a1d2963f5263b1962f190fa29bb83
 image=0 slot=1
    version: 0.5.0
    bootable: true
    flags: 
    hash: f402351c84c2eace09a729a339c25686b659a731e09432d0e068a29f2989b0a6
Split status: N/A (0)

the 'body' bytes in the above example are not clear, is it somesort of calculation or key or what ? can you help with understanding the mcumgr protocol behind, as the nrfConnect is also using it (i have already went through related smp_bt info:  https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/README.html there is no such info there, also not in the mcumgr ripo github.com/.../go.mod)

also not clear to me if the commands sent and replied as a json or byte[] 

hope to read from you soon 

best regards

Ziv

[Einar Thorsrud]

Hi Ziv,

Unfortunately, the mcumgr protocol is not very well documented (in fact, the documentation states that "The protocol isn't fully documented"). While this is used by the nRF Connect SDK and Zephyr it is not developed by Nordic and I do not hav any more information about it than what is available. I do not have any better suggestions than to refer to the implementation of the mcumgr command line tool, which is in newtmgr (or other implementations like iOS-/Android- nRF-Connect-Device-Manager).

If you refer to image.go you can see that the data you see form image confirm is a hash.

Einar

[ziv123]

hi Einar 

does the nrfConnect written in js ?  is there no third side for support on that matter of mcumgr ?

Einar Thorsrud said:

If you refer to image.go you can see that the data you see form image confirm is a hash.

the data i am talking about in the massege is not the hash, 

the hash is "hash: 471256019b441f8f026790ada969c0182c3a1d2963f5263b1962f190fa29bb83"

the data i am asking about is the data in the command sent to the device, in at in the body  " in npm, BodyByets, data = [162 103 99 111 110 102 105 114 109 245 100 104 97 115 104 246]" 

printed from  'npm.go' , the struct sent looks like this:

type NmpHdr struct {
	Op    uint8 /* 3 bits of opcode */
	Flags uint8
	Len   uint16
	Group uint16
	Seq   uint8
	Id    uint8
}

type NmpMsg struct {
	Hdr  NmpHdr
	Body interface{}
}

image confirm is just an example, in image upload it seems that only data is transfered from the first byte without any header or instruction type which is strange to me but still, how is the '.bin' file send ?

again any help will be appreciated

best regards

Ziv

[Einar Thorsrud]

Hi Ziv,

ziv123 said:

does the nrfConnect written in js ?

nRF Connect for Desktop is written in js.

ziv123 said:

is there no third side for support on that matter of mcumgr ?

Not that I am aware of.

ziv123 said:

again any help will be appreciated

I discussed with our developer responsible for SMP DFU supper in our mobile apps, and as there is no proper documentation for the protocol he made some for his reference while developing. That describes the basics of the protocol in some more details, which hopefully can be relevant: MCUmgr_Bluetooth_protocol.pdf. Note that this is not official documentation.

[ziv123]

hi Einar

it's been a while, the document did help

still i am trying to understand how to work with the CBOR, should i build structs for each notify etc. 

i searched the ncs modules to see how the device uses the CBOR to decode the data received from the nrfConnect and how it encodes the notification sent back to the nrfconnect. but i did not find the place where the byte array is converted to some struct and vice versa 

maybe if i understand that, i will also understand how the device know if it got all the data and how many packets are still left etc.

any help and directions will be great

hope to read from you soon 

best regards

Ziv

[Einar Thorsrud]

Hi Ziv,

You can see our fork in sdk-mcumgr. However this project is not written by Nordic and I cannot provide much insight into it, unfortunately. As you have been working with this I suspect you may be able to read something sensible out of the implementation. Also, as you are making the other end, it may be more relevant to look at some of the other implementations, like for instance the nRF Connect Device Manager implementation.

[ziv123]

hi Einar

regarding the document, first, a small correction:

the payload received following the image state read request,  does not contain "image" element in the "Images" map)

second, regarding the image upload command.. it is not clear if the components "data", len, off, image and sha are part of every packet or is it just data in the beginning of payload, also since there is no component "image" what should replace the "image" in the payload

hope the you or the creator of the document can help

hope to read from you soon

best regards

Ziv

[Aleksander Nowakowski]

Hello,

Please, let me answer your questions.

The "image" parameter was added in nRF Connect SDK in version 1.7. It allows multi-core update, e.g. for nRF5340 devices. Older versions didn't support this parameter, and only one core could be updated in a single dfu operation. For other nRF5 devices it doesn't matter. For nRF53 device the app core should be updated in the same operation as net core so that both cores have compatible fw.

When you initiate dfu procedure, the first packet sent needs to have "off" set to 0, "len" set to image length, "sha" set to.. actually to anything (it's session id and to allow resume on the same connection we set it to 3 bytes of the image hash, so when resuming, the string will be the same, but in can by any string), and "data" set to some number of image bytes. For multi-core updates the first packet should also contain "image" parameter, which is by default set to 0 for compatibility. The following data packets must only contain "data" and "off" (offset).

We have Android (in Java) and iOS (in Swift) implementations.

Also, the documentation for SMP protocol is under construction here: https://github.com/zephyrproject-rtos/zephyr/pull/40894

FYI: The current nRF Connect for Android (4.24.3) does not yet support mutli-core update using Mcu Manager.

[ziv123]

hi Aleksander

first, thanks a lot for the document and support

i have some more questions:

1. what is the propose of the first command "validate", since after uploading takes place i have to re read the device to get the hash of the new image ( also, will it always be in slot 1, or do i have to check and compare with previous read hash? ) ? 

2. when uploading in the document i saw there is a notification return with "rc" and "off" but when i looked in the messages transfer i could not find this return notifications ? so is the sending of data dependent on those notification return or does it stop when finishing the data transmission, another thing which was strange is that the packets size looked not constant, sometimes it was 219 bytes, sometimes 173 bytes etc. though on the device i see that every message is off course 248 bytes, any ideas on that ?

3. my transmitter is BLE4.0 so my max MTU is 23/ 27, is that an issue that will cause problems ?

4. can i preppier one packet with the data, len, image and all header, and let the ble manage the division to smaller packets, or do i need to divide my data to the size of my MTU ?

5. if i am not receiving notifications after each transmit then how can i know when to send the next command ? 

hope to red from you soon

best regards

Ziv

[Aleksander Nowakowski]

1. The "validate" checks exactly what is to be done. E.g. the same image (with matching hash) could have been sent on a previous connection, so resume may be possible. Or, it received "off" is equal to "len", the client can just send "confirm" or "test" command without the need of sending the image again. Have a look at Android implementation: https://github.com/NordicSemiconductor/Android-nRF-Connect-Device-Manager/blob/3a1f9a5c35920530854f66e0009b2c5be5dd5b41/mcumgr-core/src/main/java/io/runtime/mcumgr/dfu/task/Validate.java#L62 for more details.

2. "rc" and "off" always come in the response notification. Have a look at https://github.com/nrfconnect/sdk-mcumgr/blob/d9adfe78efd71608b77ac88a5b088723a9fbe6ed/cmd/img_mgmt/src/img_mgmt.c#L333. On mobiles we send one packet and wait for the notification before sending another, but in theory it could be possible to send multiple, each with different SEQ number, and receive notifications later with matching SEQ. This seems not to work yet, at least I couldn't make it work.

Regarding number of bytes sent, seeing logs would be more helpful.

3. Higher MTU are supported since Bluetooth 4.0. DLE (Data Length Extension) is not, but MTU are. Long MTU are required for mcumgr to work, as e.g. the first packet of an upload needs to have at least.. 30 (?) bytes. DLE is not required, without it the upload will just be slower.

4. No, currently each packet sent needs to contain header (8 bytes) and complete CBOR content. Unfortunately. This issue was raised here: https://github.com/apache/mynewt-mcumgr/issues/6

5. You should receive a notification. Did you enable CCCD? In SMP protocol any message you sent shall be confirmed.

[ziv123]

hi Aleksander

Aleksander Nowakowski said:

1. The "validate" checks exactly what is to be done. E.g. the same image (with matching hash) could have been sent on a previous connection,

how do i know the "hash" before receiving it from the device ?

is it calculated from the bun image ? if so, then what is the calculating algorithm  

hope to read from you soon

best regards 

Ziv

[Aleksander Nowakowski]

As I wrote few comments above, the "sha" param can contain anything. It's only session identifier. In the Android library we get it from taking 3 first bytes of hash, calculated from the whole bin file. Check ImageManager class. The proper hash is included in bin for header.

[ziv123]

hi Aleksander

i found a hash implementation in rust which matchs this site test : 

https://emn178.github.io/online-tools/sha256_checksum.html

also looked at the sha256.c file in the ncs/modules/crypto/mbedtls/library/

however, both of them do't give the same hash as i see in the smp dfu what is the protocol or what am i doing wrong ?

hope to read from you soon

best regards

Ziv