Init Packet

[bscdb]

I'm referring this

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v15.2.0%2Flib_dfu_transport_ble.html

which states that when in bootloader mode, I've to send the init packet first & then the firmware image.

So what happens after I send 06 01 command. What is init packet? How do I create one? The response received for each command - is it written over a characteristic or a descriptor inside characteristic? My understanding is DFU Control Point & DFU Packet characteristics do not support read property. So where can I see the response received for every command sent by host to BLE device?

Sorry I could not understand a thing from the sniffer trace which I captured while executing the actual DFU procedure listed on Nordic Infocenter. I'm using SDK 15.2 & nrf52832.

5875.original.pcapng

[bjorn-spockeli]

Hi Sonal, 

What is init packet? How do I create one?

the Init packet is part of the DFU firmware image that you create using nrfutil, see https://github.com/NordicSemiconductor/pc-nrfutil. 

The response received for each command - is it written over a characteristic or a descriptor inside characteristic? My understanding is DFU Control Point & DFU Packet characteristics do not support read property. So where can I see the response received for every command sent by host to BLE device?

 The response is a characteristic notification from the BLE peripheral to the BLE Central. 

Best regards

Bjørn

[bscdb]

Thanks Bjorn! How can I read this response? On which characteristic is this response sent? 

[bjorn-spockeli]

As show in the Transfer of an init packet MSC, its the DFU Control Point characteristic that Notifies the DFU controller. In order to receive notifications you will have to enable Notifications by writting to the CCCD of the DFU Control Point characteristic. 

Bjørn

[bscdb]

Ok. Where in the secure bootloader code is this response being sent?

[bjorn-spockeli]

It is done in the request handler module of the bootloader , see on_data_obj_select_request in nrf_dfu_req_handler.c (nRF5_SDK_15.2.0_9412b96\components\libraries\bootloader\dfu\nrf_dfu_req_handler.c)

static void on_data_obj_select_request(nrf_dfu_request_t * p_req, nrf_dfu_response_t * p_res)
{
    NRF_LOG_DEBUG("Handle NRF_DFU_OP_OBJECT_SELECT (data)");

    p_res->select.crc    = s_dfu_settings.progress.firmware_image_crc;
    p_res->select.offset = s_dfu_settings.progress.firmware_image_offset;

    p_res->select.max_size = DATA_OBJECT_MAX_SIZE;

    NRF_LOG_DEBUG("crc = 0x%x, offset = 0x%x, max_size = 0x%x",
                  p_res->select.crc,
                  p_res->select.offset,
                  p_res->select.max_size);
}

[bscdb]

Is the init packet generated from the zip package? - .dat file? 

I think the responses below are incorrect except the first two. What am I doing wrong?

HOST -> BLE DEVICE	BLE DEVICE -> HOST
06 01	60-06-01-00-01-00-00-00-00-00-00-00-00-00-00
01 01 8E 00 00 00	60-01-01
12 8b 01 0a 45 08 01 12 41 08 90 4e 10 34 1a 02 af 01 20 00	60-12-02
28 00 30 00 38 b0 8e 03 42 24 08 03 12 20 01 91 8e 46 bb 14	60-28-02
fc b6 37 95 6d dd d4 34 40 a4 60 ab ec 76 57 8f 9c 72 e6 b5	60-FC-02
8a 62 c7 9b b3 df 48 00 52 04 08 01 12 00 10 00 1a 40 9d 86	60-8A-02
94 d0 23 bd 0e db 03 47 26 f9 4d 27 77 4c 4b 04 8e de 75 79	60-94-02
bf d4 b5 1a df 0f 5a 39 f0 b1 5b 44 bc 12 bf 16 87 99 6d c8	60-BF-02
e2 a7 aa 4e 62 c4 ad 68 55 2f b1 8c a4 27 1e bc 07 65 5a 0f	60-E2-02
28 a3	60-28-02
3	60-03-01-00-00-00-00-00-00-00-00
4	60-04-08

[bjorn-spockeli]

bscdb said:

Is the init packet generated from the zip package? - .dat file? 

Yes, the init packet is the .dat file in the zip package. 

bscdb said:

I think the responses below are incorrect except the first two. What am I doing wrong?

The first request from the host is the select command, where the control point replies with 60-06-01-00-01-00-00-00-00-00-00-00-00-00-00, which means that the Select command was successful, i.e. 60-06-01, then you have the max size of the init packet 00-01-00-00, the offset 00-00-00-00 and the CRC32 00-00-00-00. 

The second request is a Create request from the host, i.e. 01 01, where it informs the Control Point that the size of the init packet is 8E 00 00 00.

The Control point should not respond to the data packets after the Control Point has replied with Create Success, i.e. 60-01-01.

The two last operations consists of the following:

Opcode 3 is a CRC request from the host. The control point replies with 60-03-01-00-00-00-00-00-00-00-00, which is means NRF_SUCESS, but the offset and the current CRC is zero.

Opcode 4 is an Execute request from the host. The control point replies replies with 60-04-08, which means NRF_DFU_RES_CODE_OPERATION_NOT_PERMITTED. 

I would recommend to debug the bootloader when you transfer the init packet and set breakpoints at the following locations in the bootloader code.

nRF5_SDK_15.2.0_9412b96/components/libraries/bootloader/dfu/nrf_dfu_req_handler.c:p_res->result = NRF_DFU_RES_CODE_OPERATION_NOT_PERMITTED;
nRF5_SDK_15.2.0_9412b96/components/libraries/bootloader/dfu/nrf_dfu_req_handler.c:p_res->result = NRF_DFU_RES_CODE_OPERATION_NOT_PERMITTED;
nRF5_SDK_15.2.0_9412b96/components/libraries/bootloader/dfu/nrf_dfu_req_handler.c:p_res->result = NRF_DFU_RES_CODE_OPERATION_NOT_PERMITTED;
nRF5_SDK_15.2.0_9412b96/components/libraries/bootloader/dfu/nrf_dfu_req_handler.c:p_res->result = NRF_DFU_RES_CODE_OPERATION_NOT_PERMITTED;
nRF5_SDK_15.2.0_9412b96/components/libraries/bootloader/dfu/nrf_dfu_validation.c:ret_val = NRF_DFU_RES_CODE_OPERATION_NOT_PERMITTED;

You should hit one of them and then hopefully get an indication to why the bootloader does not permit the init packet. 

Best regards

Bjørn