Zigbee OTA upgrade file version, DFU

RE: Zigbee OTA upgrade file version, DFU

AnnaR — Wed, 10 Jul 2019 10:43:51 GMT

Hi.

Thanks for the clarification!

Sincerely,

Anna

RE: Zigbee OTA upgrade file version, DFU

AndreasF — Tue, 09 Jul 2019 08:29:53 GMT

Hi Anna.

I have talked to our developers.

When I did my test and it did not work I was using SDK 3.0.0. Because in SDK 3.0.0 there is a check if the stack release is the same for the new firmware as the old firmware.

In SDK 3.1.0 I'm told that the only check is that the new firmware id (all of the 4 bytes) is larger than the old firmware id.

So you should be able to configure it as you like in SDK 3.1.0, just be sure that the firmware id is larger.

Best regards,

Andreas

RE: Zigbee OTA upgrade file version, DFU

AndreasF — Mon, 08 Jul 2019 13:33:33 GMT

Hi Anna.

I'm waiting for assist from our developers about this question, I will come back to your :-)

Best regards,

Andreas

RE: Zigbee OTA upgrade file version, DFU

AnnaR — Fri, 05 Jul 2019 14:34:50 GMT

Hi Andreas.

Thanks for your answer. I understand, that there are 9999 possible combinations (starting from 1) for the 2-byte (4-digit) BCD. But we use the semantic versioning (https://semver.org/), and it is the completely real situation, that in some future we need, for example, the 1.12.10 version number, or 2.11.15, etc. So, potentially we need at least 4 BCD digits (2 digits for major and 2 digits for minor) instead of 2 BCD digits marked the “Application Release”.

Of course, it is possible to make some additional increment “internal” decoding from the version number shown in the Basic cluster to the value from [1 – 9999] region used for the OTA update, but it would be more convenient to use the same representation for both.

Could you, please, advise, does it worth to look through the OTA client on the subject of mentioned semantic versioning implementation (i.e., omitting the stack number, that is 0x0101 anyway, for the Zigbee OTA client examples from different Zigbee SDK versions with the different ZBOSS builds)?

Or, it is better just to use the conversion to [1..9999] OTA version number, in order to avoid further possible problems with SDK migration, etc.?

Sincerely,

Anna

RE: Zigbee OTA upgrade file version, DFU

AndreasF — Fri, 05 Jul 2019 08:49:52 GMT

Hi.

According to the specification, it is as you mentioned, 2 bytes for application release and build, and 2 bytes for stack release and build.

But you do have 99 different numbers you can use for Application release and Application build.

I've ran some tests and I don't think it is possible to exclude the stack release and build info fields. When I ran the tests the server broadcasts out OTA: Image Notify packets, but the client does not respond with a OTA: Query Next Image Request packet.

Best regards,

Andreas