wandering1
16917bf165
P1-10 剩余①「CH395F 套件实际构建确认链接通过」今天才真正有数：产品基线 + 三档 测试配置（ARMCC，全部 0 错误 0 警告；.sct 保持 128 KB 未动，符合 P1-10 写的 "不建议扩到 192KB"）： 配置（TEST_SUITE_CH395F + 阶段） Code ZI RW_IRAM1 距 92% 余量 产品基线（阶段全关） 214,104 131,852 75,632 57.7% 44,954 B 默认阶段 11/14（只切套件宏） 217,468 134,076 77,920 59.5% 42,666 B NET 层全开 6~11/13/14 218,992 141,688 85,552 65.3% 35,034 B HW 层全开 1~5/12/15（最坏态） 229,256 147,176 90,952 69.4% 29,634 B HW 层无需 PC 1/12/15（冒烟用） 215,244 134,896 78,672 60.0% 41,914 B P1-10 specifically 关心的 PHASE5 三块静态缓冲（3 x PHASE5_CHUNK_SIZE = 3 x 4093） 确实进了链接，不是"理论上会在"：hw_full 的 ch395f_test_task.o 数据段 = 12,285 B （12,279 + 该 TU 其余 6 B）。于是"理论余量足够但未实测"改成了实测：最坏态仍余 29,634 B（RW_IRAM1 上限 131,072 B，92% 线 120,586 B）。RW_CCM 四档恒为 57,376 B / 87.9%——测试代码不进 CCM，但该区已经贴着红线，将来往 CCM 加东西要单独核算。 顺手修掉一个把实测挡了三年的坑（就是它让第一轮 hw 配置炸掉的）： ENABLE_PHASE11/14 两行的说明是**挂在行尾的跨行块注释**。而"关掉一个阶段"的标准动 作是在行首加 //，// 只注释到行尾 → 块注释从第二行起变成裸代码，实测 188 条 error #7: unrecognized token，报点落在注释续行上，看着像头文件坏了、其实只是注释 被腰斩。run_all_suites.py 的 _rewrite_config 只改 TEST_SUITE_* 行（那些行没有行尾 跨行注释）所以一直没暴露；ch395f_test.h 恰是"人手工切阶段"的入口，必须自身安全。 修法：把两段说明挪到 #define 行的上一段，行尾只留同行闭合的短注释；并在开关区后面 写清"开关行注释规范"+ 上面这张实测表（同一事实只在这一处，销项时文档引它）。 验证（_wt/P1-10-test-fw，每步都实跑 @build）： - V1 产品态（改注释后）：0/0，Code/RO/RW/ZI = 214104/20388/1204/131852，与主干 2026-10-25 台账行逐项相同 → 本改动零体积增量。 - V2 只切套件宏（默认阶段 11/14）：0/0，RW_IRAM1 77,920 B / 59.5%。 - V3 **朴素行注释切换**（正是炸掉第一轮的那个动作）改到 HW 1/12/15：0/0，且尺寸与 用 #undef/#define 覆盖法得到的 hw_nopc 逐字节相同（215244/23656/1200/134896） → 陷阱确认已消除，两条改法等价。 - V4 还原后产品重建：0/0，数字回到基线；test_config.h 与 ch395f_test.h 均按字节还原 （git status 只剩本文件这一处改动，测试宏没有留在树里，test-suite-switch 无需放行）。 - 产物身份戳实测：hw_nopc = "Oct 25 2026 04:32:16 suite=CH395F dstr=off"、产品态 = "Oct 25 2026 04:32:25 suite=NONE dstr=off" → dstr=off 三档一致，破坏性开关全程关。 RAM 增量：0 B。gate：改动只命中 no-mojibake / trailing-whitespace / end-of-file-fixer / check-added-large-files / id-check / mem-budget，全部 0；未用 --no-verify。 P1-10 剩余②（@test 烧录抓日志）需要 bench 锁，已把镜像与锚点清单交给 lead 执行； 真机跑 Phase 2~5 / 8 / 11 / 13 / 14 需 PC 端 tcp_server / peer 配合（Phase 11 还要 制造死对端，E11），属"实际测量采样"类，按用户指示本轮跳过，不在本提交声称做过。
test/ — 测试代码与主机端脚本
测试分两部分，物理隔离在两个子目录：
board/—— 板端测试套件（.c/.h，编入固件由 testTask 执行）host/—— 主机端脚本（.py，PC 侧驱动板子并判读结果）
目录结构
| 目录 | 内容 | README |
|---|---|---|
board/ |
板端测试套件（编入 Keil 工程，占 RAM） | board/README.md |
host/ |
PC 端测试/判读脚本（Python） | host/README.md |
run_all_suites.py |
多套件回归编排（改宏 → 构建 → 烧录 → 采集，try/finally 保证还原开关）；--check-build = 只编译不烧录（纯离机） |
本文 §多套件回归 |
运行方式
# @test 一键闭环（推荐）
& '.venv\Scripts\python.exe' .dsh/skills/serial-boot-test/scripts/run_boot_test.py
# 单独校验日志
& '.venv\Scripts\python.exe' .dsh/skills/serial-boot-test/scripts/verify_log.py <日志文件>
# 多套件回归编排（需真机；自动改开关 + 构建 + 烧录 + 采集，结束后还原）
& '.venv\Scripts\python.exe' test/run_all_suites.py
& '.venv\Scripts\python.exe' test/run_all_suites.py --suites STORAGE,GD5F
& '.venv\Scripts\python.exe' test/run_all_suites.py --dry-run # 只看计划
# 只编译不烧录（S6；不需要 MCU / 串口 / ST-LINK，验证 4 套件可编译性）
& '.venv\Scripts\python.exe' test/run_all_suites.py --check-build
退出码约定：0=PASS / 1=FAIL / 2=采集或烧录错误 / 3=用法或预检错误。
多套件回归（run_all_suites.py）
套件互斥（编译期 #error）意味着跑 4 个套件要手工循环 4 轮。本脚本把它编排成一条
命令，并且无条件还原 test_config.h——跑完忘还原 = 测试固件进库，这是它存在的
核心理由（与提交期门禁 test-suite-switch 互为独立防线）。
⚠️ 每轮要真机烧录 + 采集，4 套件约数分钟起；破坏性套件还会改设备持久状态。 仅回归窗口用，绝不挂 pre-commit。
--check-build 则相反：只改宏 + @build，不烧录不采集，无需任何硬件，用于防止
"测试套件长期编不过而无人知"（2026-08~09 CH395F 套件实例）。改动 test/board/ 下测试
代码后建议先跑它——实测 4 套件均 BUILD_OK: 0 errors, 0 warnings。
⚠️ 注意
- 本目录被 pre-commit 门禁排除（测试代码不受 C 规范约束）
board/套件占用 RAM，启用前先核算预算（见docs/内存管理/）- Keil 工程已同步：
board/下 7 个.c编入MDK-ARM/STM32F4-Demo.uvprojx， IncludePath 含../test/board；移动文件须同步改工程文件 - 套件选择开关：
board/test_config.h的TEST_SUITE_*（互斥，一次只启用一个） - 测试缓冲用分 Phase 复用静态缓冲（避免
L6406E溢出）
相关文档
docs/测试说明/测试开发标准流程.md— L0~L3 分层与门禁决策表docs/测试说明/自动化测试流程.md—@test细节与失败模式- 各模块测试指南：
docs/测试说明/*_Test_Guide.md docs/测试说明/链路延迟测试说明.md