OTA Update Process (Classic Bluetooth)

This topic describes the process by which an Echo device and a gadget communicate to perform an over-the-air (OTA) update over Classic Bluetooth.

For the requirements that your gadget must meet to perform OTA updates, see OTA Update Prerequisites. An additional prerequisite is that your gadget must have two RFCOMM servers running: one for OTA updates (UUID 0x1101), and one for events and directives (UUID 0x1201).


After a gadget is paired to an Echo device over Bluetooth, the Echo device can initiate and provide an OTA update by sending the gadget a series of commands. The protocol of the commands is described in OTA Update Commands. The gadget executes the commands and in some cases returns a response. The Echo device and the gadget exchange these commands and responses over Bluetooth using the serial port protocol (SPP) packet format described in Packet Format.

The following figure shows how a gadget and an Echo device interact to perform the OTA update of the gadget's firmware. The procedure assumes that the Echo device and the gadget are already paired. The steps are explained after the figure.

Alexa Gadget OTA Update over Classic Bluetooth

OTA update procedure

This section describes the OTA update steps that are shown in the previous figure.

Establishing an RFCOMM connection

In this step, which is identical to the RFCOMM connection phase in the initial Bluetooth connection flow, the Echo device establishes an SPP link with the gadget. To do so, it sends the gadget a request to connect to its RFCOMM server for OTA (UUID 0x1101). This is a separate RFCOMM server than the one used to exchange events and directives (that server has a UUID of 0x1201). For the connection to be established, the gadget's local SDP database must contain the settings listed in SDP Database Settings.

OTA handshake

In this step, some Echo devices request the gadget's OTA version by sending the gadget a CMD_VERSION command. The gadget returns its OTA version from non-volatile memory. However, the decision as to whether an OTA update should be performed is based on the firmwareVersion that the gadget reports using the Discover.Response event during Bluetooth connection or reconnection.

Checking the readiness of the gadget

Some Echo devices send the gadget a CMD_BATTERY command to query whether the gadget is in a state sufficient to perform the OTA update. Because battery level is an example of a factor that might affect this decision, this command is called CMD_BATTERY for now, but is subject to change. Regardless of the influencing factors, the gadget returns a value above 0x0A to indicate that it is ready for the update, or below 0x0A to indicate that it is not ready.

Erasing the gadget's flash

If the gadget indicates that it is ready for the update, the Echo device sends a CMD_ERASE command to the gadget, which instructs the gadget to erase the flash that will contain the new image. An erasure can take several seconds to complete. To determine the status of the erasure, the Echo device repeatedly sends the gadget a CMD_STATUS command. The gadget indicates that erasure is complete by returning 0x00.

Writing the new image to the gadget's flash

The Echo device then writes the new firmware image to the gadget's flash buffer by sending the gadget a succession of commands:

  • The first command, CMD_WRITE_METADATA, writes the metadata of the image.
  • The next command, CMD_WRITE_SIGNATURE, writes signature data. The gadget extracts the OTA version from this data, and stores the value in non-volatile memory as its new OTA version.
  • The last command, CMD_WRITE, downloads the rest of the image. The Echo device calls CMD_WRITE repeatedly until the entire image is downloaded to the gadget.

The gadget can calculate the CRC incrementally as it receives each CMD_WRITE. When the gadget receives the last CMD_WRITE, it can validate the CRC of the downloaded image. For details about calculating the CRC, see CMD_WRITE.

Applying the update

The gadget then applies the update in a manner that is gadget-specific. The goal is to make the newly downloaded image the boot image. In the example provided in the Prerequisites section, the gadget switches the boot address from the active section to the OTA section. That way, when the gadget resets, it loads the new image.

Was this page helpful?

Last updated: Feb 14, 2022