Bluetooth BLE OTA specification

Interaction flow

To ensure a secure OTA update, the security authentication process must be completed before the update begins. If authentication fails, the OTA update is not allowed. For more information about security authentication, see the Bluetooth BLE basic specification.

The OTA flow between a mobile phone and a Bluetooth device is as follows.

Use of basic specifications

• Broadcast specification

  OTA is an optional feature. If a Bluetooth device supports this feature, it must be indicated in the FMSK field of the broadcast specification.

• Service specification

  The transmission process uses the Service and Characteristics that are defined in the basic specification and distinguished by instruction type. When the mobile app sends firmware, it uses the WriteWithNoRsp Characteristic (0xFED7) to speed up the transmission. After the Bluetooth device receives a data packet, it uses the Notify Characteristic (0xFED8) to send an acknowledgement to the app. During firmware reception, if the device detects an error in the data ordinal number, it reports the last correct ordinal number.

• Data transmission specification

  Data transmission uses the data format and rules defined in the basic specification.

Version format

The firmware type is a 1-byte number that distinguishes different firmware types for the same device. The version format is a 4-byte number. For example, 0x00010302 represents firmware version 1.3.2. The version number can only be incremented. The maximum version number is 99.99.99. The version format rules are as follows.

Upgrade rules

• The firmware to be upgraded is pushed to the server-side. The firmware version information and the reason for the upgrade are also provided.
• If the server-side confirms that the pushed firmware version is newer than the version reported by the device, the server-side pushes an upgrade notification to the mobile app.
• The mobile app forwards the upgrade request, firmware version information (application version only), firmware size, and CRC.
• The Bluetooth device checks the application version information of the firmware. If the application version from the app is newer than the current firmware version on the device, the Bluetooth device enters upgrade mode. Otherwise, it exits upgrade mode.
• The protocol is designed to support firmware breakpoint retransmission. As shown in step 12 of the "Interaction flow" figure, the Bluetooth device can respond with the position at which the last firmware transmission was interrupted. The mobile app then resumes transmission from the specified position. Breakpoint retransmission is an optional feature and can be implemented as needed.
• The protocol is designed to support a fast transmission mode. In this mode, the mobile app continuously transmits a number of data packets specified by TotalFrame (0 < TotalFrame <= 16) without waiting for a reply from the Bluetooth device for each packet. The Bluetooth device replies only after all TotalFrame packets are sent. Then, the mobile app starts the next round of data transmission.
• All instructions must be encrypted after the authentication process, except for the 0x2F instruction (send firmware packet), which does not require encryption.

OTA instruction set

• CMD 0x20: The mobile phone queries the device firmware version.

  The payload is 1 byte and specifies the firmware type. The default value is 0x00. Based on the specified firmware type, the device returns the corresponding version number information in the 0x21 response.

  Header (1 byte)	CmdType (1 byte)	Total Frame & Seq (1 byte)	Length (1 byte)	Payload (1 byte)
  0x00	0x20	0x00	0x01	0x00

  Note A value of 0x00 in the Total Frame & Seq field indicates that there is a total of one frame and the current data is the first frame.
• CMD 0x21: The device reports its firmware version.
  The payload is 5 bytes:

  • Firmware type (1 byte): The default value is 0x00. If an unsupported firmware type is requested, the device reports 0xFF.
  • Firmware version number (4 bytes): For example, 0x00000002.

  Header (1 byte)	CmdType (1 byte)	Total Frame & Seq (1 byte)	Length (1 byte)	Payload (5 bytes)
  0x00	0x21	0x00	0x05	0x00 0x00000002

  Note The Msg ID in the 0x21 instruction must match the Msg ID in the 0x20 instruction.
• CMD 0x22: The mobile phone sends an upgrade request.
  The payload is 12 bytes:

  • Firmware type (1 byte): The default value is 0x00.
  • Firmware version number (4 bytes): For example, 0x00000001.
  • Firmware size (4 bytes): For example, 0x00123456.
  • CRC16 (2 bytes): Uses CRC16_CCITT.
  • Upgrade identifier (1 byte): 0 for full upgrade, 1 for incremental upgrade, and 2 for silent upgrade.

  Header (1 byte)	CmdType (1 byte)	Total Frame & Seq (1 byte)	Length (1 byte)	Payload (12 bytes)
  0x00	0x22	0x00	0x0c	0x00 0x00000001 0x00123456 0x7890 0x00

• CMD 0x23: The device acknowledges the upgrade request.
  The payload is 6 bytes:

  • Upgrade allowed (1 byte): 0 indicates not allowed, and 1 indicates allowed.
  • Number of bytes transmitted in the last session (4 bytes)
  • Number of packets allowed per transmission loop (1 byte): The value range is 0x00 to 0x0F, representing 1 to 16 packets.

  Header (1 byte)	CmdType (1 byte)	Total Frame & Seq (1 byte)	Length (1 byte)	Payload (6 bytes)
  0x00	0x23	0x00	0x06	0x01 0x00000000 0x0F

  Note The Msg ID in the 0x23 instruction must match the Msg ID in the 0x22 instruction. If the device supports breakpoint retransmission, the 'Number of bytes transmitted in the last session' field reports the length of the firmware that has already been received.
• CMD 0x24: The device reports the ordinal number of the last received frame and the total length of data received.
  The payload is 5 bytes:

  • Number of received frames (1 byte): totalFrame 4 bits + frameSeq 4 bits
  • Data length (4 bytes): For example, 0x00000200.

  Header (1 byte)	CmdType (1 byte)	Total Frame & Seq (1 byte)	Length (1 byte)	Payload (5 bytes)
  0x00	0x24	0x00	0x05	0x20 0x00000200

  If the device detects a lost frame, it reports the ordinal number and data length of the last correctly received frame. The mobile phone then retransmits the data, starting from the lost frame, and sends the remaining frames in the current loop.

• CMD 0x25: The mobile phone notifies the device that the firmware transmission is complete and that a firmware check can be performed.

  Header (1 byte)	CmdType (1 byte)	Total Frame & Seq (1 byte)	Length (1 byte)	Payload (1 byte)
  0x00	0x25	0x00	0x01	0x01

• CMD 0x26: After it receives all packets, the device reports the firmware check result.

  Firmware check result (1 byte): 0 indicates that the firmware check failed, and 1 indicates that the firmware check was successful.

  Header (1 byte)	CmdType (1 byte)	Total Frame & Seq (1 byte)	Length (1 byte)	Payload (1 byte)
  0x00	0x26	0x00	0x01	0x01

  Note The Msg ID in the 0x26 instruction must match the Msg ID in the 0x25 instruction.
• CMD 0x2F: The mobile phone sends firmware packet data.

  Header (1 byte)	CmdType (1 byte)	Total Frame & Seq (1 byte)	Length (1 byte)	Payload (N bytes)
  0x00	0x2F	0xF0	0x10	0x00 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88 0x99 0xAA 0xBB 0xCC 0xDD 0xEE 0xFF

  The firmware is divided into packets of a specified length. One loop consists of 16 packets. The frame ordinal number (Msg ID) in the header cycles from 0 to 15.

  Note A value of 0xF0 in the Total Frame & Seq field indicates that there is a total of 16 frames and the current data is the first frame.

OTA data transmission and Characteristic mapping

Retransmission epoch

If the same fault occurs multiple times consecutively within one retransmission epoch, the device sends the 0x24 instruction only once. The retransmission epoch is calculated by multiplying 500 ms by the TotalFrame value. For example, if the maximum number of data frames allowed per loop is 10, the retransmission epoch is 500 ms × 10, which equals 5 seconds.

Abnormal handling logic

• If the device receives a packet with a sequence number (seq) that does not match the expected seq, the device sends an 0x24 instruction in response. This instruction reports the seq of the last consecutively received packet and the total length of the data that has been received. After it receives the 0x24 instruction, the mobile app or Tmall Genie uses the 0x2F instruction to retransmit the lost packet. The content, including the header and payload, must be identical to the original packet. After it receives the remaining packets in the loop, the device must send an 0x24 instruction in response. Then, the mobile app or Tmall Genie continues to transmit the rest of the firmware.
• If the device detects a data reception fault, it reports the 0x24 instruction only once per retransmission epoch. This limit is reset after the expected data is received correctly.
• After the device sends an 0x24 instruction, if it does not receive the expected packet within the retransmission epoch, it sends the 0x24 instruction again.
• If the device repeatedly sends the same 0x24 instruction more than five times, it disconnects.
• If the amount of remaining data at the end of the firmware transmission is less than TotalFrame × MTU, the TotalFrame for the current transmission loop is determined by the actual number of remaining packets. When the device determines that the amount of data received equals the total firmware length, it must immediately send an 0x24 instruction in response.

Summary of abnormal handling

The device must send an 0x24 instruction in response in the following situations.

• The device must respond with the 0x24 instruction after receiving all the data packets in a single loop.
• When the device receives a packet with a sequence number (seq) that is different from the expected one. In the event of a data fault, the 0x24 instruction can be sent only once per retransmission epoch.
• Upon receiving all the data packets retransmitted in a single loop, the device must respond with the 0x24 instruction.
• If a device fails to receive the packet with the expected seq within a retransmission epoch, it must reply with the 0x24 instruction.
• The device must respond with the 0x24 instruction upon receiving the complete firmware.

References

CRC16 algorithm parameters.

• CRC-16/CCITT-FALSE
• Width: 16-bit
• Polynomial (POLY): 0x1021
• Initial value (INIT): 0xFFFF
• Result exclusive OR value (XOROUT): 0x0000
• Input data inverted (REFIN): false
• Output data inverted (REFOUT): false