学习笔记 · Obsidian
NVS、OTA 和恢复：让设备能够长期运行
NVS 先从一个配置开始
NVS 用于保存小型键值数据。第一轮保存“采样周期”即可：读取时验证范围和配置版本，缺失时使用明确默认值；更改后检查写入与 nvs_commit 结果，最后通过重启验证持久化。ESP-IDF NVS
不要每次采样都写一次 Flash。把“当前读数”和“需要长期保存的配置”分开；相同配置无需反复写入。NVS 有磨损均衡，也仍需合理控制写入频率。
初始化失败时先分类原因和恢复影响。直接擦除整个 NVS 会丢失保存内容，不应作为任何异常都执行的常规逻辑。多个键也不能未经验证就当作一笔数据库事务；相关配置可设计版本化记录和恢复策略。
OTA 先设计失败如何启动
应用 OTA 通常需要至少两个应用槽位和 OTA data 分区：把新固件写到非当前启动槽，校验后切换下一次启动目标。启用回滚机制后，新固件首次运行需要完成自检并确认有效，否则可回退。ESP-IDF OTA
下载候选版本 → 校验 → 写入备用槽 → 切换并重启
↓
首次启动自检
↙ ↘
确认有效 回滚“下载成功”不是升级完成。分区配置、镜像尺寸、启动验证、配置兼容和设备恢复，都属于一次升级。
本项目建议的升级验收
- 检查镜像与实际型号、Flash 分区布局匹配，升级来源可信。
- 升级前记录旧固件版本和配置版本。
- 新固件启动后检查必要外设、主循环/任务和配置读取；不要把临时云端故障无条件作为固件失效依据。
- 在受控实验中验证下载中断、校验失败、新固件自检失败及回滚。
- 确认回滚后的旧固件还能读取配置，或存在兼容读取/迁移策略。
上述是本课程的实验设计，并未在设备执行。固件签名、Secure Boot、Flash/NVS 加密在产品化阶段结合具体威胁和供应流程设计；本轮不进行 eFuse 等不可逆配置。
最少的可观察信息
| 信息 | 用来判断什么 |
|---|---|
| 固件版本、启动原因、运行时长 | 设备是否反复重启 |
| 配置版本、当前采样周期 | 命令是否真正生效 |
| 最近成功采样时间、错误码 | 旧读数是否已失效 |
| 网络状态、最近重连原因 | 故障在哪一层 |
| 空闲内存最低值、队列溢出计数 | 是否存在资源压力 |
| OTA 阶段与结果 | 是否完成或需要恢复 |
日志记录可定位问题的摘要，不记录凭据和完整认证材料。实验结论保留脱敏的关键结果，不把整段串口日志复制到 Vault。
过关标准：断电、断网、错误配置和坏版本都有清楚的恢复结果；如果还没做故障演练，状态保持“待实机验证”。