Considerations for older firmware versions

Some changes need to be made to this OTA upgrade process for some previous versions of the software.

Version 1009 and prior: Only the GBL file is sent over the air

When the firmware is sent over the air it must be sent without including the OTA header and sub-element tags. See Does the download include the OTA header?

Version 1009 and prior: Delayed ACK for some packets

The Query Next Image Response and the final Image Block Response both cause the client to perform a long operation—erasing/verifying OTA update data in the storage slot. On these versions, the network ACK for the transmission is not sent until after this operation completes. This means that the server will time out waiting for an ACK, and the transmission will appear to fail even though it was in fact received by the client.

On Zigbee, this error can be worked around by enabling the extended APS timeout. Set bit six of the Transmit Options field (0x40) in the transmit API frame, at least when sending a Query Next Image Response or the final Image Block Response.

Version 1008 and prior: Recovering from failed client transmissions

On XBee 3 Zigbee versions 1008 and previous, the OTA client will not attempt to resend a request to the server if it fails due to network conditions. This is known to occur in large networks when the client attempts to send the first Image Block Request or the Upgrade End Request, but could happen at any time during the download due to a failed transmission.

When this occurs, it will appear to the server as though the client stopped sending requests. The server can recover the update from this state using the following method:

  1. When sending messages to the client, the OTA server should check the TX status of the transmission to ensure it was successfully delivered to the client.
  2. When the server waits for the client's response, it should do so with a timeout.
    • How long this timeout should be can vary based on network settings, but something like 20 seconds should cover most cases.
    • Keep in mind when determining the timeout that the client can take a long time (6-8 seconds) to process some OTA commands, such as the Query Next Image Response or the final Image Block Response.
  3. If the server does not receive the request from the client, the server should proceed and send the next response, as though it had received the expected request from the client.
    • For this process, note that firmware versions 1008 and prior will always specify 64 for the maximum data size field of an Image Block Request if encryption is disabled, and 44 if it is enabled. Use these as the maximum sizes when constructing image blocks.
    • For example, if the last packet sent before the timeout was a Query Next Image Response, the server should send an Image Block Request with the first image block, for example 64 bytes—or 44 on an encrypted network—starting at offset 0.
    • If the last packet sent before the timeout was an Image Block Response, the server should send another Image Block Response starting immediately after the end of the last block sent and of the same size.
    • If the last packet sent before the timeout was an Image Block Response containing the final bytes of the image, the server should send an Upgrade End Response.
  1. The client will accept the generated response and continue the update. Failures like this should not happen consistently; If the server times out and has to do this for more than about three packets in a row without hearing from the client, it should assume communication with the client is lost and the update has failed.

Note This method should only be used when updating from a version 1008 or prior. On newer versions the client will resend failed requests, and sending a response unprompted like this could cause an error in the download.

Version 1007 and prior: OTA commands cannot be sent with fragmentation

An OTA update with any of these versions as the client will fail if an OTA command is sent with fragmentation. This is why Image Block Requests sent by these versions set the maximum data size to 64 or 44 bytes. However, on networks with source routing enabled—this includes any network that is using encryption—this means that if a message is sent with a route record included then the payload size must be decreased even more to ensure fragmentation is not used. This can be handled one of two ways by the server:

  1. Set AR to 0xFF on the server for the duration of the update. This will ensure that the OTA server does not send route records to the client, and is the recommended method when updating devices from version 1007 or earlier.
  1. Alternatively, if the number of relays between the server and the client is known, the image block size can be reduced to accommodate the reduced payload size.
    • The payload should be reduced by one byte plus two byes for each relay node—including the client.
    • The payload should then be further reduced to a multiple of four.
    • Be aware that the route could change during the update due to changing network conditions, so it would be wise to include some additional overhead.