故意破坏 ESP32 的 OTA 更新会怎样？
We broke an Over-The-Air update on the ESP32 on purpose
OTA 更新是物联网产品的生命线，但一旦中断，设备极易变砖。我们利用 Groundrun 系统，在 ESP32-C6 上故意制造了三种最恶劣的更新中断场景：软件复位、硬件复位和直接断电。测试发现，得益于 ESP-IDF 的双分区回滚机制，设备不仅能幸存，还能自动恢复并完成更新。我们进一步验证了从旧版本到新版本，再到下一版本的连续更新能力，确保系统在任何中断后都能回到已知良好的状态。
额外的恢复时间紧密跟踪着增加的延迟：它是下载进度的重复，中断前做一次，中断后再做一次。
- leoedin
这篇文章内容空洞。测试 OTA 更新能否在下载过程中断电后幸存，这种测试太基础了，根本不需要写这么长的文章。我猜这是 AI 根据几个句子的提示生成的吧？
他们没做任何有趣的测试。那掉电（brownouts）、电压纹波、精确控制复位信号以观察更新过程中是否存在关键时间点、损坏的更新文件、高电磁兼容（EMC）环境等等呢？这些才有趣。
我觉得这篇文章是在为某个测试平台打广告，该平台能自动化此类测试。但奇怪的是，他们并没有展示平台如何实现自动化，所以看起来他们只是对自己完成了一些非常基础的工程工作而感到沾沾自喜。
- rurban
你只需要足够的 Flash RAM 来存放两个固件和一个正确的引导加载程序（bootloader），该程序知道哪个分区是活动/已验证的。就这么简单。最大的问题是获取足够的 Flash。
编写引导加载程序 trivial（微不足道）。
- mikewarot
个人轶事：大概在 1985 年左右，我遇到过类似的问题。我手头有一个手持条形码扫描器，需要通过专有串行协议将收集的数据上传到 PC 以便最终生成报告。
客户在上传过程中问：“如果我此刻断开连接会发生什么？”这是一个我未曾考虑过的边缘情况。让它变得坚不可摧只花了我几天时间。
---
作者们似乎没有考虑到网络非常慢或不稳定的情况。
我会担心下载过程中的数据损坏，并对此进行检查。我也会确保看门狗硬件已开启，且代码尊重它。
在我看来，OTA 代码需要 3 个缓冲区，而不是 2 个。应该有一种方法，除了任何新更新外，还能保留上一个运行版本达 X 秒，其中 X 应该相当大，也许是一整天。