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

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

AndreasF — Thu, 24 Oct 2019 07:09:43 GMT

Hi.

I understand your concern.

The reason I said that configuring the blocks will not really make any difference is because I think that the maximum block size according to the Zigbee specification is 68 bytes if i rememeber correctly. That's because you have all these layers (PHY, MAC, NWK, APS, ZCL).

So yes, you might be able to have it working with a 68 byte block size, but I think that the only thing that will make it noticeable faster is to not have a long delay.

And yes, I understand you want this delay to decrease the Zigbee traffic.

But you could perhaps send out the new firmware slower and update at a later point in time?

Best regards,

Andreas

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

AnnaR — Tue, 22 Oct 2019 20:57:18 GMT

Hi again,

Let explain further with example estimations.

Let suppose that the firmware size is 400kB. Taking into account the Zigbee data rate and neglecting the overhead traffic for simplicity, the non-stop firmware submission would require about 13 seconds.

Then, let suppose that the “Block Request Delay” is set to 5 seconds in order to decrease the load on the Zigbee network in the meantime. The 128-bytes block size gives us the 3200 blocks, that will require approximately 3200 * 5s (delays) + 13 s (pure firmware), so more than 4 hours.

But increasing the block size to 2048 bytes gives the 200 blocks, that will require approximately 200 * 5s (delays) + 13 s (pure firmware), so about the 17 minutes.

Sincerely,

Anna

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

AnnaR — Tue, 22 Oct 2019 07:58:13 GMT

Hi Andreas,

Exactly, I want to increase the “Block Request Delay” in order to decrease the Zigbee traffic with my device in time slots between the OTA block sending. As a consequence, indeed, it requires more time for DFU. So, in order to keep the same overall time, I want to increase the block size.

In other words, I just need to “reshape” OTA DFU traffic for fewer requests with bigger packets’ size.

Sincerely,

Anna

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

AndreasF — Tue, 22 Oct 2019 07:33:05 GMT

Hi again Anna.

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

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

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

AndreasF — Mon, 21 Oct 2019 13:47:41 GMT

Hi Anna.

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

Best regards,

Andreas

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

AnnaR — Sun, 20 Oct 2019 23:34:32 GMT

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

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

Bartosz Gentkowski — Fri, 18 Oct 2019 13:47:57 GMT

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

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

AndreasF — Fri, 18 Oct 2019 13:21:13 GMT

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