OTA

OTA升级介绍

涂鸦蓝牙 SDK 实现了固件升级部分，包括蓝牙以及MCU部分。

由于固件升级和芯片平台架构关联较大，涂鸦蓝牙 SDK 只提供固件升级接口，设备 Application 需通过 OTA 通信接口实现代码交互逻辑。

升级流程

升级协议

OTA升级请求（TUYA_BLE_OTA_REQ）

App>设备：

	data_len=1
长度：	1 字节
Data：	固定 0

设备->App:

	data_len=9
长度：	1 字节	1 字节	1 字节	4 字节	2 字节
data：	Flag	OTA_Version	0	Version四字节	最大包长度

参数说明：

Flag：0x00 - 允许升级，0x01 - 拒绝升级。

OTA_Version：OTA 协议大版本，例如 0x03 代表 3.X 的协议版本。

Version：当前固件版本号,大端格式，例如 0x00 01 00 02 代表版本为 V1.0.2。

最大包长度：设备允许的单包最大长度，单位字节，当前版本不要超过 512字节。

OTA升级文件信息（TUYA_BLE_OTA_FILE_INFO）

App->设备：

	data_len=37
长度：	1 字节	8 字节	4 字节	16 字节	4 字节	4 字节
Data：	0	产品 PID（保留）	文件版本	文件 MD5	文件长度	CRC32

文件版本：例如，0x00010002代表版本为V1.0.2。

说明： 下发参数中 PID 字段，若需支持OEM，则会存在PID不一致的情况。因此建议设备 Application 在OTA时无需校验PID 并忽略该参数。

设备->App:

	data_len=26
长度：	1 字节	1 字节	4 字节	4 字节	16 字节
data：	0	STATE	已储存文件长度	已储存文件CRC32	已储存文件 MD5（目前不使用）

STATE：

0x00：正常升级

0x01：产品 PID 不一致

0x02: 文件版本低于或者等于当前版本

0x03：文件大小超过范围。

其他：保留。

已储存文件信息：

为了支持断点续传，这里需要返回设备端已经储存的文件信息。App 在收到后，首先根据设备返回的已储存文件长度计算新文件对应长度的 CRC32，然后和设备返回的 CRC32 对比，如果两者都吻合，那么在下面的文件起始传输请求中将起始传输偏移量改为该长度值，否则文件起始传输偏移量改为 0，表示从头开始传输。

OTA升级文件偏移（TUYA_BLE_OTA_FILE_OFFSET_REQ）

App->设备：

	data_len=5
长度：	1 字节	4 字节
Data：	0	Offset

offset：升级文件偏移量。

设备->App:

	data_len=5
长度：	1 字节	4 字节
Data：	0	Offset

offset：设备要求的起始传输文件偏移量。

实际文件传输的偏移地址应该以设备端要求的为准，且设备端要求的地址会小于等于 App端给出的偏移。

OTA升级数据（TUYA_BLE_OTA_DATA）

App->设备：

	data_len=7+n
长度：	1 字节	2 字节	2 字节	2 字节	n 字节
Data：	0	包号	当前包数据长度 n	当前包数据 CRC16	当前包数据

包号从 0 开始，高字节在前。

设备->App:

	data_len=2
长度：	1 字节	1 字节
Data：	0	STATE

STATE：

0x00：成功

0x01：包号异常

0x02：长度不一致。

0x03：crc检验失败

0x04：其它

OTA升级结束（TUYA_BLE_OTA_END）

App->设备：

	data_len=1
长度：	1 字节
Data：	0

设备->App:

	data_len=2
长度：	1 字节	1 字节
Data：	0	STATE

STATE：

0x00：成功

0x01：数据总长度错误

0x02: 数据总 CRC 检验失败

0x03: 其它

设备 OTA 文件验证成功后如果需要重启，通过调用API tuya_ble_ota_response(tuya_ble_ota_response_t *p_data) 响应给 App 结果至少无阻塞延时 2 秒后再重启。

OTA 案例参考

Application 通过注册的回调函数（无 RTOS 环境下）或者注册的接收队列（RTOS 环境下）接收 OTA 数据，EVENT ID 为 TUYA_BLE_CB_EVT_OTA_DATA，OTA 响应数据通过 tuya_ble_ota_response(tuya_ble_ota_response_t *p_data) 函数发送。

OTA相关数据结构

typedef enum 

{

​    TUYA_BLE_OTA_REQ,      //OTA升级请求指令

​    TUYA_BLE_OTA_FILE_INFO,    //OTA升级文件信息指令

​    TUYA_BLE_OTA_FILE_OFFSET_REQ, //OTA升级文件偏移量指令

​    TUYA_BLE_OTA_DATA,      //OTA升级数据指令

​    TUYA_BLE_OTA_END,      //OTA升级结束指令

​    TUYA_BLE_OTA_UNKONWN,

}tuya_ble_ota_data_type_t;

typedef struct{

​    tuya_ble_ota_data_type_t type;  

​    uint16_t data_len;

​    uint8_t *p_data;

}tuya_ble_ota_data_t;   //用户自定义OTA处理函数入参，包含ota升级指令事件、app下发的ota指令Data字段内容及数据长度

typedef struct{

​    tuya_ble_ota_data_type_t type;  

​    uint16_t data_len;

​    uint8_t *p_data;

}tuya_ble_ota_response_t;  // OTA响应数据发送函数tuya_ble_ota_response(tuya_ble_ota_response_t *p_data) 对应的数据结构

升级步骤

第一步：OTA 初始化，初始化获取升级文件相关信息以及 DFU 设置。（以 nordic nRF52832芯片为例）

注意：OTA 初始化函数需要在 SDK 初始化函数 tuya_ble_sdk_demo_init 后调用。

uint32_t tuya_ble_ota_init(void)
{
    s_old_file = (tuya_ble_ota_file_info_storage_t*)(s_dfu_settings.init_command);
    
    uint32_t ret = nrf_dfu_settings_init(true);
    
    APP_ERROR_CHECK(ret);
    
    return ret;
}

第二步：在注册的回调函数内，填写 TUYA_BLE_CB_EVT_OTA_DATA 事件，在该事件下调用自定义的 OTA 处理函数。

static void tuya_ble_sdk_callback(tuya_ble_cb_evt_param_t* event)
{
     switch(event->evt)
    {
        case TUYA_BLE_CB_EVT_OTA_DATA: {
            tuya_ble_ota_handler(&event->ota_data); //在OTA事件下添加自定义处理函数
        } break;


    ...
    }
}

第三步： tuya_ble_ota_handler() 函数内 ，在每个 OTA 指令下，按照上述的 OTA 交互协议，并结合设备实际逻辑，补充对应的处理函数。

void tuya_ble_ota_handler(tuya_ble_ota_data_t* ota)
{
    tuya_ble_ota_response_t rsp;
    
    rsp.type = ota->type;
    
    if(ota->type != TUYA_BLE_OTA_DATA) {
        TUYA_APP_LOG_INFO("ota_cmd_type: %d", ota->type);
        TUYA_APP_LOG_HEXDUMP_INFO("ota_cmd_data", ota->p_data, ota->data_len);
    }
    
    switch(ota->type)
    {
        case TUYA_BLE_OTA_REQ: //OTA升级请求指令
        {
            tuya_ble_ota_req_handler(ota->p_data, ota->data_len, &rsp);
        } break;
        
        case TUYA_BLE_OTA_FILE_INFO:  //OTA升级文件信息指令
        { 
            tuya_ble_ota_file_info_handler(ota->p_data, ota->data_len, &rsp);
        } break;
        
        case TUYA_BLE_OTA_FILE_OFFSET_REQ: //OTA升级文件偏移量指令
        {
            tuya_ble_ota_file_offset_handler(ota->p_data, ota->data_len, &rsp);
        } break;
        
        case TUYA_BLE_OTA_DATA: //OTA升级数据指令
         {
            tuya_ble_ota_data_handler(ota->p_data, ota->data_len, &rsp);
        } break;
        
        case TUYA_BLE_OTA_END:  //OTA升级结束指令
        {
            tuya_ble_ota_end_handler(ota->p_data, ota->data_len, &rsp);
        } break;
        
        case TUYA_BLE_OTA_UNKONWN: 
        {
        } break;
        
        default: {
        } break;
    }
}

完整案例参考

OTA 代码参考-nRf52832为例

开发者平台配置说明

创建固件

创建好产品后，在硬件开发中，选择对应的芯片或模组。点击新增自定义固件。

按照要求，填写带*的基本信息。

固件标识名：固件的标识名，在烧录授权时进行校验，需要和编译产生的固件名称保持一致，否则不能授权通过

固件类型：

1. 模组固件：WiFi sdk开发选用
2. MCU 固件：MCU 通用对接，用于升级 MCU 侧固件，MCU通用对接固件模组开发方式选用
3. 蓝牙固件：蓝牙 SDK 开发选用
4. zigbee固件：zigbee sdk开发选用
5. 拓展固件：设备需要单独管理附件固件（与设备应用程序不同）时选用，如 显示屏UI 资源

除了以上两个注意项，客户填写时需要注意，其它选项自定义修改，不知道该选项表示什么意思，可点击选项后面的”？“，查看说明

新增固件版本

新增固件升级

升级方式区别：

1. app提醒升级：用户点进app设备面板主动提醒用户有新版本升级，用户可选择是否升级
2. app强制升级：蓝牙连接就会强制升级，会主动推送升级通知给app用户，无选择是否升级权利，强制升级
3. app检测升级：不会主动推送升级提醒给app用户，需要用户主动发起版本检测，才能看到升级提醒

添加设备验证

点击验证，添加设备

将设备虚拟ID 填入，即完成该设备的 OTA 配置，再次进入设备面板便能收到 OTA 推送信息，进行 OTA 的升级测试。。

FAQ

• 设备虚拟id如何查找？
  答：点击面板右上角”🖊”状图标——》设备信息——》虚拟ID，复制即可。
  
  
  

• 添加设备时显示“设备不匹配当前产品PID”？
  答：设备虚拟id 对应的 PID 与开发者平台上创建的OTA升级固件所对应的 PID 不一致，请检查代码中所使用的 PID 和开发者平台创建的 OTA 升级固件所对应的 PID 是否一样。
  
  
  

• 添加设备时显示“设备不存在或被移除”？
  答：确认该设备所在使用地区，设备实际使用地区要和选择的服务器一致。若设备是在中国区使用，但是测试设备验证时，却选择了美西数据中心，美西数据中心由于数据隔离无法找到该设备相关信息则报错。