• State Verified Answer
  • Replies 5 replies
  • Subscribers 68 subscribers
  • Views 1487 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 231972
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Zigbee OTA upgrade file version, DFU

AnnaR

Zigbee OTA upgrade example uses the Zigbee OTA cluster recommendations concerning the firmware file name (that is used for the version control and prevention of the downgrade to the previous version if such an option enabled). According to mentioned recommendations, file version is the 32-bit binary-coded decimal (BCD), where the upper 2 bytes represent the application release and build, and lower 2 bytes correspond to the stack release (0x0101 in the OTA example).

For example, 0x10120101 means application release 1.0, build 12 with stack release 0.1 b01. So, as for the major, and minor version numbers in release representation, there is only one decimal digit. But what if we need greater version value? For example, how to deal with release 11.10?

Is it possible to omit the stack release and build info, and use the 2 BCD digits (1 byte) for the major value of release number, another 2 BCD digits (1 byte) for the minor value, and remained 4 BCD digits (2 bytes) for the build number? So, the release 11.10 build 35 would be represented as 0x11100035 (without the information about the stack release). We are using the DFU option that prevents firmware downgrade, would it work correctly in this case?

Parents
  • 0

    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

  • 0 in reply to AndreasF

    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

Reply
  • 0 in reply to AndreasF

    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

Children
Related