dfu with zephyr rtos using mcumgr

RE: dfu with zephyr rtos using mcumgr

ziv123 — Sun, 26 Dec 2021 07:26:32 GMT

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

RE: dfu with zephyr rtos using mcumgr

Aleksander Nowakowski — Sat, 18 Dec 2021 22:04:05 GMT

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.

RE: dfu with zephyr rtos using mcumgr

ziv123 — Sat, 18 Dec 2021 19:29:32 GMT

hi Aleksander

[quote userid="3284" url="~/f/nordic-q-a/81729/dfu-with-zephyr-rtos-using-mcumgr/343413#343413"]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,[/quote]

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

RE: dfu with zephyr rtos using mcumgr

Aleksander Nowakowski — Tue, 14 Dec 2021 13:17:21 GMT

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.

RE: dfu with zephyr rtos using mcumgr

ziv123 — Tue, 14 Dec 2021 10:16:03 GMT

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

RE: dfu with zephyr rtos using mcumgr

Aleksander Nowakowski — Mon, 13 Dec 2021 10:19:20 GMT

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.

RE: dfu with zephyr rtos using mcumgr

ziv123 — Sun, 12 Dec 2021 16:22:14 GMT

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

RE: dfu with zephyr rtos using mcumgr

Einar Thorsrud — Mon, 06 Dec 2021 14:52:57 GMT

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.

RE: dfu with zephyr rtos using mcumgr

ziv123 — Mon, 06 Dec 2021 07:59:17 GMT

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

RE: dfu with zephyr rtos using mcumgr

Einar Thorsrud — Tue, 16 Nov 2021 09:46:02 GMT

Hi Ziv,

[quote user="ziv123"]does the nrfConnect written in js ?[/quote]

nRF Connect for Desktop is written in js.

[quote user="ziv123"] is there no third side for support on that matter of mcumgr ?[/quote]

Not that I am aware of.

[quote user="ziv123"]again any help will be appreciated[/quote]

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: devzone.nordicsemi.com/.../MCUmgr_5F00_Bluetooth_5F00_protocol.pdf. Note that this is not official documentation.

RE: dfu with zephyr rtos using mcumgr

ziv123 — Tue, 16 Nov 2021 07:47:56 GMT

hi Einar

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

[quote userid="7377" url="~/f/nordic-q-a/81729/dfu-with-zephyr-rtos-using-mcumgr/339047#339047"]If you refer to image.go you can see that the data you see form image confirm is a hash.[/quote]

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

RE: dfu with zephyr rtos using mcumgr

Einar Thorsrud — Mon, 15 Nov 2021 14:15:24 GMT

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