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

[Vidar Berg]

Hello,

I captured a HCI trace from the DFU target (nRF52840 running SMP server) when being updated by the nRF device manager app on iOS.

Here's the first image upload request received by the dfu target:

The following upload commands can be found in attached trace file (can be opened in Wireshark).

smp_dfu.pcapng

I will ask internally about the sequence number and get back to you. I assume the image size can't be limited by the bit width of this field.

Best regards,

Vidar

[vinsin]

Hello Vidar,

I would like to thank you so much for your help. 

                   Just saw your message. I was trying to do a similar thing in the meanwhile and used the device manager app on my Android and nRF52832. I got the log for the DFU and studied it and tried to replicate it on my setup. I could finally do a DFU from my esp32 on the nRF52 board. I found some issues with what is written on the webpage for the DFU commands. I will send a detailed reply later so that those things can be corrected. Meanwhile, I still cannot understand one piece of information. For the image test/confirmation, I have to send a Hash value for the image as shown below. I calculated the Hash256 for my file and it is coming out to be some other value than what is shown as Hash value for the image when I read it back from the nRF52 board as part of getting image state. Since I knew this hash value before hand I could use it for image confirmation purpose but what if I don't know it while uloading an image for the first time? So, I need to know what is this hash value and how it is calculated. Just to be clear I am talking about the hash value that is returned when you ask for get image state from nRF52 board and details of both the images in two slots are returned.

The image I am uploading is 1667.app_update.bin

The Hash256 for the image is ::  e04689284bcb4979b6340ba45965716b64c051139a3827c08bfa5bd270cb7870

While if I try to get image state the hash it gives for the image is :: 82AD183C3DC099B9D4A4E94CBE7EF58E6F7671415C4B96F17000BCDE096A322B

This is what I get as response on trying to get image state 

3, 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": true, "confirmed": false, "active": false, "permanent": false}], "splitStatus": 0}

So what is this hash value for my image?

[Vidar Berg]

Hello,

I'm happy to hear that you have made good progress on this. With regards to the image hash, it is stored in the image trailer of the app_update_binary and is computed over the image header and body (see IMAGE_TLV_KEYHASH).

The IMAGE_TLV_KEYHASH value in the app_update.bin you uploaded:

app_update.txt

I assume you are able to confirm the image if you use the hash you received in response to your image state request?

[vinsin]

Hello Vidar,

                    Thank you for the update. Yes, I was able to confirm the image using the hash I received in response to your image state request. I read the link you pointed to but I still cannot understand if there is a fixed offset (either from the end or beginning) from where I can read this hash? If not, then how can I move to the offset where I have to read the hash value? I mean I cannot understand reading the text how the complete image is structured and if the image header starts from the beginning or not( It doesn't look so). Can you explain to me how I can find out the hash value from a bin file?

Regards,

Vineet

[Vidar Berg]

Hello Vineet, 

The hash is included in the image trailer located at the end of image slot. To find the exact location for the hash digest, you can parse the TLVs following the magic word (0x6907) as shown in the image in my previous reply.

There was recently introduced a new command in imgtool called 'dumpinfo' which can help you extract the image header and trailer in a more human readable format, but it has not been released yet. If you want to try it out, you can checkout the main branch of https://github.com/nrfconnect/sdk-mcuboot and do a pip install from the folder here:  https://github.com/nrfconnect/sdk-mcuboot/tree/main/scripts 

e.g.,

/mcuboot/scripts$ python3 -m pip install .

$ imgtool dumpinfo app_update.bin 
Printing content of signed image: app_update.bin 

#### Image header (offset: 0x0) ############################
magic:              0x96f3b83d
load_addr:          0x0
hdr_size:           0x200
protected_tlv_size: 0x0
img_size:           0x36cf0
flags:              0x0
version:            0.0.0+0
############################################################
#### Payload (offset: 0x200) ###############################
|                                                          |
|              FW image (size: 0x36cf0 Bytes)              |
|                                                          |
############################################################
#### TLV area (offset: 0x36ef0) ############################
magic:     0x6907
area size: 0x150
        ---------------------------------------------
        type: SHA256 (0x10)
        len:  0x20
        data: 0x82 0xad 0x18 0x3c 0x3d 0xc0 0x99 0xb9 
              0xd4 0xa4 0xe9 0x4c 0xbe 0x7e 0xf5 0x8e 
              0x6f 0x76 0x71 0x41 0x5c 0x4b 0x96 0xf1 
              0x70 0x00 0xbc 0xde 0x09 0x6a 0x32 0x2b 
        ---------------------------------------------
        type: KEYHASH (0x1)
        len:  0x20
        data: 0xfc 0x57 0x01 0xdc 0x61 0x35 0xe1 0x32 
              0x38 0x47 0xbd 0xc4 0x0f 0x04 0xd2 0xe5 
              0xbe 0xe5 0x83 0x3b 0x23 0xc2 0x9f 0x93 
              0x59 0x3d 0x00 0x01 0x8c 0xfa 0x99 0x94 
        ---------------------------------------------
        type: RSA2048 (0x20)
        len:  0x100
        data: 0x35 0x9c 0xa2 0xef 0xd7 0x13 0x3b 0x74 
              0x8a 0x5c 0x0a 0x56 0x37 0xa6 0x4c 0x9e 
              0xf8 0x5e 0x01 0x60 0x84 0x72 0x61 0x54 
              0x7f 0x44 0x4e 0x5e 0x2b 0x48 0xc5 0x72 
              0x55 0xa6 0x6a 0x1a 0x62 0xf9 0xad 0x9a 
              0x80 0xc9 0x7a 0xbd 0x7f 0x29 0x41 0xbd 
              0x7b 0xe8 0x00 0xf9 0x94 0x9b 0x56 0xf8 
              0x0b 0xa9 0xfc 0x09 0xa8 0xae 0xf1 0x10 
              0x4b 0x39 0xa0 0x0f 0x91 0x02 0xac 0xc1 
              0x85 0x4f 0xd3 0xa1 0xf3 0x0a 0xb7 0x98 
              0x13 0xd7 0x09 0x29 0xab 0xba 0x01 0x05 
              0x6b 0xa1 0xf8 0xcb 0x2d 0xd6 0xd3 0x1d 
              0xb9 0xcd 0x0b 0x71 0xfe 0x7d 0xbd 0xc4 
              0xcd 0x31 0x00 0x72 0x03 0xff 0x89 0xce 
              0x38 0x40 0xa8 0xf7 0x76 0x3d 0x9f 0x0e 
              0x01 0x68 0x87 0xef 0xb9 0x65 0x38 0xef 
              0x9e 0xb7 0x88 0x16 0x6b 0xf3 0x77 0x2f 
              0x4b 0x29 0x1b 0xa6 0x7f 0x40 0x82 0xad 
              0x15 0xfd 0xed 0x2c 0x32 0xc7 0x29 0xe2 
              0x5a 0x03 0x96 0xfd 0x7c 0xf7 0x2e 0xd7 
              0x8b 0xf8 0x81 0xdb 0x1c 0x21 0xe3 0xa1 
              0x7f 0xde 0xfb 0xad 0xb1 0xa8 0x6b 0xf9 
              0x41 0x81 0x3a 0x72 0x29 0xe1 0x15 0x3a 
              0x68 0x05 0xc8 0x73 0x60 0x21 0x09 0xdb 
              0x04 0x81 0xc0 0x22 0xbd 0x45 0x8b 0x17 
              0xcf 0xc6 0x45 0x11 0xd2 0x2c 0x29 0x7d 
              0xec 0xd4 0x9f 0x3f 0xe0 0x24 0xee 0x15 
              0xcc 0x49 0xcf 0x33 0xf8 0xe3 0x5b 0x76 
              0x29 0x99 0xb1 0xbd 0x2b 0x47 0xc2 0x51 
              0xa9 0xf8 0xf0 0xdc 0x3f 0x1b 0xe7 0xda 
              0x47 0x79 0x73 0x7c 0xa2 0xae 0xf8 0x48 
              0x12 0xca 0xe7 0x34 0xb7 0x22 0x1f 0x39 
############################################################
#### End of Image ##########################################
dumpinfo has run successfully

Regards,

Vidar