ESP-IDF 生产落地案例

五、生产落地案例

案例一：量产固件「随机重启」定位到看门狗与日志级别

业务背景：一批智能插座产品在实验室运行正常，量产出货后在部分现场出现随机重启，日志碎片化，复现困难。

怎么用：先让设备启动时输出复位原因，据此把「看门狗复位」与其他复位区分开；再看任务是否有长时间不让出 CPU 的循环；检查日志级别——调试期留下的高频日志在串口输出上阻塞严重，尤其当串口没接或波特率低时，写日志会阻塞任务；把量产固件的默认日志级别降到 Warning 以下，并去掉循环里的高频日志。

关键配置：任务看门狗（Task WDT）的使能与超时；串口控制台输出在量产固件里是否需要关闭；各任务的栈大小按实测峰值留余量，而不是拍脑袋给个值。

效果指标：现场重启问题基本消失；同时因为去掉了日志输出开销，主循环的响应也更稳定。

踩过的坑：一是用调试固件直接量产，日志级别没降；二是把栈大小设得刚好够用，加了日志后栈溢出，触发随机崩溃，后来按实测峰值加 30% 余量；三是没有记录复位原因，早期根本分不清是看门狗、掉电还是硬故障，补上启动日志之后定位速度完全不同。

案例二：OTA 升级与分区表规划

业务背景：一个部署在客户现场的环境监测设备，需要远程升级固件，早期用单分区方案，升级失败只能返厂。

怎么用：改用带 OTA 的分区表方案（工厂分区 + 两个应用分区），应用启动并自检通过后主动标记自身有效；升级流程是「下载新固件到备用分区 → 校验 → 切换启动分区 → 重启 → 自检 → 标记有效或回滚」；下载用 HTTPS 并校验固件签名；升级状态上报到云端，方便运维观测失败率。

关键配置：分区表大小必须同时容纳两个应用；Flash 容量与分区表要匹配；回滚策略要明确（自检失败几次后回滚）；升级过程中断电的容错（下载到备用分区，不影响正在运行的分区）。

效果指标：升级失败的设备可以自动回滚到可用版本，现场故障从「必须上门」变成「远程重试」；升级过程可观测，失败原因能定位。

踩过的坑：一是分区表没给两个应用留够空间，编译直接被拒绝，重新规划分区并调整 Flash 容量配置；二是忘记标记应用有效，设备每次重启都回滚到旧版本，表现为「升级成功但版本没变」；三是升级期间断电，因为下载写入的是备用分区，运行中的应用没受影响，这一点在设计时就考虑到了，否则会变砖。