阅读导航#

1. 杰理 AC79 应用启动与注册机制详解：从 REGISTER_APPLICATION 到 start_app
2. paipopAi 对话玩具解析（一）：从 APP_STA_START 到眼睛任务与摇一摇服务
3. paipopAi 对话玩具解析（二）：从按键与摇一摇到对话打断
4. paipopAi 对话玩具解析（三）：从按键启动到云端语音回答
5. paipopAi 对话玩具解析（四）：PaipopSDK 如何封装 LingXinSDK
6. paipopAi 对话玩具解析（五）：AI 播放时如何实现自然语音打断
7. paipopAi 对话玩具解析（六）：从开机联网到 AP 网页配网
8. 本文：从版本检查、双备份写入到重启确认。
9. paipopAi 对话玩具解析（八）：本地音量与云端动作指令

本文范围与证据边界#

本文基于正式工程 Paipop_YP_Toy 的 main@24a83f9，产品版本为 V1.2.8 / 10208，目标平台为杰理 AC791N/WL82，分区身份为 8MB_dual_bank_paipop_v1。

本次做的是静态源码与构建配置复核，没有重新烧录硬件、抓取 HTTPS 报文或执行断电破坏测试。因此结论需要分层：

本文不会展示真实设备身份、App Key、签名、领取 Token 或带鉴权参数的下载 URL。当前配置中仍有联调固定值和允许 HTTP 的测试开关，这是需要整改的工程事实，不应复制到公开文章或量产固件。

一、先画出完整生命周期#

一次 OTA 横跨两次启动：

1
旧固件本次启动
2
  → DHCP成功
3
  → 网络与业务连续稳定3秒
4
  → 准备或读取OTA凭据
5
  → HMAC鉴权检查更新
6
  → 校验升级任务
7
  → 流式下载并写入非活动区
8
  → 校验长度与SHA-256
9
  → 保存pending记录
10
  → 正常关闭升级流，底层安排切换和复位
11

12
新固件下次启动
13
  → DHCP成功并再次进入OTA任务
14
  → 读取pending记录
15
  → 比较目标version_code与当前编译版本
16
  → 上报success或boot_not_target
17
  → 后台接受后清除pending

所以，“下载进度 100%”最多表示字节接收完毕，绝不等于升级成功。真正的成功至少要跨过内容校验、升级模块收尾、启动槽切换、新固件启动和结果上报五个边界。

二、三个模块怎样分工#

当前 OTA 不是一个大函数，而是三个第一方模块协作：

再往下，httpcli、net_update、双备份写入任务和 Bootloader 属于杰理平台边界；眼睛、按键、摇一摇和 FSM 属于产品协作边界。

这种拆分让协议变化不必侵入 Flash 状态机，也让玩具交互规则不必知道 HMAC 和 JSON 字段。

三、paipop_ota_init() 为什么不检查更新#

应用启动时调用：

1
paipop_ota_init();

它只清理控制结构、设置初始化标志并打印版本，不访问网络。真正的启动信号来自 Wi-Fi DHCP 成功后的：

1
paipop_ota_network_ready();

check_started 保证一次开机只创建一个 OTA 检查线程。网络反复断开、重连不会不断创建重复线程；network_ready 只是实时条件，线程内部会等待它恢复。

这两个变量不能混为一谈：

1
check_started：本次启动是否已经创建过工作线程
2
network_ready：当前网络是否仍然满足运行条件

网络断开或模块反初始化时，如果存在活动 HTTP，代码调用 http_ops.quit() 主动打断阻塞读取。否则线程可能一直卡在网络栈内部，无法及时释放升级资源。

四、为什么不是固定延时，而是连续稳定 3 秒#

旧实现可以用“联网后睡眠若干秒”给系统让路；当前 V1.2.8 改成了更精确的稳定窗口。

OTA 只有同时满足以下条件，才开始累计稳定时间：

1
network_ready == true
2
Wi-Fi状态 == DHCP_SUCC
3
FSM状态 == ENGINE_EXIT 或 ENGINE_INIT_FAILED
4
当前没有提示音播放

四项条件连续成立 3000 ms 才通过。任何一项失效，stable_since 都会清零重新计算。

这与简单的 msleep(3000) 有本质区别：

1
简单睡眠：三秒后继续，不关心期间是否断网或进入对话
2
稳定窗口：条件必须在整段三秒内持续为真

ENGINE_EXIT 在这个项目里表示语音引擎已退出本轮活动、设备等待下一次触发，不是程序异常退出。ENGINE_INIT_FAILED 允许云端对话暂时不可用时仍然修复固件。

检查更新阶段并不设置 ota.busy，用户仍可触发正常交互；如果状态变化，OTA 会重新等待空闲。只有真正开始下载和写入后才置 busy，缩短对产品功能的冻结时间。

五、凭据为什么有三条来源#

OTA 后台凭据与 PaipopSDK 的 PaipopKey 是两套系统，不能混用。当前加载顺序可以概括为：

1
编译配置中存在App Key
2
  → 直接使用
3

4
否则读取专用VM记录
5
  → 有效则使用
6

7
否则使用一次性provision token领取
8
  → 保存VM
9
  → 立即读回比对

首次领取最多尝试三次，间隔是 0、10 秒和 60 秒；只有网络、超时等可恢复错误才继续，明显的参数或认证错误会提前停止。

VM 记录包含：

1
magic + schema + length
2
设备SN的SHA-256摘要
3
base_url + app_id + app_key + key_version
4
CRC32

设备摘要用于防止一台设备误读另一身份的记录，CRC32 用于发现掉电或存储损坏。写入后再次加载，并比对 App Key 与 Key Version，形成“写入—读回—验证”闭环。

但要说清安全边界：CRC32 不是消息认证码，VM 也不是安全芯片。它们能发现随机损坏，不能防止有能力读取或改写 Flash 的攻击者。量产方案应使用每台设备独立密钥、安全存储、调试口保护和服务端撤销机制。

六、HMAC 请求是怎样生成的#

检查和状态上报都使用带签名的 POST。设备先保证系统时间不早于合理纪元；时间无效时启动独立 NTP 任务，最多等待 15 秒，每 200 ms 轮询一次。

随后把三个字段分别做 RFC 3986 百分号编码，并按固定次序构造规范串：

1
app_id=<encoded>&sn=<encoded>&timestamp=<encoded>

签名计算为：

1
digest = HMAC-SHA256(app_key, canonical_string)
2
signature = Base64(digest)

请求头携带 app_id、设备身份、毫秒时间戳、签名和 key_version。App Key 本身不会通过网络发送。服务端用同一密钥重算并比较，时间戳则可用于限制重放窗口。

实现还有两类输入防护：

• 头字段拒绝 CR、LF、控制字符，避免请求头注入；
• URL 拒绝换行、#、@、localhost 和 127.0.0.1，限制明显的解析歧义和本地回环目标。

不过 HMAC 只证明“请求方掌握密钥、签名字段未被改动”，不加密通信，也不自动验证响应服务器身份。因此量产环境仍必须使用 HTTPS 并校验证书。当前源码允许 HTTP 的宏只能属于受控联调配置。

七、检查更新到底上传了什么#

设备调用 OTA check 接口时，上送：

1
device_unique_id
2
hardware_model
3
board
4
current_version / current_version_code
5
partition_layout
6
battery_percent / charging
7
wifi_rssi

这些字段服务于三个目标：身份定位、固件兼容性匹配和发布策略判断。

版本名是给人看的，真正用于单调升级判断的是整数 version_code。硬件型号、板型和分区布局则防止把“同名版本”的错误二进制发给不兼容设备。

充电或外部供电场景会把有效电量按 100% 报告，避免 USB 联调机因电池采样被后台误拦截；普通电池读数会限制在 0～100。

响应不是看到 JSON 就接受。协议层要求：

• HTTP 为 2xx，业务 code == 200，data 必须是对象；
• has_update 必须是布尔值；
• 有更新时，Task ID、Firmware ID、目标版本、下载 URL、过期时间、大小和 SHA-256 都必须存在且类型正确；
• version_code 必须是无小数的合法 32 位整数；
• 过期时间必须是 JavaScript 安全整数范围内的非负整数；
• SHA-256 必须恰好是 64 个十六进制字符。

这种严格解析很重要。嵌入式 C 代码不应把服务端响应当成天然可信输入。

八、协议解析通过后，为什么还要本地二次校验#

协议层只验证“响应格式成立”；业务层还要判断“当前设备现在是否应该执行”。paipop_ota_validate_offer() 会继续检查：

1
任务ID、版本、URL、大小和SHA-256有效
2
target_version_code > 当前version_code
3
下载URL不是即将过期
4
电量 >= 30%
5
Wi-Fi RSSI >= -75 dBm

如果设备时间有效，URL 至少还要剩 30 秒；下载前会再次检查，避免排队等待后拿着已经失效的临时 URL 开始写 Flash。

这体现两层校验：

1
协议校验：这个响应能否被安全解析？
2
业务校验：这个任务是否适用于此设备、此时刻？

后台策略是第一道门，本地硬门槛是最后一道门。即使后台误配，低版本覆盖高版本、低电量升级或弱信号下载也应在设备侧被拒绝。

九、检查与下载怎样重试#

检查更新最多三轮，计划延时为：

1
立即、60秒、300秒

但不是所有结果都重试：命中更新、明确无更新、凭据不可用或认证失败都会结束本轮；只有其余瞬态错误进入下一轮。每一轮之前都重新等待网络和业务稳定。

下载最多尝试两次，失败间隔 2 秒。若临时 URL 已过期，代码最多重新 check 一次获取新任务信息，并重新上报 detected/confirmed，而不是无限刷新。

这是“有限重试”而不是“失败就死循环”。量产设备若无退避地持续请求，服务端故障时会形成惊群和自我放大流量。

十、4 KiB 流式下载怎样工作#

下载缓冲区为：

1
#define PAIPOP_OTA_DOWNLOAD_BUF_SIZE (4 * 1024)

核心循环可以抽象成：

1
HTTP读取最多4 KiB
2
  → 检查累计长度不能超过offer.size
3
  → SHA-256上下文累计update
4
  → net_fwrite写入升级流
5
  → 检查返回长度必须等于输入长度
6
  → 更新进度与眼睛显示

因此 RAM 占用与固件总大小基本解耦。设备不需要先把整个 OTA 包放进内存，也不需要普通文件系统作为中转。

开始写入前还要求：

1
HTTP状态码 == 200
2
响应头存在
3
Content-Length == offer.size

结束时再次要求：

1
downloaded == offer.size
2
计算所得SHA-256 == 后台摘要

前面的 Content-Length 检查防止明显错误，后面的实际计数防止连接提前结束，SHA-256 防止内容变化。三者解决的是不同故障，不能相互替代。

十一、net_fopen() 不是普通文件写入#

代码使用：

1
update_fd = net_fopen(CONFIG_UPGRADE_OTA_FILE_NAME, "w");
2
net_fwrite(update_fd, data, len, 0);

这里的“文件”是杰理网络升级模块暴露的虚拟写入口。数据继续流向双备份升级任务，写到非活动固件区域，而不是创建一个常规磁盘文件。

工程同时满足几个构建条件：

• CONFIG_DOUBLE_BANK_ENABLE 已开启；
• Paipop OTA 三个源文件进入目标 Makefile；
• 公共升级代码和 update、dw_update 任务进入最终程序；
• 完整 USB 基线使用 8 MB 双备份布局；
• 后台上传版本化的 db_update_files_data_<版本>.bin，而不是把 jl_isd.fw 与 OTA 包混用。

单备份设备不能靠一次应用 OTA 凭空变成双备份布局。分区变更必须先通过完整 USB 烧录建立正确基线。

当前工程还在 Flash 尾部保留独立音频资源区域。不能仅凭 Firmware OTA 成功就假设所有外部资源一定同步更新；资源是否进入升级包必须以打包清单和实机验证为准。

十二、ota.busy 怎样保护产品交互#

真正下载开始时：

1
ota.busy = 1;
2
paipop_fsm_cancel_push_to_talk();
3
paipop_eye_ota_begin();

按键、摇一摇、FSM 和眼睛服务都会查询 paipop_ota_is_busy()：

• 新的对话触发被拦截；
• 摇晃打断不再启动另一条语音链；
• 普通随机眼睛动作暂停；
• OTA 十段式进度覆盖普通状态图标。

眼睛显示按 10% 粒度更新，而后台状态上报携带实际进度。显示层不需要为每个数据块刷新 LCD，协议层仍能获得更准确的遥测。

失败路径会关闭升级流并传入 abort 标志、释放 SHA 上下文和 4 KiB 缓冲、清除 busy、恢复眼睛。成功路径故意不清 busy，因为设备已经进入“等待底层复位”的不可交互阶段。

十三、为什么必须先保存 pending，再正常关闭升级流#

下载和哈希都通过后，顺序是：

1
保存pending记录
2
→ 上报downloaded
3
→ net_fclose(update_fd, 0)
4
→ 底层完成镜像收尾、启动信息更新并安排复位

pending 记录包含目标版本号、目标版本名、Task ID、总字节数、阶段、magic、schema 和校验值。

其校验是一个类似 FNV-1a 的 32 位非加密校验，只用于识别随机损坏，不应描述成数字签名或防篡改机制。

为什么 pending 必须在切换前落盘？因为复位之后，原进程的 RAM 全部消失。若先触发切换再写记录，设备可能已经重启，却没有任何持久状态告诉新固件“上一轮任务是谁、目标是什么、结果应上报给谁”。

如果 pending 保存失败，本次升级直接失败，不进入启动切换。

net_fclose(fd, 0) 的 0 表示正常完成；失败时使用 net_fclose(fd, 1) 中止。玩具层成功后不再主动调用 system_reset()，避免在底层尚未完成镜像校验或启动信息写入时抢先复位。

十四、新固件如何完成跨重启确认#

下一次启动、联网并稳定后，OTA 线程先处理 pending，再检查新任务。

判断规则很直接：

1
pending.target_version_code == 当前编译version_code
2
  → 上报success
3

4
否则
5
  → 上报failed / boot_not_target

只有状态接口返回并确认 accepted == true，设备才清除 pending。上报时断网，记录会继续存在，下次启动或重新进入流程时还能补报。

这里需要避免过度解读：版本不匹配只能证明“当前没有运行目标版本”，可能是切换失败、底层拒绝镜像或其他启动路径。应用层没有读到一个权威的 Bootloader rollback reason，因此不会武断上报 rollback。

这正是证据边界意识：有 ROLLBACK 枚举，不代表当前代码已经能可靠识别所有回滚。

十五、三种完整性机制不要混淆#

成熟量产链路还应增加：

1
HTTPS与证书校验
2
发布私钥签名固件摘要
3
设备内置公钥验签
4
Bootloader安全启动
5
新固件试运行与健康确认
6
失败阈值触发自动回滚

一句面试表达是：

双备份解决可恢复性，哈希解决传输完整性，HMAC解决设备请求认证；固件来源真实性要靠非对称数字签名，启动阶段的持续可信还要靠安全启动和可确认回滚。

十六、状态上报为什么不只是日志#

设备会沿生命周期上报：

1
detected
2
→ confirmed
3
→ downloading
4
→ downloaded
5
→ success / failed

上报包含 Task ID、目标版本、当前版本、进度、下载字节数、总大小和稳定错误码。Task ID 标识一次发布任务，Firmware ID 标识固件实体，Key Version 标识认证密钥版本，三者职责不同。

进度上报失败不会中断一份仍在安全下载的镜像，否则短暂的遥测故障反而会放大成升级失败。相反，pending 保存失败会阻止切换，因为它影响跨重启结果闭环。

这是“控制面”和“数据面”的取舍：进度遥测可以暂时丢失，固件内容和启动状态不能含糊。

十七、异常路径逐个追问#

十八、怎样测试这套 OTA#

至少准备旧版本完整 USB 基线和版本号更高的 OTA 目标包。后台硬件型号、板型、分区布局、文件大小和 SHA-256 必须与目标产物一致。

正常用例：

1
旧版本启动
2
→ DHCP成功
3
→ 空闲稳定3秒
4
→ check命中新版本
5
→ detected/confirmed/downloading/downloaded
6
→ 自动复位
7
→ 启动日志显示目标version_code
8
→ 联网后上报success

异常矩阵至少覆盖：

还要做长时间与批量测试：连续 A/B 槽往返升级、Flash 擦写寿命、弱网抖动、NTP 失败、看门狗复位、多个版本跨越和后台灰度暂停。

十九、当前实现仍有哪些量产差距#

二十、面试官高频追问#

总结#

Paipop OTA 可以分成七层：

1
业务门控层
2
DHCP + FSM空闲 + 提示音结束 + 连续稳定3秒
3

4
身份认证层
5
凭据领取/VM + NTP + HMAC-SHA256
6

7
发布策略层
8
硬件/板型/布局/版本/电量/RSSI
9

10
传输校验层
11
HTTP状态 + Content-Length + 实际字节数 + SHA-256
12

13
平台写入层
14
net_update + 4 KiB流式写入 + 双备份非活动槽
15

16
切换事务层
17
先保存pending，再正常finalize并由底层安排复位
18

19
结果闭环层
20
新固件比对version_code + 后台accepted后清pending

最值得记住的是四个“不等于”：

1. DHCP 成功不等于现在适合升级，还要等待业务连续空闲；
2. 后台返回任务不等于设备必须执行，还要本地做兼容性和环境校验；
3. 下载 100% 不等于镜像可信，还要检查实际长度和 SHA-256；
4. 镜像写完不等于升级成功，还要跨重启确认目标版本。

把这四条边界讲清楚，面试官继续追问 HMAC、流式下载、Flash 掉电、双备份、Bootloader 回滚或量产安全时，就可以从系统设计回答，而不是停留在“调用了一个 OTA 接口”。