DFU on NRF52DK using bluetooth

[vinsin]

I am trying to perform the DFU on the nRF52 DK board from my esp32 board via Bluetooth with the following stack: Simple Management Protocol (SMP) + Bluetooth Low Energy (BLE).

I am using the commands format shown here: developer.nordicsemi.com/.../smp_protocol.html

and commands from image management group shown here: developer.nordicsemi.com/.../smp_group_1.html

I first try to get the state of images and I get the following notification back

On checking for the data in CBOR i get proper values

1, 0, 0, false, 0, 1, 0, 0, {"images": [{"slot": 0, "version": "0.0.0", "hash": h'3B8B8664F91875B456BCC769242680B0657BD48A599A41B7F94CD83D89F4F32D', "bootable": true, "pending": false, "confirmed": true, "active": true, "permanent": false}, {"slot": 1, "version": "0.0.0", "hash": h'82AD183C3DC099B9D4A4E94CBE7EF58E6F7671415C4B96F17000BCDE096A322B', "bootable": true, "pending": false, "confirmed": false, "active": false, "permanent": false}], "splitStatus": 0}

where the initial 8 bits are response(though not mentioned on the above-mentioned webpage with command details) and then further expected response about the expected 2 images on the board.

Next, I try to upload the image on the board in .bin format using the command shown on the webpage

I am sending the following CBOR data(just few bytes for example, shown in red). The actual command +data and response is shown in blue. As evident from the response I get an error with error code 0x3. There is no RSN sent to get details. Now, I thought probably the data is not in the proper format or there is some discrepancy in the way CBOR data has been depicted to be sent on the webpage. So, I tried sending in a format where there is CBOR data within single brackets { ..} instead of two brackets(which(two brackets) I find absurd as any CBOR decoder is not able to handle it). If I send it within single brackets I again get back error. I tried only the compulsory field of offset and data in the first packet and also the proper format for first packet with all fields for offset 0. Still I keep getting response with error code 0x3. I tried multiple combinations but nothing works.

Now, I tried to send the command to set the state of image to find out the format expected for the commands as its CBOR data is in a similar format with two brackets.

I tried sending in the format as shown on the webpage with only the compulsory field of confirm, just to see if I get a response. No matter what combination(single bracket, two bracket) I try it gives an error when I just send the confirmation field value in CBOR data.

But then when I try to send the Set Image state command with CBOR data containing both fields in CBOR data: conform true and hash value(for the image in slot 1 ), I do not get any response from the nrf board.  But when I try to get the image state again to see what happened, I see the state of the image in slot 1 has changed to "bootable": true, "pending": true. That means that data is supposed to be sent in single brackets and not inside two brackets. 

Command to set image state in red and response for image state in blue.

3, 0, 0, false, 0, 1, 0, 0, {"images": [{"slot": 0, "version": "0.0.0", "hash": h'82AD183C3DC099B9D4A4E94CBE7EF58E6F7671415C4B96F17000BCDE096A322B', "bootable": true, "pending": false, "confirmed": true, "active": true, "permanent": false}, {"slot": 1, "version": "0.0.0", "hash": h'ECA54C38C1CCB868DB8367C562E25DB806230044E137E35467C818589A421E87', "bootable": true, "pending": true, "confirmed": false, "active": false, "permanent": true}], "splitStatus": 0}

After a reboot I see the image in slot 1 has moved to slot 0 and is the active image and image in slot 0 has moved to slot 1 as expected.

1, 0, 0, false, 0, 1, 0, 0, {"images": [{"slot": 0, "version": "0.0.0", "hash": h'ECA54C38C1CCB868DB8367C562E25DB806230044E137E35467C818589A421E87', "bootable": true, "pending": false, "confirmed": true, "active": true, "permanent": false}, {"slot": 1, "version": "0.0.0", "hash": h'82AD183C3DC099B9D4A4E94CBE7EF58E6F7671415C4B96F17000BCDE096A322B', "bootable": true, "pending": false, "confirmed": false, "active": false, "permanent": false}], "splitStatus": 0}

Now, I went back and tried to send an image upload request with CBOR data within single brackets, but again get a response in notification with an error 0x3.  

So, now I want to know

1) how exactly am I supposed to send the Image Upload Request and its data for uploading an image on the NRF52 for a DFU.

2) What format is the update image is supposed to be in .bin, .hex, .zip ?

3) What order of commands do I have to follow to perform a DFU from the image management group ? Do i need to provide a special command to enter bootloader mode or anything special needs to be done before sending image upload request?

4) Can you clarify the exact format for the CBOR data in the commands for image management group?

Thanks

[vinsin]

I tried again sending continous packets of 100 bytes for the image and for the first packet(with all optional and compulsory fields for image upload command)   i still get error 0x3. But for next set of packets like i show below for offset 100 i get response saying rc is 0 i.e. no error and i get off field also with value 0 as shown below.

Now, this is like in between of a positive and negative response as it has rc as well as off in response. Can you explain what is happening here?

[Vidar Berg]

Hello,

I don't know the low-level details of the protocol, so I need to spend some time on this before answering your questions. In the meantime, please have a look at this forum thread:  DFU for external BLE Sensor (note: the SMP protocol documentation did not exist at the time this was posted). 

Best regards,

Vidar

[vinsin]

Hello Vidar, We had to test some features based on this protocol so needed to solve it soon.  But I understand. I will wait for your reply. Meanwhile, I will experiment from my side.

Thanks

[Vidar Berg]

Hello,

I got this feedback from one of the developers: 

"I think that there is mistake in documentation where additional map is placed around image group command requests. I have noticed that customers requests begin with "bf bf "which is cbor for map with terminator in map. Request processor expects already opened map it can parse, so it tries to read key, and key reading function returns error because it finds another map."

2) What format is the update image is supposed to be in .bin, .hex, .zip ?

You should use the signed app_update.bin binary generated by the build (https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/app_dev/multi_image/index.html#what-image-files-are).

What order of commands do I have to follow to perform a DFU from the image management group ? Do i need to provide a special command to enter bootloader mode or anything special needs to be done before sending image upload request?

You can send the reset command after the upload is complete to boot into the bootloader and get the new update activated.

[vinsin]

Hello Vidar,

Thank you for the details on CBOR map and command order. The most important thing for me right now is to know the format of the CBOR map as json or bytes of data for the Image upload Request. I know what the header is but the real data with a CBOR map is a mystery as I get 0x3 error for the first packet and sometimes corrupted CBOR reply for them. It surely doesn't work as it is defined to work on the wepage https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/services/device_mgmt/smp_groups/smp_group_1.html . Neither it works for me when I try the format that Dave had made to work. here  DFU for external BLE Sensor So what I basically need now is the real format for

1) First packet of the IMage Upload Request.

2) Further packets. Packet number 1 onwards for IMage upload request.

3) Also, I have a doubt. If my MTU for an application is such that excluding other parts of the packet my data can only be 100 bytes, then I can only send maximum 255 packets due to 8 bits assigned to the sequence number field. Thus I get limited to 25500 bytes of image data. Even if I use the MTU size of around 512 bytes (which is quite standard as per my knowledge, correct me if I'm wrong) I can do just 5 times of that? Isn't it a bit less? Correct me if I misread something.