# 阿里云MCU OTA协议
日期 | 版本 | 说明 |
2020.7.20 | 1.0 | 初次发布 |
2020.9.17 | 1.1 | 删除0x33的mcu响应指令 新增0x34指令 |
2020.10.12 | 1.2 | MCU收到 0x34 指令后，需要延时 200ms 进入Ymodem |
2020.12.30 | 1.3 | 1 增加WiFi 固件OTA时的通知指令 2 增加MCU查询MCU OTA固件的版本、长度、MD5 |
2021.1.6 | 1.4 | 1 增加MCU OTA示例 2 增加 MCU OTA 的版本、长度MD5的通知指令 |
2021.9.3 | 1.5 | 1 删除33指令 |
2022.9.19 | 1.6 | mcu版本号可以自定义 |
#MCU OTA 指令集
#获取MCU固件版本号
WiFi->MCU
CMD | PAYLOAD | 说明 |
0x31 | 0x00 | 预留 |
MCU->WiFi
无
#上报MCU固件版本号
MCU->WiFi
CMD | PAYLOAD | 说明 |
0x32 | n bytes (string) | MCU固件版本号； 最大值32 |
WiFi->MCU
CMD | PAYLOAD | 说明 |
0x32 | 0x00 | MCU固件版本号设置成功 |
0x01 | MCU固件版本号设置失败 |
mcu 版本号，必须是 xxxx-abc****
- xxxx 不能包含 - ；将会成为 mcu ota时的模块名称
- abc 必须是数字 0～9
- 例如：stm32f215-100
#MCU请求开始固件升级
MCU->WiFi
CMD | PAYLOAD | 说明 |
0x34 | 0x00 | 进入MCU OTA模式，128字节 |
0x01 | 进入MCU OTA模式，1024字节 |
WiFi->MCU
CMD | PAYLOAD | 说明 |
0x34 | 0x00 | WiFi模组进入Ymodem模式成功 |
0x01 | WiFi模组进入Ymodem模式失败 |
#MCU查询MCU OTA固件版本
MCU->WiFi
CMD | PAYLOAD | 说明 |
0x35 | 0x00 | 查询MCU OTA固件版本信息 |
WiFi->MCU
CMD | PAYLOAD | 说明 |
0x35 | 0x00 | 没有MCU OTA固件 |
n bytes | json 字符串格式，后续会扩展 |
该指令可以在指令模式下任意时间发送。 json格式：
{
"fw_ver": "mcu-101",
"fw_len": 886864,
"fw_md5": "8E8DD18D6B4C1006A0BB57EFCFD41874"
} #通知MCU开始WiFi模组自身固件升级
WiFi->MCU
CMD | PAYLOAD | 说明 |
0x36 | n bytes（string） | 设备当前WiFi固件版本号（OTA之前的版本） |
MCU->WiFi
无
该指令说明，固件已经下载完成，并且校验正确，模组将重启启动，开始模组自身的更新，持续时间20s~30s不等。
#通知MCU OTA的版本、长度、MD5
WiFi->MCU
CMD | PAYLOAD | 说明 |
0x37 | n bytes | json 字符串格式，后续会扩展 |
MCU->WiFi
无
该指令的数据格式与0x35指令的数据格式一致
#升级流程
#流程说明
- WiFi模组接收到云端下发的 MCU OTA 升级指令
- WiFi模组下载固件并校验固件完整性
- WiFi模组发送通知MCU开启固件升级的指令
- MCU请求WiFi模组进入Ymode模式，
- WIFI响应请求应答，如果检查到WiFi模组中存在MCU固件，WiFi模组进入 Ymodem 模式， WiFi模组关闭所有串口指令，MCU端延时 200ms 后，再进入Ymodem模式
- MCU与WiFi模组通过 Ymodem 协议，传输 mcu 的ota 固件，固件传输完成后，WiFi模组打开所有串口指令
- MCU OTA成功后，发送 重启指令
- WiFi模组应答指令
- 重启模组
- 模组通过获取MCU固件版本号指令，请求MCU固件版本号
- MCU通知上报MCU固件版本号指令，上报MCU固件版本号
- WiFi模组应答指令
- WiFi模组向云端上报MCU固件版本号
#升级要求
- MCU应用程序必须要有bootloader模式
- bootloader必须支持Ymodem协议
- OTA固件必须包含完整性校验
- MCU应用程序应该在适当的时候上报版本号，一是在WiFi请求mcu版本时；二是在mcu升级成功后
- MCU可以在模组启动初期上报版本号
- 如果模组在发送请求固件版本号之前收到了MCU上报的固件版本，模组将不再发送请求MCU固件版本号指令
#Ymodem 协议
Ymodem协议是由XModem协议演变而来的，每包数据可以达到1024字节，是一个非常高效的文件传输协议。
YModem-1K用1024字节信息块传输取代标准的128字节传输，数据的发送会使用CRC校验，保证数据传输的正确性。它每传输一个信息块数据时，就会等待接收端回应ACK信号，接收到回应后，才会继续传输下一个信息块，保证数据已经全部接收。
Ymodem支持128字节和1024字节一个数据包。128字节以（SOH）开始，1024字节以（STX）开始。
1.起始帧的数据格式
YModem的起始帧并不直接传输文件的数据，而是将文件名与文件的大小放在数据帧中传输，它的帧长=3字节数据首部+128字节数据+2字节CRC16校验码=133字节。它的数据结构如下：
SOH 00 FF filename filezise NUL CRCH CRCL
其中SOH=0x01，表示这个数据帧中包含着128个字节的数据（STX表示1024字节，初始帧只有128个），00表示数据帧序号，初始是0，依次向下排，FF是帧序号的取反，filename是要传输的文件名，如USTB_V3_1.0.1.26_NMEA.Bin，它在数据帧中的格式为：55 53 54 42 5F 56 33 5F 31 2E 30 2E 31 2E 32 36 5F 4E 4D 45 41 2E 42 69 6E 00，也就是把ASCII码转成十六进制，但是最后一定要在文件名后加上00，表示文件名的结束；filesize表示文件的大小，如上面的USTB_V3_1.0.1.26_NMEA.Bin大小是132KB，也就是135168Byte，它在数据帧中的格式就是31 33 35 31 36 38 ，也就是ASCII的“135168”，同样最后要加上00表示结束，NUL就是数据部分的128字节中除去文件名和文件大小占据的剩下的字节都用00填充，CRCH和CRCL分别表示16位CRC校验码的高8位与低8位。
2.数据帧的数据格式
YModem的数据帧中会预留1024字节空间用来传输文件数据，它跟起始帧接收差不多，如下：
STX 01 FEdata[1024] CRCH CRCL
其中STX=0x02，表示这帧数据帧后面包含着1024字节的数据部分；01是表示帧序号，FE是它的取反，再下一帧数据就是02 FD，以此类推；data[1024]表示存放着1024字节的文件数据；CRCH与CRCL是CRC16检验码的高8位与低8位。
如果文件数据的最后剩余的数据在128~1024之间，则是使用SOH的128字节传输，
有一种特殊的情况：如果数据不满128字节，剩余的数据用0x1A填充这是数据帧的结构就变成了：
文件大小小于128字节
SOH 01 FE data[ ] 1A ...1A CRCH CRCL
文件最后剩余数据小于128字节
SOH 01 FE data[ ] 1A...1A CRCH CRCL
3.结束帧数据结构
YModem的结束帧数据也采用SOH的128字节数据帧，它的结构如下：
SOH 00 FF NUL[128] CRCH CRCL
结束帧同样以SOH开头，表示后面跟着128字节大小的数据；结束帧的帧序也认为是00 FF；结束帧的128字节的数据部分不存放任何信息，即全部用00填充。
#示例
以 128字节为一个数据包的Ymodem例。数据交互以MCU为视角，OTA数据包大小为 656 bytes。
Phase Data Description ----- -------------------------------------------------------------- ------------ OUT c0 34 00 00 d0 MCU 请求开启 MCU OTA IN c0 34 00 00 d0 WiFi 响应 MCU 成功 OUT 43 C IN 01 00 ff 6d 63 75 2d 31 30 31 00 36 35 36 00 00 ... CRC16 文件名:mcu-101 ;长度:656 OUT 06 ACK OUT 43 C IN 01 01 fe 31 32 33 34 35 36 37 38 39 30 31 32 33 ... CRC16 128 Data OUT 06 ACK IN 01 02 fd 37 38 39 30 31 32 33 34 35 36 37 38 39 ... CRC16 128 Data OUT 06 ACK IN 01 03 fc 31 32 33 34 35 36 37 38 39 30 31 32 33 ... CRC16 128 Data OUT 06 ACK IN 01 04 fb 37 38 39 30 31 32 33 34 35 36 37 38 39 ... CRC16 128 Data OUT 06 ACK IN 01 05 fa 31 32 33 34 35 36 37 38 39 30 31 32 33 ... CRC16 128 Data OUT 06 ACK IN 01 06 f9 37 38 39 30 31 32 33 34 35 36 37 38 39 ... CRC16 128 Data OUT 06 ACK IN 04 EOT OUT 15 NAK IN 04 EOT OUT 06 ACK OUT 43 C IN 01 00 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 ... CRC16 结束包 OUT 06 ACK
通过 Bus Hound 抓包，完整的交互流程如下图。
