标签： fota

这两天在学习csdk系统，昨晚销售小哥给了一个链接：http://doc.openluat.com/article/1416/0 其中零妖大佬说了关于cat1 差分升级的事。

本着求实的精神，就很像知道确凿的证据，最好有代码或者数据的依据。

所以今天特意准备了下评估板子，看看能不能拿到些直观的线索。

第一个想到的就是通过coolwatcher追查系统的日志。这里有个开发板和我的usb uart小板电平不匹配的小插曲，定位此问题又额外浪费了点时间，暂不展开，如果有人想细究再补充，先说结论：想稳定看coolwatcher的日志，你需要使用host log的串口方式，而不是用usb方式。

测试使用的是官方的ota平台： iot.openluat.com ,设备初始代码是自己编译的测试包， ota包使用同样的代码，只是改了下版本号，因为主要是验证流程，所以不用关注功能逻辑。

fota包的下载使用的是http，注意是http，不是https，主要原因就是简单，https是趋势。

第一步：

通过http获取到文件大小，这里对应是的是Content-Length

[ota] HTTPClientFindFirstHeader 21,Content-Length: 48330

[ota]GetSize fsz: 48330

6M左右的原始bin档，实际的下载大小只有48K左右，这就说明下载的是差分，而不是全量包。

第二步：

ota_parse otaProcess file size 48320, type 1

从48330 变成了48320 说明有10byte可能是控制描述数据，不细表。

第三步：

[ota] HTTPClientReadData readSize 511

[ota] HTTPClientReadData readTotalLen 1022, 48330

每次下载511个字节，一包一包开始下载

第四步：

中间重复无数包，通过总包大小控制下载次数，直到最后一包下载完成

[ota]--HTTPIntrnConnectionClose--

ota_parse otaDownloadDone appState 3 CoreState 1

[ota_parse] FILE: app 48320 0

app应该是文件名，48320是大小，0 是属性或者权限之类的吧。

第五步：校验

ota_app crc (f7ddf30f,f7ddf30f)

ota openat_newApp appImageIsVaild ok

使用的应该是crc32 的校验的多包累加和，纯瞎猜，不求证

第六步：更新ota的标志

ota check 1,0

ota check 1,1

ota OPENAT_newOtaFlagSet 102

这个102应该就是告诉bootloader这个是刚ota完成，第一次需要做些特殊的工作。

第七步：下载完成

ota_parse _otaDownloadDone ok

[ota]fota end 0

看日志，整个升级48k大小的样子，花了6s完成，基本无感知，所以如果你用usb方式看日志，可能coolwatch还没连接上，升级就完成了