加上模组 OTA:APP 用 55AA 的 0x30~0x39 升级,MCU 和模组分开升。

- MCU 升级:模组只原样转发,不存 MCU 固件
- 模组自己升级:写到备用区,校验通过后再切过去,成功回 0x34,等 APP 回 0x35 再重启
- 升模组时先通知 MCU 先别上报;升的过程中不跑心跳、不处理普通控制
- 关掉原来的 JSON OTA,改走这条协议
This commit is contained in:
2026-08-20 16:12:08 +08:00
parent 7b7583668b
commit c0b5fcc4c5
23 changed files with 2700 additions and 446 deletions
+466
View File
@@ -0,0 +1,466 @@
# OTA升级流程
# 修订记录
|文档版本|日期|编写人|修订类型|修订内容|
|---|---|---|---|---|
|V1\.0\.0|2026\-07\-09|麦田|新建|首次发布OTA升级流程文档|
# APP获取设备版本
设备连接服务器后,主动上报当前版本给服务器,服务器进行维护。
服务器维护:
|**字段**|**说明**|
|---|---|
|固件类型|BLE / MCU |
|固件版本|当前版本号|
APP进入设备页面后,找服务器获取当前固件版本。
服务器返回:
```Plain Text
MCU固件
当前版本:V1.0.0
BLE固件
当前版本:V2.0.0
```
---
# 服务器推送OTA版本给APP
用户在服务器上传了bin文件,并填写了版本号和固件类型,点击发布。APP进入设备页面之后,服务器推送OTA文件信息给APP。
服务器推送:
```Plain Text
MCU固件
OTA版本:V1.2.0
长度:128KB
CRC320x12345678
BLE固件
OTA版本:V2.0.1
长度:256KB
CRC320x87654321
```
# APP进行版本比较
APP比较:
```Plain Text
OTA版本 VS 设备当前版本
```
例如:
|**固件**|**当前版本**|**OTA版本**|**是否升级**|
|---|---|---|---|
|MCU|V1\.0\.0|V1\.2\.0|是|
|BLE|V2\.0\.0|V2\.0\.1|是|
如果两个固件都需要升级:
升级顺序:
```Plain Text
第一步:MCU升级
第二步:BLE升级
```
避免 BLE 升级过程中影响 MCU OTA 通讯。
---
# APP通知BLE准备OTA
APP发送**OTA升级请求**告诉 BLE 本次升级目标。
例如升级 MCU
```Plain Text
Target:MCU
Firmware Version:V1.2.0
Payload Length:128KB
Payload CRC32:xxxx
```
---
# BLE判断升级目标
BLE收到:**OTA升级请求**
进行固件类型判断:
## 情况1:升级BLE
流程:
```Plain Text
APP
|
| OTA升级请求
|
BLE
|
| 自身检查
|
BLE返回准备结果
```
检查:
- Flash空间
- OTA状态
- 固件信息
返回:OTA请求应答
成功:
```Plain Text
Result = 0x00
Max Data Length = xxx
```
然后APP开始发送BLE Bin。
---
## 情况2:升级MCU
流程:
```Plain Text
APP
BLE
MCU
```
BLE收到后:
提取:
- Firmware Version
- Payload Length
- Payload CRC32
发送:
```Plain Text
BLE
|
| OTA升级请求
MCU
```
---
# MCU检查OTA条件
MCU收到升级请求。
检查:
1. 固件版本 :新版本 \> 当前版本
2. Flash空间
3. OTA状态 返回:OTA请求应答
结果:
|**Result**|含义|
|---|---|
|0x00|允许升级|
|0x20|无需升级(版本一致)|
|0x21|OTA 版本低于当前版本|
|0x22|Flash 空间不足|
|0x23|Bootloader 不支持|
|0x24|OTA 状态错误|
|0x25|固件类型不支持|
同时返回:
```Plain Text
Max Data Length
```
例如:
```Plain Text
512 Byte
```
---
# APP发送OTA Bin数据
APP按照:
```Plain Text
Max Data Length
```
进行分包。
例如:
MCU允许:
```Plain Text
512 Byte
```
发送:
```Plain Text
当前分包序号
总分包数
OTA数据
```
流程:
```Plain Text
APP
OTA_DATA
BLE
OTA_DATA
MCU
```
---
# MCU接收OTA数据
MCU每收到一包:
1. 校验数据包
2. 写入OTA区域
3. 累计接收长度
例如:
第一次:
```Plain Text
received = 512
```
第二次:
```Plain Text
received = 1024
```
直到:
```Plain Text
received == Payload Length
```
表示:
数据接收完成。
---
# OTA数据包应答
每包数据:
MCU返回:OTA数据应答
例如
成功:
```Plain Text
Result=0x00
```
失败:
```Plain Text
Result=错误码
```
如果失败:
BLE停止发送。
---
# MCU完成OTA校验
全部数据接收完成。
MCU
计算:CRC32
比较:CRC32 VS OTA升级请求中的CRC32
---
## 校验成功
MCU:保存升级信息。
返回:OTA\_RESULT
然后:重启。
---
## 校验失败
返回:OTA\_RESULT
错误码:
例如:
```Plain Text
CRC错误
```
---
# MCU通知BLE升级结果
MCU升级完成后主动发送:MCU OTA完成通知
协议:0x34
内容:
```Plain Text
OTA Result
MCU Version
```
BLE收到:添加上类型(0x01 MCU
上传APP。
---
# BLE通知APP升级结果
BLE发送:OTA完成通知
告诉APP
```Plain Text
MCU升级完成
版本:V1.2.0
结果:成功
```
---
# 如果BLE也需要升级
MCU升级成功后:
APP继续:
```Plain Text
Target = BLE
```
流程重新开始:
```Plain Text
APP
BLE
BLE自身OTA
```
完成后:
BLE通知:
```Plain Text
OTA成功
```
APP更新最终状态。
---
# 完整流程图
```Plain Text
云服务器
|
|
获取最新固件信息
|
APP比较版本,决定升级顺序
|
┌───────────┴───────────┐
│ │
MCU升级 BLE升级
│ │
OTA升级请求 OTA升级请求
│ │
▼ ▼
BLE BLE
│ │
│ 解包 ▼
▼ 自身准备
OTA升级请求
MCU
OTA请求应答
OTA数据
OTA数据应答
CRC校验
OTA_RESULT
MCU通知BLE
BLE通知APP
```