BT DFU OTA over SMP service from nRF54L15 Central to nRF54L15 Peripheral

[br_adams_01]

Hello,

So I am working on implementing Bluetooth DFU OTA capabilities to send an image from a 54L15, acting as an SMP Central Client, to another 54L15, acting as an SMP Server. I can load the image into the SMP Client via an mcumgr UART transport and store it into littlefs, so storing the image onto the Central is not my main concern. However, I was looking to see if there were any examples on the Bluetooth transport side (sending the loaded bin file from the SMP Client to the SMP Server), as I am running into a little bit of trouble, mainly regarding 1) How much of the bin file do I need to chunk and send, and does this include the TLV area, and 2) How can I parse the TLV area from the application layer so that I can extract the hash to test the image? Are there any higher-level API’s that can handle the BT transport from a separate stack? That’s what I was hoping to look into; perhaps an existing example or higher-level BT DFU-OTA API’s would be great, as I am currently planning to use the Zephyr DFU Client API’s to try to accomplish this. I am currently working with NCS v2.8.0, but maybe there is something in v2.9.0 I can use?

Thanks!

cc:
Manieldyers 

[Amanda Hsieh]

Hi, 

You can take a look at this Bluetooth: Central SMP Client sample. 

Regards,
Amanda H.

[br_adams_01]

Thanks, Amanda.

I have looked into this example already, and it gives me a good idea of how I want to approach the problem of sending the SMP commands themselves. However, I still would like to know information about questions 1 and 2 above -- ""1)How much of the bin file do I need to chunk and send, and does this include the TLV area, and 2) How can I parse the TLV area from the application layer so that I can extract the hash to test the image?"" 

[Amanda Hsieh]

br_adams_01 said:

1)How much of the bin file do I need to chunk and send, and does this include the TLV area

At least 32 bytes, since first it has to send the whole header (which is 32 bytes), not including the TVL area. Here is my colleague's unofficial sample, but it is not updated to v2.9.0. Still worth taking a look.  https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/client_smp/smp_client_ble

Disclaimer:

This code/configuration is not thoroughly tested or qualified and should be considered provided “as-is”. Only for reference. 

br_adams_01 said:

2) How can I parse the TLV area from the application layer so that I can extract the hash to test the image?

You can use the img_mgmt_find_tlvs() function, see the example https://github.com/nrfconnect/sdk-zephyr/blob/v3.7.99-ncs2/subsys/mgmt/mcumgr/grp/img_mgmt/src/img_mgmt.c#L227 

[br_adams_01]

Amanda,

Making good progress. I can list the images on the target, erase an image if there is an image populated in the secondary slot, and upload 99% (I'll explain below) of the image chunks. The example is helping out very well.

I did change the way that I stored the image on the Central in order to OTA the image to the Target (used mcumgr uart transport to store in secondary image partition instead of littlefs).

I have ran into a problem. When I sent the last packet of the image, I get an error return code "rc" on the central of 1 in the upload response packet (According to the SMP stack, an unknown error). On the target side, I get the following in the log:

"Image upload inspect failed: 31"

The offset that I am getting from the upload response appears to match the offset of what I am reading from flash.

Upon further observation, when this error occurred on the target, the image seemed to be discarded upon listing the images again.

I checked the SHA hash of the image file itself that I am sending in the first upload packet, and it is the same hash that was calculated from the nRF connect app, so I do not think that is the issue. Currently right now, I am calculating this hash in a Python script and inputting that hash into a shell command.

Any suggestions? Is there a way to calculate the hash of the image in the secondary partition on the Central?

Thanks!

[br_adams_01]

Also, in addition to calculating the SHA hash, is there a way that we can get the exact image size before we OTA the file to the target?

Thanks!