Using the Application Bootloader for OTA#

Broadcast or Unicast#

Silicon Labs Connect provides two OTA methods:

  • Broadcast: Image is sent to all devices (although a device could ignore it, so in that sense, it is actually multicast). Only single-hop range is supported—that is, the coordinator cannot bootload endpoints behind range extender.

  • Unicast: Image is sent to a single device. If the server and client are in the same Connect network, it will work. Packets are ACKed (both per-hop and end-to-end). The drawback is that it can only target a single device. Therefore, bootloading multiple targets is slow and puts a serious load on the network.

Both broadcast and unicast use a single source to distribute the image. This is called the OTA server. The devices that download the image are called OTA clients. Both broadcast and unicast supports secure messages.

Neither OTA method is available currently for MAC mode. Sleepy end devices cannot be bootloaded using the broadcast method. Although unicast bootloading of a sleepy end device is theoretically possible, it would take an extremely long time and Silicon Labs does not recommend it.

OTA Components#

The following components are required to test OTA in an SoC application.

For both broadcast and unicast OTA:

  • OTA Bootloader Interface: enables the application to communicate with the bootloader (for example, the flash memory is written using bootloader APIs).

  • OTA Bootloader Test Common: implements generic bootloader CLI commands such as erase.

For broadcast OTA:

  • OTA Broadcast Bootloader Client: implements OTA image reception.

  • OTA Broadcast Bootloader Server: implements OTA image transmission.

  • OTA Broadcast Bootloader Test: Implements CLI over the bootloader client/server and connects the OTA plugins with the OTA Bootloader Interface.

For unicast OTA:

  • OTA Unicast Bootloader Client: implements OTA image reception.

  • OTA Unicast Bootloader Server: implements OTA image transmission.

  • OTA Unicast Bootloader Test: Implements CLI over the bootloader client/server and connects the OTA components with the OTA Bootloader Interface.

All components are open source.

Theory of Operation: Broadcast OTA#

The broadcast OTA completes these steps:

  1. Clients who want to download the same image set up the same tag.

  2. The server starts broadcasting tagged image segments (a chunk of the firmware that fits into a connect data frame with memory address).

  3. The clients store the broadcasted image segments. Based on the addresses, they also recognize missing segments.

  4. The server stops the broadcast after 512 segments and asks each client (with unicast message) what segments are missing.

  5. The clients report the missing segments and the server collects this information.

  6. The server re-broadcasts the missing segments.

  7. The server asks again for missing segments and this loop continues until all the clients have the first 512 segments.

  8. The server broadcasts the next 512 segments and this loop continues until all the clients have the full image.

The tags can be used in a network where not all devices run the same firmware, or it can be used for versioning to make sure a device will not participate in the OTA process if it already has the same image.

Theory of Operation: Unicast OTA#

Unicast OTA is much simpler. It completes these steps:

  1. The clients set up a tag.

  2. The server sends a handshake, telling the client the image size and the tag.

  3. The client responds to the handshake.

  4. The server sends a tagged image segment (a chunk of the firmware that fits into a connect data frame with memory address).

  5. The client responds with a segment response.

  6. If the server did not receive a response, it sends the segment again.

  7. If the server did receive the response, it sends the next segment, and continues this loop until the client has the whole image.

The tag is still available. It can be used for versioning. The server retries to transmit the unacknowledged segment multiple times before it stops the transmission. The client has a five second timeout before it drops the current firmware download. A resume function has been implemented in Flex 2.6. The client counts how many segments were received. If the connection was lost between the server and the client, once the server re-initiates the download, the client informs the server during the handshake to send only the remaining portion. The segment counter on the client side is cleared if the tag changed or a flash erase command has been executed by the client. If the communication was interrupted, the re-initiation of the download is the responsibility of the customer’s application on the server side.

Remote Bootload Request#

Both broadcast and unicast OTA components implement command messages which makes remote bootload requests possible—that is, the OTA server can request bootload from clients, and in response, the clients will load the downloaded image into the main memory and boot into that.