The Block Request Delay and Maximum Data Size attributes for the Zigbee OTA upgrade

[AnnaR]

While using the Zigbee OTA examples (nRF Thread and ZigBee SDK v3.1.0), I have noticed by the sniffer, that the attribute “Block Request Delay” is presented in the OTA Upgrade Image Block Request from the client, and it’s equal to 0x00b8 milliseconds. But I have not found, where this value is set in the OTA client example? I need to slow down the request rate by increasing the default delay value on the OTA client side. Is it possible for this Zigbee stack/SDK version?

Also, I tried to increase the BACKGROUND_DFU_DEFAULT_BLOCK_SIZE (which corresponds to the Maximum Data Size attribute) to the value of 1024, which seemed okay according to the sdk_config.h comment Block size used by background DFU.  <1-4096>. But the warning message large integer implicitly truncated to unsigned type -woverflow appeared in SES. So, I looked further, and have seen, that the max_data_size field of zb_zcl_ota_upgrade_client_variable_s has the zb_uint8_t type limiting the maximum value up to 255 instead of 4096.

So, could the BACKGROUND_DFU_DEFAULT_BLOCK_SIZE be actually set up to 4096 somehow in the mentioned stack/SDK version?

I tried to look through the PICS document with the information about OTA features implemented by the Zigbee stack, but this link from infocenter seems to be dead (produce the 404 error).

[AndreasF]

Hi.

For "Block Request Delay", you can change the value of this attribute in for example ota_client_attr_init() in the client example:

static void ota_client_attr_init(void)
{
    /* Basic cluster attributes data */
    m_dev_ctx.basic_attr.zcl_version  = ZB_ZCL_VERSION;
    m_dev_ctx.basic_attr.power_source = ZB_ZCL_BASIC_POWER_SOURCE_UNKNOWN;

    /* OTA cluster attributes data */
    zb_ieee_addr_t addr = ZB_ZCL_OTA_UPGRADE_SERVER_DEF_VALUE;
    ZB_MEMCPY(m_dev_ctx.ota_attr.upgrade_server, addr, sizeof(zb_ieee_addr_t));
    m_dev_ctx.ota_attr.file_offset = ZB_ZCL_OTA_UPGRADE_FILE_OFFSET_DEF_VALUE;
    m_dev_ctx.ota_attr.file_version = OTA_UPGRADE_TEST_FILE_VERSION;
    m_dev_ctx.ota_attr.stack_version = ZB_ZCL_OTA_UPGRADE_FILE_HEADER_STACK_PRO;
    m_dev_ctx.ota_attr.downloaded_file_ver  = ZB_ZCL_OTA_UPGRADE_DOWNLOADED_FILE_VERSION_DEF_VALUE;
    m_dev_ctx.ota_attr.downloaded_stack_ver = ZB_ZCL_OTA_UPGRADE_DOWNLOADED_STACK_DEF_VALUE;
    m_dev_ctx.ota_attr.image_status = ZB_ZCL_OTA_UPGRADE_IMAGE_STATUS_DEF_VALUE;
    m_dev_ctx.ota_attr.manufacturer = OTA_UPGRADE_TEST_MANUFACTURER;
    m_dev_ctx.ota_attr.image_type = OTA_UPGRADE_TEST_IMAGE_TYPE;
    m_dev_ctx.ota_attr.min_block_reque = 0xF88;
    m_dev_ctx.ota_attr.image_stamp = ZB_ZCL_OTA_UPGRADE_IMAGE_STAMP_MIN_VALUE;
}

Simply change the attribute m_dev_ctx.ota_attr.min_block_reque.

The second question:

 The 3.1.0 SDK does not support APS fragmentation, thus you cannot use 4096 block sizes.

Have a nice weekend.

Best regards,

Andreas

[Bartosz Gentkowski]

Hi, the infocenter link to the PICS document is now fixed. Thanks for letting us know!

[AnnaR]

Hi Andreas,

Thank you for your reply. I should have known better about the min_block_reque field (which name, however, is a bit misleading), I just didn’t guess to look at the corresponding attribute ID [0x0009].

About the block size, what is the maximum value that can be set with 3.1.0 SDK, and would the 3.2.0 SDK give the block size increasing? As I understood, in order to have the 4096-size blocks kept in RAM during DFU (for further convenient flashing?), I need to select BACKGROUND_DFU_DEFAULT_BLOCK_SIZE and BACKGROUND_DFU_BLOCKS_PER_BUFFER in such a way that their multiplication will give 4096? The default values of example are both 64, so 64 * 64 gives 4096-bytes block. Then, If I need to increase the BACKGROUND_DFU_DEFAULT_BLOCK_SIZE, I can use the only 128, in order to achieve the 4096-bytes resulting block in RAM. The max uint8 255 is not the multiple of 4096, so as I guess, it is not a good idea.

Anyway, either 128 or 255, these are quite small blocks to transfer in case of the OTA blocks should be submitted with the 5 seconds interval, for example. So, the 400kB firmware image would be updated as long as more than four hours. Is there some solution, how to overcome this issue?

Sincerely,

Anna

[AndreasF]

Hi Anna.

I'm doing some testing and I will get back to you tomorrow if that is ok.

Best regards,

Andreas

[AndreasF]

Hi again Anna.

AnnaR said:

Anyway, either 128 or 255, these are quite small blocks to transfer in case of the OTA blocks should be submitted with the 5 seconds interval, for example. So, the 400kB firmware image would be updated as long as more than four hours. Is there some solution, how to overcome this issue?

 Could I just ask you to clarify this? :-)

You wanted to increase the “Block Request Delay”, which increases the time used for DFU.

And then you want to configure BACKGROUND_DFU_DEFAULT_BLOCK_SIZE and BACKGROUND_DFU_BLOCKS_PER_BUFFER to try to reduce the time used for DFU?

It should be noted that Zigbee uses a background DFU process, so you have all the functionality on your device while doing the DFU. If you compare DFU in Zigbee and BLE you can see that the reason it takes so long to do DFU in Zigbee is because the throughput is lower and the image is quite large (it's not image, not split images like in BLE).

I don't really think that configuring blocks will make any significant change in time spent on DFU to be honest.

Best regards,

Andreas