Init Packet

RE: Init Packet

Rakkumuthu — Wed, 05 Jan 2022 11:15:25 GMT

Hi Bjorn,

I have the init packet as 141 bytes. I am sending over the DFU packet characteristics as 15 bytes from nrf52833 controller. The another nrf52833 DFU bootloader receives upto 135 bytes. the last set of 6 bytes are not received by the bootloader. If i retransmit also, it gives the same result. Please suggest how to send all the 141 init bytes data.

RE: Init Packet

bjorn-spockeli — Tue, 27 Aug 2019 11:55:31 GMT

HI Sonal,

its on_data_obj_write_request() in nrf_dfu_req_handler.c that handles data sent do the DFU packet characteristic.

    NRF_LOG_DEBUG("Handle NRF_DFU_OP_OBJECT_WRITE (data)");

    if (!nrf_dfu_validation_init_cmd_present())
    {
        /* Can't accept data because DFU isn't initialized by init command. */
        p_res->result = NRF_DFU_RES_CODE_OPERATION_NOT_PERMITTED;
        return;
    }

    uint32_t const data_object_offset = s_dfu_settings.progress.firmware_image_offset -
                                        s_dfu_settings.progress.firmware_image_offset_last;

    if ((p_req->write.len + data_object_offset) > s_dfu_settings.progress.data_object_size)
    {
        /* Can't accept data because too much data has been received. */
        NRF_LOG_ERROR("Write request too long");
        p_res->result = NRF_DFU_RES_CODE_INVALID_PARAMETER;
        return;
    }

    uint32_t const write_addr = m_firmware_start_addr + s_dfu_settings.write_offset;

    ASSERT(p_req->callback.write);

    ret_code_t ret =
        nrf_dfu_flash_store(write_addr, p_req->write.p_data, p_req->write.len, p_req->callback.write);

    if (ret != NRF_SUCCESS)
    {
        /* When nrf_dfu_flash_store() fails because there is no space in the queue,
         * stop processing the request so that the peer can detect a CRC error
         * and retransmit this object. Remember to manually free the buffer !
         */
        p_req->callback.write((void*)p_req->write.p_data);
        return;
    }

    /* Update the CRC of the firmware image. */
    s_dfu_settings.write_offset                   += p_req->write.len;
    s_dfu_settings.progress.firmware_image_offset += p_req->write.len;
    s_dfu_settings.progress.firmware_image_crc     =
        crc32_compute(p_req->write.p_data, p_req->write.len, &s_dfu_settings.progress.firmware_image_crc);

    /* This is only used when the PRN is triggered and the 'write' message
     * is answered with a CRC message and these field are copied into the response.
     */
    p_res->write.crc    = s_dfu_settings.progress.firmware_image_crc;
    p_res->write.offset = s_dfu_settings.progress.firmware_image_offset;
}

If the DFU process stops, then please post the debug log output from the bootloader.

It is possible to write larger chunks than 20 bytes as long as you do not exceed the object size, see on_data_obj_write_request(). The ATT MTU size is negotiable, see the BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST case in ble_evt_handler() in nrf_dfu_ble.c. It can be set as high as NRF_SDH_BLE_GATT_MAX_MTU_SIZE, i.e. 247.

Best regards

Bjørn

RE: Init Packet

bjorn-spockeli — Tue, 27 Aug 2019 11:55:29 GMT

HI Sonal,

its on_data_obj_write_request() in nrf_dfu_req_handler.c that handles data sent do the DFU packet characteristic.

    NRF_LOG_DEBUG("Handle NRF_DFU_OP_OBJECT_WRITE (data)");

    if (!nrf_dfu_validation_init_cmd_present())
    {
        /* Can't accept data because DFU isn't initialized by init command. */
        p_res->result = NRF_DFU_RES_CODE_OPERATION_NOT_PERMITTED;
        return;
    }

    uint32_t const data_object_offset = s_dfu_settings.progress.firmware_image_offset -
                                        s_dfu_settings.progress.firmware_image_offset_last;

    if ((p_req->write.len + data_object_offset) > s_dfu_settings.progress.data_object_size)
    {
        /* Can't accept data because too much data has been received. */
        NRF_LOG_ERROR("Write request too long");
        p_res->result = NRF_DFU_RES_CODE_INVALID_PARAMETER;
        return;
    }

    uint32_t const write_addr = m_firmware_start_addr + s_dfu_settings.write_offset;

    ASSERT(p_req->callback.write);

    ret_code_t ret =
        nrf_dfu_flash_store(write_addr, p_req->write.p_data, p_req->write.len, p_req->callback.write);

    if (ret != NRF_SUCCESS)
    {
        /* When nrf_dfu_flash_store() fails because there is no space in the queue,
         * stop processing the request so that the peer can detect a CRC error
         * and retransmit this object. Remember to manually free the buffer !
         */
        p_req->callback.write((void*)p_req->write.p_data);
        return;
    }

    /* Update the CRC of the firmware image. */
    s_dfu_settings.write_offset                   += p_req->write.len;
    s_dfu_settings.progress.firmware_image_offset += p_req->write.len;
    s_dfu_settings.progress.firmware_image_crc     =
        crc32_compute(p_req->write.p_data, p_req->write.len, &s_dfu_settings.progress.firmware_image_crc);

    /* This is only used when the PRN is triggered and the 'write' message
     * is answered with a CRC message and these field are copied into the response.
     */
    p_res->write.crc    = s_dfu_settings.progress.firmware_image_crc;
    p_res->write.offset = s_dfu_settings.progress.firmware_image_offset;
}

If the DFU process stops, then please post the debug log output from the bootloader.

Best regards

Bjørn

RE: Init Packet

bscdb — Thu, 15 Aug 2019 23:12:57 GMT

RE: Init Packet

bscdb — Wed, 14 Aug 2019 14:52:19 GMT

I followed the sequence which you mentioned above. Could you please tell me the location where the packets from firmware file being received are handled in bootloader code? For me, the DFU process stops midway, like only 50% of the firmware file is sent OTA.

How come nRFConnect sends 244 byte packets? The connection diagram in the documentation mentions sending only 20 bytes. Also the sdk config file in the bootloader has 27 bytes set for BLE packet.

RE: Init Packet

bjorn-spockeli — Tue, 13 Aug 2019 08:14:48 GMT

[quote user="bop123"] I'm facing problems sending the firmware image. After I send 06 02, I receive 60-06-01-00-10-00-00-00-00-00-00-00-00-00-00. Does that mean each data object can only be 0x1000 bytes long?[/quote]

Yes, the maximum object size is 4kB (0x1000 bytes).

[quote user="bop123"]Can you please tell me the sequence of commands to send the firmware image? Should I send create command, CRC command & execute command separately for every data object or do I send it just once?[/quote]

This is described in the Transfer of a firmware image message sequence chart. The Select command should only be sent once in the beginning, then you will have to create data objects , transfer the data and send CRC requests until all the objects have been transferred.

Once all objects have been received you send the Execute command.

Best regards

Bjørn

RE: Init Packet

bscdb — Tue, 13 Aug 2019 00:02:45 GMT

Thanks!! I'm facing problems sending the firmware image. After I send 06 02, I receive 60-06-01-00-10-00-00-00-00-00-00-00-00-00-00. Does that mean each data object can only be 0x1000 bytes long? Can you please tell me the sequence of commands to send the firmware image? Should I send create command, CRC command & execute command separately for every data object or do I send it just once?

Also I never really get this response for both init packet & firmware image.

RE: Init Packet

bjorn-spockeli — Mon, 12 Aug 2019 08:54:14 GMT

HI Sonal,

Happy to hear that you're able to send the init packet successfully now. The CRC32 request is handled by the on_data_obj_crc_request() callback in nrf_dfu_req_handler.c. It simply retrieves the CRC stored on the bootloader settings page, see snippet below

static void on_data_obj_crc_request(nrf_dfu_request_t * p_req, nrf_dfu_response_t * p_res)
{
    NRF_LOG_DEBUG("Handle NRF_DFU_OP_CRC_GET (data)");
    NRF_LOG_DEBUG("Offset:%d, CRC:0x%08x",
                 s_dfu_settings.progress.firmware_image_offset,
                 s_dfu_settings.progress.firmware_image_crc);

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

The CRC value is updated on every write request to the DFU packet characteristic, which is handled by the on_data_obj_write_request() callback

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

    if (!nrf_dfu_validation_init_cmd_present())
    {
        /* Can't accept data because DFU isn't initialized by init command. */
        p_res->result = NRF_DFU_RES_CODE_OPERATION_NOT_PERMITTED;
        return;
    }

    uint32_t const data_object_offset = s_dfu_settings.progress.firmware_image_offset -
                                        s_dfu_settings.progress.firmware_image_offset_last;

    if ((p_req->write.len + data_object_offset) > s_dfu_settings.progress.data_object_size)
    {
        /* Can't accept data because too much data has been received. */
        NRF_LOG_ERROR("Write request too long");
        p_res->result = NRF_DFU_RES_CODE_INVALID_PARAMETER;
        return;
    }

    uint32_t const write_addr = m_firmware_start_addr + s_dfu_settings.write_offset;
    /* CRC must be calculated before handing off the data to fstorage because the data is
     * freed on write completion.
     */
    uint32_t const next_crc =
        crc32_compute(p_req->write.p_data, p_req->write.len, &s_dfu_settings.progress.firmware_image_crc);

    ASSERT(p_req->callback.write);

    ret_code_t ret =
        nrf_dfu_flash_store(write_addr, p_req->write.p_data, p_req->write.len, p_req->callback.write);

    if (ret != NRF_SUCCESS)
    {
        /* When nrf_dfu_flash_store() fails because there is no space in the queue,
         * stop processing the request so that the peer can detect a CRC error
         * and retransmit this object. Remember to manually free the buffer !
         */
        p_req->callback.write((void*)p_req->write.p_data);
        return;
    }

    /* Update the CRC of the firmware image. */
    s_dfu_settings.write_offset                   += p_req->write.len;
    s_dfu_settings.progress.firmware_image_offset += p_req->write.len;
    s_dfu_settings.progress.firmware_image_crc     = next_crc;

    /* This is only used when the PRN is triggered and the 'write' message
     * is answered with a CRC message and these field are copied into the response.
     */
    p_res->write.crc    = s_dfu_settings.progress.firmware_image_crc;
    p_res->write.offset = s_dfu_settings.progress.firmware_image_offset;
}

It calls crc32_compute to compute the CRC.

Best regards

Bjørn

RE: Init Packet

bscdb — Fri, 09 Aug 2019 23:18:36 GMT

Thanks Bjorn, I could successfully send the init packet with your help! Can you tell me how is the CRC32 response calculated?

RE: Init Packet

bjorn-spockeli — Fri, 09 Aug 2019 11:58:51 GMT

HI Sonal,

It looks like you are writting the date of the init packet to the Control Point Characteristic and not the DFU Packet characteristic. You see that you get a lot of invalid opcode respones. Try writting the data to the DFU packet characteristic instead.

Best regards

Bjørn

RE: Init Packet

bscdb — Thu, 08 Aug 2019 22:58:43 GMT

My nrf log file which I captured using RTT viewer -

00> <info> app: Inside main
00> <debug> app: In nrf_bootloader_init
00> <debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
00> <debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
00> <debug> nrf_dfu_settings: Settings OK
00> <debug> app: Enter nrf_bootloader_fw_activate
00> <info> app: No firmware to activate.
00> <debug> app: Enter nrf_dfu_app_is_valid
00> <debug> app: No valid app to boot.
00> <debug> app: DFU mode because app is not valid.
00> <info> nrf_bootloader_wdt: WDT is not enabled
00> <debug> app: in weak nrf_dfu_init_user
00> <debug> app: timer_stop (0x200057D0)
00> <debug> app: timer_activate (0x200057D0)
00> <info> app: Entering DFU mode.
00> <debug> app: Initializing transports (found: 1)
00> <debug> nrf_dfu_ble: Initializing BLE DFU transport
00> <debug> nrf_dfu_ble: Setting up vector table: 0x00072000
00> <debug> nrf_dfu_ble: Enabling SoftDevice.
00> <debug> nrf_dfu_ble: Configuring BLE stack.
00> <debug> nrf_dfu_ble: Enabling the BLE stack.
00> <debug> nrf_dfu_ble: No advertising name found
00> <debug> nrf_dfu_ble: Using default advertising name
00> <debug> nrf_dfu_ble: Advertising...
00> <debug> nrf_dfu_ble: BLE DFU transport initialized.
00> <debug> nrf_dfu_flash: Initializing nrf_fstorage_sd backend.
00> <debug> app: Enter main loop
00> <debug> nrf_dfu_ble: Connected
00> <debug> nrf_dfu_ble: Received BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST (request: 527, reply: 247).
00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_SELECT (command)
00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
00> <debug> app: Shutting down transports (found: 1)
00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_CREATE (command)
00> <debug> app: timer_stop (0x200057D0)
00> <debug> app: timer_activate (0x200057D0)
00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
00> <info> nrf_dfu_req_handler: Invalid opcode received: 0x12.
00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x2
00> <warning> nrf_dfu_ble: DFU request 18 failed with error: 0x2
00> <info> nrf_dfu_req_handler: Invalid opcode received: 0x28.
00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x2
00> <warning> nrf_dfu_ble: DFU request 40 failed with error: 0x2
00> <info> nrf_dfu_req_handler: Invalid opcode received: 0xFC.
00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x2
00> <warning> nrf_dfu_ble: DFU request 252 failed with error: 0x2
00> <info> nrf_dfu_req_handler: Invalid opcode received: 0x8A.
00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x2
00> <warning> nrf_dfu_ble: DFU request 138 failed with error: 0x2
00> <info> nrf_dfu_req_handler: Invalid opcode received: 0x94.
00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x2
00> <warning> nrf_dfu_ble: DFU request 148 failed with error: 0x2
00> <info> nrf_dfu_req_handler: Invalid opcode received: 0xBF.
00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x2
00> <warning> nrf_dfu_ble: DFU request 191 failed with error: 0x2
00> <info> nrf_dfu_req_handler: Invalid opcode received: 0xE2.
00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x2
00> <warning> nrf_dfu_ble: DFU request 226 failed with error: 0x2
00> <info> nrf_dfu_req_handler: Invalid opcode received: 0x28.
00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x2
00> <warning> nrf_dfu_ble: DFU request 40 failed with error: 0x2
00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_CRC_GET (command)
00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_EXECUTE (command)
00> <error> nrf_dfu_validation: Execute with faulty offset
00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x8
00> <warning> nrf_dfu_ble: DFUrequest 4 failed with error: 0x8
00> <debug> nrf_dfu_ble: Received BLE_GAP_EVT_CONN_PARAM_UPDATE
00> <debug> nrf_dfu_ble: max_conn_interval: 12
00> <debug> nrf_dfu_ble: min_conn_interval: 12
00> <debug> nrf_dfu_ble: slave_latency: 0
00> <debug> nrf_dfu_ble: conn_sup_timeout: 600

Whats missing?

RE: Init Packet

bjorn-spockeli — Thu, 08 Aug 2019 08:14:09 GMT

[quote user="bop123"]Is the init packet generated from the zip package? - .dat file? [/quote]

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

[quote user="bop123"]I think the responses below are incorrect except the first two. What am I doing wrong?[/quote]

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

RE: Init Packet

bscdb — Wed, 07 Aug 2019 21:43:41 GMT

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

RE: Init Packet

bjorn-spockeli — Thu, 01 Aug 2019 14:39:36 GMT

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);
}

RE: Init Packet

bscdb — Wed, 31 Jul 2019 21:08:33 GMT

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

RE: Init Packet

bjorn-spockeli — Wed, 31 Jul 2019 15:16:28 GMT

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

RE: Init Packet

bscdb — Wed, 31 Jul 2019 15:07:59 GMT

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

RE: Init Packet

bjorn-spockeli — Wed, 31 Jul 2019 11:44:49 GMT

Hi Sonal,

[quote user=""]What is init packet? How do I create one? [/quote]

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

[quote user=""]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?[/quote]

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

Best regards

Bjørn

RE: Init Packet

bjorn-spockeli — Wed, 31 Jul 2019 11:44:49 GMT

Hi Sonal,

[quote user=""]What is init packet? How do I create one? [/quote]

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

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

Best regards

Bjørn