测试闭环补固件身份戳、烧录回读校验与启动锚点计数，并修cmd引号解析与flash-cmd预检缺陷
This commit is contained in:
@@ -36,10 +36,10 @@
|
||||
<!-- MEM_SNAPSHOT:BEGIN generated by scripts/check_mem_numbers.py -->
|
||||
| 区域 | 用量 | 容量 | 占比 |
|
||||
|---|---|---|---|
|
||||
| ER_IROM1 | 267,740 B (261.46 KB) | 1,048,576 B (1024 KB) | 25.5% |
|
||||
| ER_IROM1 | 267,820 B (261.54 KB) | 1,048,576 B (1024 KB) | 25.5% |
|
||||
| RW_IRAM1 | 85,032 B (83.04 KB) | 131,072 B (128 KB) | 64.9% |
|
||||
| RW_CCM | 49,184 B (48.03 KB) | 65,280 B (64 KB) | 75.3% |
|
||||
| **Flash (ROM 合计)** | **268,480 B (262.2 KB)** | 1,048,576 B (1024 KB) | **25.6%** |
|
||||
| **Flash (ROM 合计)** | **268,560 B (262.3 KB)** | 1,048,576 B (1024 KB) | **25.6%** |
|
||||
<!-- MEM_SNAPSHOT:END -->
|
||||
|
||||
各区的容量与常量来源：
|
||||
|
||||
@@ -151,7 +151,7 @@ ST-LINK_CLI -c SWD HOTPLUG -Dump 20000000 1000000 dump.bin :: 转储 SRAM
|
||||
| `-r8/-r16/-r32 <地址> <数量>` | 读内存（地址、数量均为**十六进制**） |
|
||||
| `-w8/-w32/-w64 <地址> <数据>` | 写内存 |
|
||||
| `-Dump <地址> <大小> <文件>` | 内存转储到文件 |
|
||||
| `-CmpFile <文件> [地址]` | 全片 Flash 与文件逐字节比对（2026-09-20 实测：`No difference found` = 真写入；v3.5.0.0 无 `-Cksum` 命令） |
|
||||
| `-CmpFile <文件> [地址]` | 全片 Flash 与文件逐字节比对（2026-09-20 实测：`No difference found` = 真写入；v3.5.0.0 无 `-Cksum` 命令）。⚠ **连接即复位目标**（2026-10-10 实测：比对瞬间板子重打一遍开机日志）→ 自动化里必须排在日志采集之后 |
|
||||
| `-P <文件> [地址] [ske] [skpv]` | 编程（ske=跳擦除 skpv=跳校验） |
|
||||
| `-V [after_programming]` | 校验 |
|
||||
| `-ME` / `-SE <扇区>` | 全片擦除 / 扇区擦除（⚠️ RDP≠0 时 `-ME` 会被拒） |
|
||||
@@ -177,11 +177,13 @@ Get-Content tools\serial_tool\state\serial.log -Tail 100
|
||||
ⓞ 实测补充三条：
|
||||
|
||||
1. **改过 `serial_config.json` 端口后必须重启 daemon**：daemon 在启动时缓存配置，改端口后 `close` + 杀旧进程再 `open`，否则一直按旧端口报 `port not found`；
|
||||
2. **复位刚发生的几秒内 `wait-idle` 可能报 `daemon unresponsive after auto-start: timed out`**——daemon 正在排空开机日志突发，数据其实已落盘；
|
||||
3. **日志校验直接读文件最可靠**：`tools/serial_tool/state/serial.log` 用 Read/Grep/Select-String 直接查（实测 `log --grep` 子命令对确定存在的标记返回 0 命中，语义存疑，勿作为判定依据）。
|
||||
2. **（已修，2026-10-10）旧版 `wait-idle` 在复位突发期会报 `daemon unresponsive after auto-start: timed out`**：CLI 把**超时**误判成"daemon 不可达"，顺手拉起一个绑不上 HTTP 口的实例再把命令撞一次超时（数据其实已落盘）。现 CLI 超时按 `--max-ms` 自动推导、超时只快速失败不再误拉起实例；
|
||||
3. **日志校验**：`tools/serial_tool/state/serial.log` 用 Read/Grep 直接查最直观；`serial_tool.py log --grep <标记>` 现已可作判定依据（2026-10-10 修：旧实现先 `--tail`（默认 50）后 grep，开机标记必然查不到——这就是当年"实测 0 命中、语义存疑"的真根因）。
|
||||
|
||||
**B. 完整烧写 + 运行**：`MDK-ARM\reset.bat flash [xxx.hex]`（= `-c SWD -P <hex> -Rst -Run`；09/19 实测 1MB ≈ 6.5s，09/20 复测 6.47s + 全片 `-CmpFile` 逐字节一致）。正式流程仍以 `download.bat`（`UV4 -f`）为准，CLI 路径作为脚本化/快速路径。
|
||||
|
||||
**B2. 回读校验**：`MDK-ARM\reset.bat cmp [xxx.hex]`（= `-c SWD -CmpFile <hex> 0x08000000`，2026-10-10 加；默认对最新构建 hex）。判定看输出行首的 `No difference found`（`This file is already downloaded` 是同义提示）。⚠ **连接即复位目标**：实测比对瞬间板子重打一遍开机日志 → 在自动化闭环里回读必须排在**日志采集之后**（`run_boot_test.py` 已按此顺序内置）。
|
||||
|
||||
**C. 救援**（板子起不来 / 疑似 Flash 问题）——本机 3 线接线的可行子集：
|
||||
|
||||
```bat
|
||||
|
||||
+12
-4
@@ -9,8 +9,8 @@
|
||||
│
|
||||
├─ Step 0 预检 .venv + serial_tool（selftest/ports 确认 COM）
|
||||
├─ Step 1 构建验证 MDK-ARM/build.bat (0 错误 0 警告才继续)
|
||||
├─ Step 2 烧录 + 采集（一条命令编排：开串口 + 清日志 → 烧录 → wait-idle → 提取）
|
||||
│ test/host/run_boot_test.py (内置 serial_tool + download.bat + verify_log.py)
|
||||
├─ Step 2 烧录 + 采集（一条命令编排：开串口 + 清日志 → 烧录 → 固件身份戳 → wait-idle → 提取 → 回读校验）
|
||||
│ test/host/run_boot_test.py (内置 serial_tool + download.bat + reset.bat cmp + verify_log.py)
|
||||
├─ Step 3 判定：
|
||||
│ PASS → 报告，结束
|
||||
│ FAIL → 依据 [MISS]/[HIT] + 日志尾部，修改代码后回到 Step 1
|
||||
@@ -23,9 +23,10 @@
|
||||
| `@build` | `.opencode/command/build.md` | 仅编译验证（0 错误 0 警告） |
|
||||
| `@download` | `.opencode/command/download.md` | 编译并烧录（ST-Link） |
|
||||
| `@test` | `.opencode/command/test.md` | 完整闭环：build → capture+download → verify → iterate |
|
||||
| `test/host/run_boot_test.py` | `test/host/run_boot_test.py` | **一键闭环**：open + clear → 烧录 → wait-idle（静默 8s/超时 30s）→ 提取 `[RX]` → verify，退出码 0=PASS/1=FAIL/2=采集或烧录错误/3=用法错误 |
|
||||
| `test/host/run_boot_test.py` | `test/host/run_boot_test.py` | **一键闭环**：open + clear → 烧录 → 固件身份戳（从 hex 抠 `fw build:`）→ wait-idle（静默 8s/超时 30s/首字节 12s）→ 提取 `[RX]` → 回读校验（`reset.bat cmp`）→ verify，退出码 0=PASS/1=FAIL/2=采集·烧录·回读错误/3=用法错误 |
|
||||
| `MDK-ARM/reset.bat` | `MDK-ARM/reset.bat` | ST-LINK CLI 封装：`flash [hex]`（烧 + `-Rst -Run`）/ **`cmp [hex]`（回读比对，2026-10-10 加）**/ 无参复位 / `halt`/`run`/`list`/`hard` |
|
||||
| `tools/serial_tool/serial_tool.py` | `tools/serial_tool/` | Python 串口助手（常驻 daemon + 薄 CLI）：ports/open/send/status/log/clear/wait-idle/selftest；全量日志 `state/serial.log`（20MB 自动截头） |
|
||||
| `test/host/verify_log.py` | `test/host/verify_log.py` | 对日志做标记校验，输出 PASS/FAIL 并返回退出码 |
|
||||
| `test/host/verify_log.py` | `test/host/verify_log.py` | 对日志做标记校验（含**启动锚点计数** `--max-boot-count`、复位原因白名单 `--expect-reset-cause`），输出 PASS/FAIL 并返回退出码 |
|
||||
|
||||
## 判定标准
|
||||
|
||||
@@ -35,6 +36,9 @@
|
||||
- `0` = PASS：所有 `-Required` 标记均出现，且无 `-Forbidden` 模式命中
|
||||
- `1` = FAIL：存在缺失标记（`[MISS]`）或违规模式（`[HIT]`）
|
||||
- `2` = 日志文件不可读
|
||||
- **固件身份戳（2026-10-10 加）**：`App/app/app_main.c` 开机打印 `fw build: <__DATE__> <__TIME__>`（编译期展开成一段**连续 ASCII**，`.hex` 里可原样搜到）。`run_boot_test.py` 从**待烧的 hex** 里抠出该串并追加成 Required 标记 → 芯片里跑的必须就是这份构建。反例实测：把 hex 里的戳改成 `Oct 9 2026 01:00:00` 再跑，其余标记全中但 `[MISS] fw build: Oct 9 2026 01:00:00` → FAIL——这正是过去"反复重下载、芯片一直是旧镜像"在闭环里**完全隐形**的场景。`--no-fw-check` 关闭；hex 里没有该串（旧构建）只 WARN 跳过、不假判。
|
||||
- **烧录回读（2026-10-10 加）**：采集结束后自动跑 `reset.bat cmp`（= `-CmpFile` 全片逐字节比对），判定按**行首** `No difference found`（进度条与帮助文本里也含该短语，故不能全文匹配）；不一致 → `RUN_TEST_ERROR: flash readback mismatch` + 退出码 2（本次运行作废：日志是"某个未知镜像"跑出来的）。⚠ **顺序不能颠倒**——`-CmpFile` 连接时会复位目标（实测板子当场重打一遍开机日志）。`--no-verify-flash` 关闭。
|
||||
- **启动锚点计数（2026-10-10 加）**：`reset cause:` 在一次采集里出现 **0 次**（采集没从复位开始，标记全中也可能只是上一轮残留）或 **>1 次**（板子中途自己复位：IWDG 咬狗 / Fault 后 `NVIC_SystemReset` / 掉电重启）→ FAIL；`--max-boot-count N` 放宽（跑故意复位的套件时用），`--expect-reset-cause 'software;power-on'` 对第一个锚点做原因白名单（SWD 软复位实测为 `software (NVIC_SystemReset)`，CSR=0x14000000）。
|
||||
|
||||
### 自检结果判定（S7，`--require-selftest-pass`）
|
||||
|
||||
@@ -69,6 +73,9 @@
|
||||
| daemon 无响应 / 自动拉起失败 | 查 `tools/serial_tool/state/daemon.log`；`serial_tool.py restart` 重建 daemon；检查 COM 是否被其他程序占用 |
|
||||
| 抓到日志缺 `Network Init` | `-SettleMs` 太小（boot 任务间有 ~3-4s 自然静默间隙），用默认 8000ms；2026-10-10 起首字节到达前不启动静默计时（`--first-wait-ms` 默认 12000），首行晚到不再被提前收尾 |
|
||||
| 烧录后无数据（`no_data`） | 2026-10-10 起 `no_data` = **本次等待期间零字节**（旧实现比 daemon 累计字节，常驻 daemon 下永不触发，只能靠"日志里没有 [RX] 行"兜底）；开串口 + clear 必须在烧录**前**完成（`run_boot_test.py` 已保证）；核对 COM 号、板子供电，看 `state/serial.log` 有无 SYS 异常行 |
|
||||
| `[MISS] fw build: <戳>`（其余标记全中） | 芯片里跑的不是这份构建：烧录没落地 / 烧错文件 / hex 未重编译 | `reset.bat flash <hex>` 重烧并看 `READBACK: OK`；确认 `@build` 已重跑（戳取自编译时刻） |
|
||||
| `READBACK: FAIL` / `flash readback mismatch` | 芯片内容与 hex 逐字节不一致（写入未落地、选项字节/RDP 异常、烧错目标） | 按 `docs/测试说明/ST-LINK_CLI_复位使用说明.md` §10 排查；`reset.bat flash` 重烧后闭环会自动复核 |
|
||||
| `boot banner x2 > allowed 1` | 采集窗口内板子自己复位过（IWDG 咬狗 / Fault 后 `NVIC_SystemReset` / 掉电重启） | 看判定里逐条打印的 `reset cause:` 定位；跑**故意复位**的套件用 `--max-boot-count N` 放宽 |
|
||||
| 端口被占用（`port busy`） | 先 `serial_tool.py close` 或 `restart`；检查其他程序占用；Keil ST-Link 不占 COM |
|
||||
| 日志中无 UI 相关输出 | 见下节「UI 自动化」 |
|
||||
| 日志出现 `[ERR]` 行 | 固件错误级日志（`DBG_ERROR`），默认 Forbidden 会判 FAIL：按 TAG 查对应模块的 `docs/问题记录/*_Trap_Records.md`；若属测试套件的**预期**错误（守卫负路径、非法名校验等），用 `--forbidden` 放宽 |
|
||||
@@ -103,3 +110,4 @@
|
||||
| 2026-09-15 | 采集机制整体切换：serial-mcp-server（采集窗口/first-byte/EOF 重试）→ 仓库内置 Python 串口助手（daemon 常驻全量日志 + `wait-idle` 静默判据 `-SettleMs`/`-MaxWaitMs`）；`serial_capture.ps1` 删除，流程/脚本清单/失败模式表同步 |
|
||||
| 2026-09-21 | 默认 Forbidden 增补 `[ERR]`：固件 `DBG_ERROR` 前缀是 `[ERR]`（≠ `ERROR` 子串），此前驱动/模块错误日志不会被自动闭环拦截；`verify_log.py` / `run_boot_test.py` 默认值同步，测试套件运行需显式放宽 |
|
||||
| 2026-10-10 | 采集链可靠性修复（serial_tool 第一批）：`wait-idle` 的 `no_data` 改按本次增量判（旧实现常驻 daemon 下永不触发，"烧录后无数据"这一失败模式实际测不出来）+ 首字节门 `--first-timeout-ms`（`run_boot_test.py` 新增 `--first-wait-ms`，默认 12000）；`log --grep` 改先过滤后截尾（旧顺序导致 marker 必然查不到）并加 `-i`/`--regex`；`wait-idle` CLI 超时自动推导，不再需手工 `--timeout`；HTTP 口独占绑定修正（旧选项名/数值均无效，实际未生效） |
|
||||
| 2026-10-10 | **第二批：闭环补上"烧进去的是哪份镜像"与"跑的过程中有没有偷偷复位"**：① 固件身份戳——`App/app/app_main.c` 开机打印 `fw build: <__DATE__> <__TIME__>`，`run_boot_test.py` 从待烧 hex 里抠出该串追加成 Required 标记（旧镜像/错镜像此前所有固定标记照样全中）；② 烧录回读校验进闭环——`reset.bat` 新增 `cmp` 子命令（`-CmpFile` 全片比对），采集后自动跑，不一致 exit 2；实测 `-CmpFile` 连接时会复位目标，故必须排在采集之后；③ 启动锚点计数——`verify_log.py` 新增 `--max-boot-count`/`--boot-marker`/`--expect-reset-cause`，`reset cause:` 出现 0 次或 >1 次判 FAIL；④ 修 `--flash-cmd` 带参数时预检必 missing、以及 `cmd /c` 对含空格路径（本仓库目录名 `DTU Code`）的引号解析把回读假判成"芯片不一致"（改为直接 CreateProcess 跑 .bat）。真机验证：完整烧录闭环 PASS（含戳匹配 + `No difference found` + 锚点 x1）；伪造戳 → 其余标记全中仍 FAIL |
|
||||
|
||||
Reference in New Issue
Block a user