DFU for external BLE Sensor

[davidpatton]

Hi,

  I have a current project that is based on the nRf52840.  This project acts both as a peripheral and a central.  I have a need to update the firmware on a remote BLE sensor using DFU, i.e., I need to do exactly what the nRfConnect application does when it updates a peripheral firmware via DFU.  My thought was to use the nRf52840 dongle and develop this code on my PC and then port it to my embedded system.  I also thought the best starting point would be the source code for the nRfConnect application which I would port it but I see from user comments that nordic did not release the source code for this.  Is it possible to get this source code or is there another example that demonstrates what I need to accomplish?

Thanks!

[davidpatton]

Hi,

  I am a bit confused and am hoping that you can help.  I have a Laird BT610 sensor and when I connect to it it does not show a Secure DFU service; however, I can do an over the air update of this sensor using nRfConnect and a proper firmware.bin file for this sensor. The sensor does advertise the SMP Serviice.  Is nRfConnect using this service to perform the firmware update?

Thanks,

Dave

[Vidar Berg]

Hi Dave,

I am sorry for the confusion. I assumed your FW was based on our nRF5 SDK which uses a different DFU protocol.  So my initial reply does not apply to your case. As you may know, the nRF connect SDK is relying on the DFU protocol from MCUmgr for FW updates over BLE.

Here are the MCUmgr libraries we use for our ios and android apps:

https://github.com/NordicSemiconductor/Android-nRF-Connect-Device-Manager

https://github.com/NordicSemiconductor/IOS-nRF-Connect-Device-Manager

Best regards,

Vidar

[Vidar Berg]

Hi Dave,

One of our developers pointed out  to me that the sha256 sent along with the first packet (when offset == 0) is actually only of the data sent in that packet. In other words, this has digest not the same one that you will find in the image trailer:

The nRF5 SDK includes a sha library in \components\libraries\sha256 that you can use.

Vidar

[Vidar Berg]

Hi,

Please check if he has kept the "documentation folder. The is a release_notes.txt file in it which says what SDK version it is.

[davidpatton]

Hi Vidar,

  I don't think the information the developer provided is correct.  Through testing and trial and error I verified that the SHA is actually calculated over the entire image, i.e.,

Image Header   (512 bytes)
Image Data       (501,244 bytes)
Image Trailer     (151 bytes)

Just thought I would share this info with you in case someone else needs it.

Many thanks for your help,

Dave Patton

[Vidar Berg]

Hi Dave,

Thank you for the update. Actually, it seems like this hash digest is only used as an identifier for the upload session, and not for data integrity checks as I had expected. So the way the hash is computed may differ between different DFU clients. We need to document this better..

Here's the function that checks the hash in the first packet:

https://github.com/zephyrproject-rtos/mcumgr/blob/c854c85ec75d624c47058bc4ac0ab9b12e2dd0e7/cmd/img_mgmt/port/zephyr/src/zephyr_img_mgmt.c#L587

Best regards,

Vidar

[davidpatton]

Hi,

  One other IMPORTANT thing to note is that if the SHA is sent with the first Upload packet and the upload fails in the middle (let's say at byte number 253400), when it restarts if will start from where it left off, i.e., when the upload is retried and the first block is sent the Peripheral will respond with the offset where the transfer should resume, i.e., 253400 in this case.  This is not true if the SHA is not sent with the first Upload packet.  This took a lot of work to figure this out so I thought I would share it for others benefit.  NOTE: Sending the SHA is optional.

Thanks,

Dave Patton