-------------------------------------------
OTA包
OTA 包生成环境
OTA 包格式
镜像描述文件
Update.xml 文件描述了包括待升级的镜像的信息，下面是一个具体示例。
loader.bin 和分区表
分区表数据结构说明：
分区数据结构说明：
3. offset: 分区在 Flash 上的偏移地址。
4. seq: 用于区分同类型分区。OTA 升级时会选择 seq 值较小 的分区进行升级。
-------------------------------------------
OTA 流程
-------------------------------------------
OTA 升级流程
为了简化小机端代码逻辑，将更多的如何选择分区，如何调整分区大小等复 杂的逻辑留在在移动端。
移动端：
A/B 备份机制
A/B 备份机制指存在 2 个相同类型的分区。
第二次进行 OTA 时，移动端读取分区表后会发现此时 seq 值较小的是 A 分 区，所以会选择 A 分区进行升级。
OTA 完成后启动流程
• brom 引导 loader：
OTA 过程不会擦除当前运行的 SYSTEM_TYPE 分区，所以可能会有 两份正确的 app 镜像同时存在的情况。loader 会尝试读取 2 份 app 镜 像。如果 2 份镜像都通过检验，选择其中 seq 值较大的镜像加载运行。
-------------------------------------------
OTA包
-------------------------------------------
• 安装 python 2.7.15 版本
• 拷贝\scripts\utils\dd-0.6beta3 到与源码目录无关的路径。例如：C:\
• pc 的 环 境 变 量-系 统 变 量-Path 中 添 加 python 和 dd 的 路 径。 例 如： ;C:\Python27;C:\dd-0.6beta3
OTA 包生成
运 行\samples\voice_rcu\build.bat 后，outdir 目 录 下 会 生 成 zs110a_*_ota.zip 文件。
OTA 包格式
OTA 包是一个 zip 格式的压缩文件。解压后的目录由一个 OTA 镜像描述 文件和多个镜像文件组成。
以遥控器方案为例，OTA 包解压后包含以下文件：
• 镜像描述文件：Update.xml
• loader 分区镜像文件：loader.bin
• 应用分区镜像文件：rcu.bin
镜像描述文件
Update.xml 文件描述了包括待升级的镜像的信息，下面是一个具体示例。
说明：
1. 格式必须符合标准 XML。
1. 格式必须符合标准 XML。
2. version: 描述版本号。
3. partitionsNum：描述分区的数目。
4. partition：描 述 一 个 分 区 的 信 息， 其 各 个 字 段 由\samples\voice_rcu\firmware.xml 的 模 板 定 义， 建 议 不 要 自 行 修改改字段的模板定义。
• type：描述该镜像的类型，合法值包括“BOOT”，“SYSTEM”等。
• name：由打包脚本自动生成。
• file：烧写到该分区的镜像文件名。
• address：分区在 Flash 上的地址。
• fw_id：镜像 ID。
• crc32：描述镜像文件的 crc32 校验和。
loader.bin 和分区表
• 默认 loader 分区为 4KBytes。
• ota 包中的 loader.bin 是由 loader 工程生成的 loader.bin（<3KBytes）和分区表 组合而成。分区表位于 3KBytes 偏移处。
• 分区表的数据结构如下：
分区表数据结构说明：
1. magic: 0x54504341 // ‘ACPT’
2. version: 默认为 0x0000
3. table_size: 分区表的总大小 =16+360+4+4=384 Bytes
4. part_cnt: 实际的分区数
5. part_entry_size: 一个分区的数据结构大小
6. parts[MAX_PARTITION_COUNT]: 预留了 15 个分区的数据结构
7. table_crc：整个分区表的 crc 校验和。 单个分区的结构
分区数据结构说明：
1. name: 分区名。
2. type: 分区类型。
3. offset: 分区在 Flash 上的偏移地址。
4. seq: 用于区分同类型分区。OTA 升级时会选择 seq 值较小 的分区进行升级。
-------------------------------------------
OTA 流程
-------------------------------------------
OTA 升级流程
为了简化小机端代码逻辑，将更多的如何选择分区，如何调整分区大小等复 杂的逻辑留在在移动端。
双方具体分工和协作方式如下
小机端：
• 提供小机的分区表信息及版本号。
• 实现分区读写和校验的功能。
• 实现重启的功能。
移动端：
• 解析 ota 包获取版本号，获取小机端版本号，对比后判断是否需要 升级。
• 解析 ota 包内的分区镜像文件，获取小机端的分区信息，选择正确 的分区来进行升级。
• 选择备用的 app 分区升级 app 镜像。
• 选择备用 loader 分区升级 loader 镜像（包含更新分区信息），并擦 除当前的 loader 分区。
具体流程如下图所示：
A/B 备份机制
A/B 备份机制指存在 2 个相同类型的分区。
以遥控器方案为例：定义了 2 个 BOOT_TYPE 分区和 2 个 SYSTEM_TYPE 分区。
初始版本的分区表中：A 份分区的 seq=0，B 份分区的 seq=-1。
第一次进行 OTA 时，移动端读取到分区表后，会选择 seq 值较小的 B 分区 进行升级，升级完成会修改 seq_B。seq_B=seq_A+1。
第二次进行 OTA 时，移动端读取分区表后会发现此时 seq 值较小的是 A 分 区，所以会选择 A 分区进行升级。
OTA 完成后启动流程
• brom 引导 loader：
OTA 过程中会檫除当前运行的 BOOT_TYPE 分区，所以正常情况下 brom 也只能引导升级后新的 loader。如果 A/B 同时存在，brom 会优 先引导 A 份。
• loader 引导 app：
OTA 过程不会擦除当前运行的 SYSTEM_TYPE 分区，所以可能会有 两份正确的 app 镜像同时存在的情况。loader 会尝试读取 2 份 app 镜 像。如果 2 份镜像都通过检验，选择其中 seq 值较大的镜像加载运行。
-------------------------------------------
OTA Profile
-------------------------------------------
Ota profile 定义了 4 个属性：
• File Transfer Control Characteristic（FTC）：用于 OTA 固件的读和写控制。
• File Transfer Data Characteristic（FTD）：用于 OTA 固件读和写，以保证传送速 率。
• Authentication Characteristic（AU）：用于保证 OTA 升级必须是在移动端和小机 端协商同意才允许升级。
• Device Configuration（DC）：用于配置和获取一些 BLE 参数，如连接间隔、MTU 等。
传送控制属性-File Transfer Control Characteristic
FTC 用于控制命令的发送和应答。
FTC 命 令 控 制 要 求 采 取 同 步 应 答 方 法， 除 WDXS_FTC_OP_PACKET_RECEIVED 响 应 方 式 为 异 常 应 答 方 式。
WDXS_FTC_OP_PACKET_RECEIVED 设主要用移动端 APP 的传送和 设备端计数同步，为了提高 BLE 的传送效率，
当前设计为设备端 CPU 稍 有空闲时，就将接收到固件大小数据反馈给移动端，同时保证最后一个包的 数据统计信息必须反馈给移动端。
FTC 有如下传输控制命令：
• OTA_FTC_OP_GET_REQ
• OTA_FTC_OP_GET_RSP
• OTA_FTC_OP_GET_RSP
• OTA_FTC_OP_PUT_REQ
• OTA_FTC_OP_PUT_RSP
• OTA_FTC_OP_PUT_RSP
• OTA_FTC_OP_ERASE_REQ
• OTA_FTC_OP_ERASE_RSP
• OTA_FTC_OP_VERIFY_REQ
• OTA_FTC_OP_VERIFY_RSP
• OTA_FTC_OP_SYSTEM_RESET
• OTA_FTC_OP_GET_VERSION_REQ
• OTA_FTC_OP_GET_VERSION_RSP
• OTA_FTC_OP_ERASE_RSP
• OTA_FTC_OP_VERIFY_REQ
• OTA_FTC_OP_VERIFY_RSP
• OTA_FTC_OP_SYSTEM_RESET
• OTA_FTC_OP_GET_VERSION_REQ
• OTA_FTC_OP_GET_VERSION_RSP
数据传送属性-File Transfer Data Characteristic
ftd 用于数据文件的传送，通常都是裸的读写数据
授权认证属性-Authentication Characteristic
暂无
设备配置属性-Device Configuration
一个可读可写可通知的 ATT 属性用于支持 OTA 相关配置，如连接参数配 置、安全连接配置、连接断开配置、MTU 配置、电池 Level 配置等。
当前 OTA 和应用设计在同一固件中，相关配置已经在应用中配置，该属性 节点没有添加相关接口。
-------------------------------------------
OTA 交互过程
-------------------------------------------
-------------------------------------------
移动端与设备进行 OTA 大致过程为：
1. 移动端获取设备端的信息确认是否需要升级，如获取电量信息、获取设备固件版 本信息。
2. 移动端获取设备端的分区表，确认需要升级固件的升级地址。
3. 按照下列操作步骤，循环升级完 OTA 包中的每个 bin。
• 移动端发送 put 请求，告诉设备端 xxx.bin 的升级地址及长度
• 设备端回复 put 应答，告诉移动端已经准备好。
• 移动端将 xxx.bin 切分多个 data 包（大小跟 mtu 一致），然后发送给设 备端
• 设备端收到数据包后，将数据写到 flash，同时进行计数，并发送一个消 息给 Main 线程，Main 线程在空闲时将包计数回复给移动端，用于更新 进度条。
• 设备端将 xxx.bin 接收完后，发送 EOF 给移动端
• 移动端收到 EOF 后，发送 verify 给设备端。
• 设备端将 xxx.bin 进行校验，校验成功，回复 verify 应答。
4. 升级包中所有 bin 升级完后，移动端发送檫除命令给设备端，设备檫除完后，回 复檫除操作应答。
5. 移动端发送重启命令给设备端，让设备端进行重启。
评论