3.2.16. Firmware Update Meta Data Command Class, version 2¶
Firmware Update Meta Data Command Class, version 2 updates the Firmware Update Meta Data Report Command.
\requirement{CC:007A.02.00.11.001}{4}
While support for version 1 has been deprecated, a controlling device implementing Firmware Update Meta Data Command Class, version 2 MUST also be able to control Firmware Update Meta Data Command Class, version 1 based devices.
3.2.16.1. Compatibility considerations¶
\requirement{CC:007A.02.00.21.001}{0}
A node supporting Firmware Update Meta Data Command Class, version 2 MUST also support Firmware Update Meta Data Command Class, version 1.
All commands and fields not described in this version remain unchanged from version 1.
3.2.16.2. Interoperability considerations¶
3.2.16.2.1. Interoperability with v1 devices¶
Version 2 of the Firmware Update Meta Data Report command introduces a 16-bit Checksum field to follow the variable-length Data field. No fields follow the variable-length Data field in Version 1 of the Firmware Update Meta Data Report command.
At the same time, the specified method for determining the length of the variable-length Data field is that the length must be calculated from the length of the received frame.
The unintended consequence is that a version 1 implementation receiving a Firmware Update Meta Data Report v2 command will consider the 16-bit Checksum field to be the last two bytes of the Data field.
Similarly, a version 2 implementation receiving a Firmware Update Meta Data Report v1 command will consider the last two bytes of the Data field to be the 16-bit Checksum field.
In either case, the transfer will fail.
\requirement{CC:007A.02.00.31.001}{0}
Therefore, a controlling device implementing the Firmware Update Meta Data Command Class, version 2 MUST do the following when initiating the transfer of a firmware image:
Request the version of the Firmware Update Meta Data Command Class from the target device
Use the version of the Firmware Update Meta Data Report implemented by the target device
Determine the number of Data bytes that can fit into the Firmware Update Meta Data Report command so that the complete command can still fit into the payload field of the transport frame. The number of available payload bytes in the frame depends on the actual bit rate, the use of security encapsulation as well as the presence of Checksum bytes in the Firmware Update Meta Data Report.
\requirement{CC:007A.02.00.32.001}{0}
The controller SHOULD accept any binary image format and transfer that without any modifications. The image may be encrypted or carry checksums.
3.2.16.2.2. Checksum calculation¶
Version 1 of the Firmware Update Meta Data Command Class introduced a 16-bit Checksum field used to verify firmware image integrity. It has been a recommendation to use the CRC-CCITT polynomial for calculating checksums. Nodes having implemented another method for calculating the checksum will find a non-matching checksum.
From Version 5 onwards, the checksum calculation method is mandatory. For more details about the checksum calculation, refer to CRC-CCITT Source Code.
3.2.16.3. Firmware Update Meta Data Report Command¶
The Firmware Update Meta Data Report command is used to transfer a firmware image fragment.
\requirement{CC:007A.02.06.11.001}{0}
If sending more than a single Firmware Update Meta Data Report Command at a time, a node MUST apply a delay between each transmitted command. The minimum required time delay and number of frames before a delay must be inserted depends on the actual bit rate.
40 kbit/s: At least 35 ms if sending more than 1 frame back-to-back
100 kbit/s: At least 15 ms if sending more than 2 frames back-to-back
\requirement{CC:007A.02.06.12.001}{0}
If needed, a controlling node SHOULD abort an ongoing transfer by responding to a Firmware Update Meta Data Get Command with a Firmware Update Meta Data Report Command with the Last bit enabled and the Data fields intentionally corrupted while the Checksum field of the Firmware Update Meta Data Report Command is valid, i.e. calculated over the corrupted Data fields.
This will invalidate the calculated firmware checksum, which should eventually cause the receiving device to return a Firmware Update Meta Data Status Report Command with the status code <checksum error>.
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|---|---|---|---|---|---|---|---|
Command Class = COMMAND_CLASS_FIRMWARE_UPDATE_MD (0x7A) |
|||||||
Command = FIRMWARE_UPDATE_MD_REPORT (0x06) |
|||||||
Last |
Report number 1 |
||||||
Report number 2 |
|||||||
Data 1 |
|||||||
… |
|||||||
Data N |
|||||||
Checksum 1 |
|||||||
Checksum 2 |
|||||||
All fields not described below remain unchanged from version 1.
Checksum (16 bits)
\requirement{CC:007A.02.06.11.002}{0}
The checksum field MUST be used to ensure the consistency of the entire command; including the command class and command identifiers.
\requirement{CC:007A.02.06.12.002}{0}
It is RECOMMENDED to use a checksum algorithm that implements the CRC-CCITT polynomium using initialization value equal to 0x1D0F and 0x1021 (normal representation).
The Checksum field is known to cause compatibility issues with version 1 devices. Refer to Section 3.2.16.1.