wandering1/STM32F4-Base
1
0
Fork 0
Code Issues 30 Pull Requests Actions Packages Projects 2 Releases Wiki Activity
561 Commits 3 Branches 0 Tags
16917bf165d47b29c457deb91abaca437b532833
Commit Graph

29 Commits

Author SHA1 Message Date
wandering1 16917bf165 test(P1-10): CH395F 套件三档构建实测 + 修阶段开关行尾跨行注释的切换陷阱 
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），属"实际测量采样"类，按用户指示本轮跳过，不在本提交声称做过。
 2026-10-25 04:49:19 +08:00
wandering1 78248a1cdf feat(S-5): 收编 SD2506/TPAFE 并给 dhara 失败分类，门禁基线 19→17 
前一笔立契约与门禁（`Drivers/BSP/bsp_err.h` + `bsp-err` 钩子 + RS485 试点）；这一笔按用户
指定顺序 C3 → C1 → C2 把三个模块真正收编，并让存储失败第一次变得可读、可分类。

**C3 · SD2506 整模块（11 个公共 API + 6 个内部 helper）**：三枚私有宏 `SD2506_OK`/
`SD2506_ERROR`/`SD2506_I2C_ERROR` **删除而不是留别名**——留别名等于新代码还能用旧形状，
把迁移洗掉；编译器替我们找全所有调用点。新增 `sd2506_err_from_hal()`，**把 I2C 超时从
"和没人应答共用一个 −2"里拆出来归成 `BSP_ERR_TIMEOUT`（可重试）**——SD2506 是启动链第一站、
I2C1 上电时序敏感，这是本波唯一真正的语义改善，不是改名。`sd2506_init` 的 charge 寄存器
**回读校验不符**原返参数类错误，改归 `BSP_ERR_IO`（那不是调用方的错）。

**C1 · 同形两义**：`GD5F_BUSY_TIMEOUT` → `GD5F_WAIT_EXPIRED`（**值 −2 不变**，纯消"名字叫
TIMEOUT 其实是返回码"）。**GD5F 私有码集整体收编刻意没做**：169 处引用里 48 处在板级套件、
还要动 Trap 记录用词，属另一波带真机+套件回归的工作，不夹带。TPAFE5160 收编 23 处：
`BUSY_TIMEOUT → BSP_ERR_TIMEOUT`、`ERROR → BSP_ERR_PARAM`（**同值 −1，行为零变化**）、
`FRSTDATA_ERR → BSP_ERR_NO_DEVICE`（E-44 的本义就是"芯片没驱动 DB 总线"，归到器件无响应比
私有 −3 有用，且避开与 `BSP_ERR_TIMEOUT` 撞值）。实测 `tpafe5160.o`/`gd5f2gq5ue.o` 的 Code
增量为 **0**——改名不产生一条指令。

⚠ **`tpafe5160_snapshot()` 刻意不套成败码**：它是 1=有新帧 / 0=无新帧 / −1=参数错 的三态
**状态**返回，0 不是错误而是"这一拍没有新数据"，强行收编会把慢消费者的正常路径变成失败。
顺带订正我上一版在 `bsp_err.h` 的断言——"本层只有 `net_*` 把数量与错误挤同一返回值"是错的，
`snapshot`/`adc_input_poll` 就是第二族；两族现都已写明并各注保留理由。

**C2 · FTL 坍缩点分类**：`ftl_flush_cache`/`ftl_read_page` 不再把 dhara 失败压成
  `GD5F_ERROR`，
按**处置差异**分三类，并在最早同时知道 LPN 与原始码的位置就地打印：`ECC`/`TOO_BAD` →
`BSP_ERR_CRC`（页级，重试或换页，不代表卷坏）；`JOURNAL_FULL`/`MAP_FULL` →
`BSP_ERR_NO_SPACE`（介质健康但块池/日志见底，此时重格式化只是把问题推回去）；
`BAD_BLOCK`/`RECOVER`/`CORRUPT_MAP`/越界 → `BSP_ERR_IO`（完整性故障，保卷 + 上报，不许自愈
重格式化）。这与 **E-31** 是同一条纪律的两端。可读名用自建短表：**本仓 dhara 没有编
`error.c`，用 `dhara_strerror()` 会直接链接失败**。`disk_read`/`disk_write` 仍回
  `RES_ERROR`
（FatFs 契约）；要让 defaultTask 卷健康探针按类分支还差跨调用存活的快照 → C4 待还。

**两次靠核实拦住的自我错误**：① 我一度认定 `DBG_ERROR("... err=%d", err)` 是把结构体塞进
varargs 的格式 bug——核 `Lib/dhara/error.h` 后确认 `dhara_error_t` 是 `enum`（标量），那行日志
本来合法，改了反而是引入错误；② `bsp-err` 一次 `replace_all` 越界把 8 处 **GD5F 码空间**的
判据改成 `!= BSP_OK`（数值同为 0、无行为变化），但那正是"把两个码空间混起来"，已逐一还原。
`cppcheck` 亦抓到 `cls` 声明作用域过宽，已收进失败分支。

**验证**：`@build` 0 错 0 警告（`Code` 213,648、RO 18,860、`ER_IROM1` 232,508 B /
  22.2%、
`ROM 合计` 233,696；**RAM 三项零增量**）；`@test` PASS（692 ms，烧入戳 `Oct 23 01:35:32`）
且逐条读到被改模块的锚点：`SD2506 init: OK (ret=0)` 与 ID/时间/温度/电池四条读回正常、
`ADC init: OK`、`NAND init: OK`、`Map resumed: 14094/97504`、`adc=` 帧计数持续递增（证明
snapshot 三态未被改坏）、`[ERR]`/Fault/FAIL 0 条。主机单测：系统时钟 100/100、dhara NAND
移植层 149/149（两者都因本次改动需补 `Drivers/BSP` include 路径，补后在钩子内实跑 Passed）。
`pre-commit run` 全量 RC=0（20 个实跑钩子 Passed）；`bsp-err` 基线 **19 → 17**（还掉两个
`*_BUSY_TIMEOUT = -2`）、`--prune` 干净；`doc-links --all --sections-strict` 147 篇
  0 问题；
`id-check --strict`、`layer-deps`、`mem-numbers`、`mem-budget`、`ui-golden` 全过；33
  个文件
字节卫生 0 异常（无 CR / 无 U+FFFD / 无行尾空格 / 均有尾换行）。

**口径与数字联动**：新增 `docs/架构设计/STM32F4-Base存储架构说明.md` §10.4（三类码与处置
理由）；`pre-commit使用说明.md` §2.27 与 `AGENTS.md` 基线计数 19 → 17；TPAFE README、
GD5F 测试指南与 Trap 记录均**保留旧名留痕**以便对旧日志；配图桶按 .map 对象级增量重算
（`dhara/FTL` 10,931 → 11,222，+291 全部落在 `nand_ftl.o`；应用代码/UI +36 落在
`app_main.o`；其余散量入"其他"7,557；桶和 = Code+RO 断言通过、文本溢出 0）；
`ram_baseline --update/--write`、`ram_report_20261023.md` 快照、报告 §1.3/§5.1/§5.4
  与
部署文档 §3.3 数字全部同步；报告 §0.4/§9 的 S-5 状态改为 🟡 主体已落地。
 2026-10-23 07:42:02 +08:00
wandering1 a26a9d6f52 test(NET): 阶段 8/9 实现体补挂用例号 TC-NET-801/802/901/902 
先纠正我上一轮的错判：这 4 条不是「被重构丢掉」，实现体一直都在，
只是从来没挂号——我在旧路径 test/ch395f_test_task.c 里找，而它们已在
2026-08-26 前后搬进 test/board/net_test_task.c（文件搬迁导致我误判成删除）

判据（为何不是有目的删除，也不是遗漏实现）：
- 开关在（ch395f_test.h:62/63）、调用点在（net_test_task.c 主循环 phase8_run /
  phase9_run）、函数体在（phase8_run / phase9_run）三者齐全 → 若是有意删除
  必然连开关与调用一起清掉
- 内容逐条对得上：phase8_run 按 PHASE8_DIRECTION 编译期切 SEND/RECV、逐字节 +
  尾附 4B CRC32（= TC-NET-801 SEND / TC-NET-802 RECV）；phase9_run 注释即
  「有数据返回正数 / NET_FD_ISSET 正确 / 超时 50ms 返回 0」
  （= TC-NET-901 就绪检测 / TC-NET-902 超时）
→ 所以按用户的判据（没意义才删）结论是**不删**，删了反而抹掉四条已有覆盖的入口

验证：@build 0 错误 0 警告，Program Size 与改前逐字节相同 → 只动注释；
DOC-ONLY 10 → 6、追溯交集 261 → 265；id-check --strict 无台账外新账；
BOM=否 CR=0 U+FFFD=0
 2026-10-21 23:45:06 +08:00
wandering1 3c69411409 test(NET): 阶段 1 实现体补挂用例号 TC-NET-101 / TC-NET-102 
手法与上一批 TC-NET-1101 相同：只把号挂到已有实现体的注释上，不改任何语义
- 第一轮第 1 项处补挂 TC-NET-101（附录 B 的 ✅ 由此可走到实现体）
- 第一轮第 6 项处补挂 TC-NET-102，并注明条目何时删、汇总行为何遗留

顺带修一处被门禁当场咬住的写法：注释里原写「P1-01~P1-09」这个范围式，
让校验 6 多出 2 类台账外新账 → 按既定规矩改写成平实语言，**不往债务台账塞条目**

验证：@build 0 错误 0 警告且 Program Size 与改前逐字节相同
（Code=213356 RO=18580 RW=1184 ZI=131480）→ 证实只动注释；
id-check --strict 通过（无台账外新账）；doc-links --all 143 篇 0 失效；
追溯交集 259 → 261（101/102 两侧现在都有号，是真对上，不是靠注记压掉）；
BOM / CR / U+FFFD 与 HEAD 逐项一致
 2026-10-21 23:35:40 +08:00
wandering1 514a514601 test(NET): 阶段 11 实现体补挂用例号 TC-NET-1101 
不是新增测试，是把已有实现体的号补上：ENABLE_PHASE11_TESTS 在
ch395f_test.h:65 是打开状态，实现体在 net_test_task.c:810 起（phase11_run），
但从未挂 TC-NET-1101 → 追溯器把它当成「文档声明却无载体」

改法：只在阶段 11 说明块补一行用例号注释（含属主文档路径，满足 §5.2 紧邻要求）

验证：@build 0 错误 0 警告，Program Size 与改前逐字节相同
（Code=213356 RO-data=18580 RW-data=1184 ZI-data=131480）→ 证实只动注释；
BOM / CR / U+FFFD 与 HEAD 逐项一致；id-check --strict 通过
 2026-10-21 23:14:31 +08:00
wandering1 fca414102e fix(编号): 批 6 追溯器分档 + 板级 NET 用例号标注归一 
步骤 1：追溯器分两档（不改数据，改判据）
- BENCH：文档**定义行**（标题行或表格首格）带「（硬件层）」或其所属章节带的号 →
  人工台架用例，不期望有 C 代码载体；NOTIMPL：定义行标了未实现/待补/暂缓/已取消
- 两档**单列示数恒打印**、明细进 --verbose，不是静默豁免；也不等于"已验证"
- 两个实测坑写在脚本注释里：① 按"任意行出现即算"实现时 BENCH 收 14 个号却只消掉
  1 处差异（同一号被别处引用一次就复活）→ 改为只认定义行 + 从文档全集整体减档；
  ② 载体类型必须由定义处决定，引用行不影响判断
- 另把 has_intent() 收窄到同号所在行（原先整文件任意位置有人话就算过关）

步骤 2：板级 NET 用例标注归一（真债，改名 109 处 / 5 文件）
- 取证发现"文档声明却无载体"绝大多数是**标注形态烂**：实现体里写的是
  TC204 / TC-201 / TC 703 / TC1501 / TC1502b（三种畸形），文档写 TC-NET-204 等
- 序号一位不改、只补模块码（§7.1）；作用域限定 5 个真载体文件：
  test/board/ch395f_test_task.c(67) net_test_task.c(37) net_test_task.h(1)
  test/host/ch395f_socket_test.py(3) Drivers/BSP/CH395F/ch395f.c(1)
- 审计轨迹 scripts/rename_maps/batch6-net-annotate.json；别名自动登记（scoped）

实测
- DOC-ONLY 29 → 15：701~704 的 NET 层实现体一直存在（net_test_task.c），
  此前因裸形标注被误判成"未实现"；1501~1503 属硬件层人工 + 同样裸形
- 交集 260 不变、代码侧 578 不减（识别面没缩）；BENCH 14 个号 / NOTIMPL 1 个
- 台账 --prune-backlog 还清 6 条（只减不增）；@build 0 错误 0 警告
  （Program Size 与改前逐字节相同：Code=213356 RO=18580 RW=1184 ZI=131480
   → 证实只动了注释与日志串）；7 个改动文件 BOM/CR/U+FFFD 与 HEAD 逐项一致

剩余 15 处 DOC-ONLY 的组成（步骤 3 未完，下轮处理）
- 4 处文档侧无模块码形态（TC-1003/206/501/704）→ 属 ② 大批
- TC-NET-607 一条是历史指称（原文"原 607/608/609，现 701/702/703"）
- 真未实现 10 条：TC-NET-101/102/601/606/801/802/901/902/1006/1101
  ——其中 801/802/901/902 曾在 2026-08 的代码里有载体、后被重构丢掉，最值得补
 2026-10-21 13:53:06 +08:00
wandering1 52976bdec3 refactor(编号): 批 4 陷阱号统一为 TRAP-<模块码>-<nn> 
本批是 ② 形态迁移清的第一族（用户裁定顺序：② 里的 Trap 一族先做）

统一了什么（数字不变、只补模块码，§7.1）——改名工具 23 处 / 11 文件
- Trap 01~07 → TRAP-GD5F-01~07：属主文档 7 个标题行从此成为定义位
- 陷阱 1 → TRAP-RTC-01（SD2506 属 RTC 域，§4.2）、见陷阱 01 → TRAP-GD5F-01
- Trap 21 / Trap 19 → TRAP-NET-21 / TRAP-NET-19（引用的是活登记处
  CH395F_Trap_Records.md，号本身不变）
- 波及 Drivers/BSP/GD5F2GQ5UE/*（4 处注释）与 test/board/*（2 处）→ 已重编

三处判读后**刻意不改**（写进 §8.3，不让人当成漏网）
- docs/环境与部署/并行任务工作树方案.md 的 wip/trap22-fix 是 git 分支名，不是编号；
  这类非编号字面量要靠类型处理，与位号 T1、IEEE 负序 S2、gitlint 规则 ID 同一批
- docs/UI设计/菜单页面设计.md 变更记录行的「陷阱 3」按 §8.1 冻结不改写
- docs/硬件平台/V0.0、V0.1 网表报告里 6 处 Trap05 语义确指 TRAP-NET-05，但该目录
  是门禁与改名工具共同的排除语料 → 不越界动笔，盲区登记进注册表 TRAP 族 cursor_note

两处不是改名、是改错话（映射表类工具的典型失效：字面对了、意思错了）
- scripts/README.md 原写「Trap 19 从未存在」；改名后字面变成 TRAP-NET-19，而它是
  **真实条目**（SET_MAC 必须在 INIT_CH395 之前）→ 那句话成了假话，改用站得住的例子
- docs/编号规范.md 同一处事故叙述补准确说法：当年裸形不在册 ≠ 这个坑不存在
- 菜单页面设计.md 的「见 §8.2 陷阱 1」本就不是 TRAP-* 族的号（指本文小节第 1 条），
  改写成「见本文 §8.2 第 1 条（lv_text_get_width 的 length=0 陷阱）」

关闸第一次真拦人：咬的是自己家的审计表
- scripts/rename_maps/batch3-trap.json 里必然写着 Trap 21 / 陷阱 1 等旧形态，
  被当成 6 类「台账外新账」→ 提交被拦（拦得对，但表不是语料）
- 第 4 次同一类自循环（前三次：别名表、注册表、债务台账）→ 整个 rename_maps/
  目录入 excluded_paths；这条规律写进 §8.4：**登记号的表一律不得当引用语料**

实测变化
- 错误级 659 → 632（−27）；② 空格/中文形 Trap 残余 2 处（都是上面刻意保留的）
- ③ 悬空错误 44 → 42：TRAP-GD5F-01/05/06 三处历史悬空引用自动落地为已定义
- 编号字面量 8277 → 8312（识别面没有缩水，这是改名最容易踩的坑）；
  可判定比例 82.92% → 82.99%（基线 82.6%）；⑦ 定义无引用 100 → 103（如 TRAP-GD5F-02
  只有定义位无人引用，如实挂 warn 不压掉）
- 台账 --prune-backlog 收掉已还清 42 条，剩 298 条（只减不增）；--strict 通过

另修：core.autocrlf=true 把 SD2506_Trap_Records.md 检出成 CRLF（41 处）→ 还原 LF，
该文件 diff 只剩 1 行实质改动（仓库权威行尾是 LF，见 .gitattributes）

验证（全绿）
- @build：0 错误 0 警告（Program Size Code=213356 RO=18580 RW=1184 ZI=131480）
- ci_local.py：L0 + L0.5 全过（16 runner / 1104 断言）
- check_doc_links.py --all：143 篇文档 0 失效、0 待确认
- 改动文件字节卫生逐项与 HEAD 对比：BOM / CR / U+FFFD 异常 0

审计轨迹与文档
- 映射表 scripts/rename_maps/batch3-trap.json（含作用域切分理由与刻意不改清单）
- 别名 11 条全部带 scope；docs/编号规范.md §7.1 行状态、§8.3 批 4 行 + 说明段、
  §8.4 自循环第 4 条、变更记录
 2026-10-21 12:32:13 +08:00
wandering1 bda7ab2b50 refactor(编号): 16 个测试模块码单词化 + 门禁识别面连带放宽 
批 2（用户授权改名 + 「新名要一眼看懂」裁定）
- 16 个有歧义模块码单词化，共 1,146 处随 scripts/rename_ids.py 改写：
  AI→ADCIN、AH→ADCHEALTH、PS→PROTSET、PE→PROTELEM、PH→PHASOR、
  TS→TIMESYNC、VL→VOLLOCK、NP→NANDPORT、CFG→CONFIG、CLK→SYSCLK、
  WD→WATCHDOG、STO→STORAGE、SH→SHA256、FA→FTPAUTH、FR→FREQ、104→IEC104
- 不动 NET/GD5F/RTC/SOE/UI/ADC/LOG/RS485/TOOL（已是单词、芯片名或业界通用词，
  改了纯属 churn）
- 别名按全局登记：这批字面量已完全限定（TC-<码>-<nnn>），不存在裸形多义
- 映射表存档 scripts/rename_maps/batch2.json 作审计轨迹；§6 模块码表同步

连带修门禁（关键教训）
- 模块码涨到 9 位（ADCHEALTH/WATCHDOG）后，候选正则与族正则的 {0,4} 上界
  会让改名后的号**整批从门禁眼里消失**：实测编号字面量从 8271 掉到 7315、
  悬空假降 490 处。已放宽到 {0,9} 并写进 §6 注记
- 结论：改名批次必须连带复核识别面，只改数据不改判据 = 静默放行；
  这次是靠「可判定比例跌破基线即失败」那条线拦下来的

现状与遗留
- 校验 1 未登记前缀 0 处；可判定比例 82.71%（基线 82.6%，只涨不跌成立）
- 遗留：7 个模块的「单元测试说明.md」仍缺（PROTSET 116、NANDPORT 109、
  PROTELEM 65、FREQ 48、FTPAUTH 45、SHA256 25、SOE 14 处悬空）——改名不解决
  缺文档，处置方式待议
- 遗留：T-2/T-3/T-4/T-6 历史任务号悬空（别名表未收全，属本工具批次漏项）
- 未改任何 C/H 可编译语义（仅注释与宏名内的编号），故不需 @build
 2026-10-21 09:53:28 +08:00
wandering1 506eccc68f docs: 错误码传播审计收口并删除该文档（E-xx 转历史编号族） 
本次会话先后销项与关闭：
- E-61 SD2506 清 INTAF：原实现只读取 CTR1，而按手册 ARST=0 时读操作
  不清标志，属空操作；改为读-改-写 CTR1，并按手册订正 CTR1 位宏
  （INTAF/INTDF/BLF 位置，ARST 归 CTR3）
- E-16 cfg_file：新增 CFG_FILE_MAX_NAME_LEN（段名/键名 ≤15），注册时
  拒绝超长键名；s_gen_document 两处 snprintf 改检查式；补 TC-CFG-024
  用例（主机单测 149→151 PASSED）
- E-23 TC704：PHASE7_MULTI_COUNT 8→5（并发上限 = 8 − 3 个常驻监听），
  accept 失败分支加网络代次检查（网络重建即重建监听）
- E-26（UDP）按“保留 API + 文档定案”关闭；E-30 评估为不必要后关闭；
  N-4（ACCEPT 决定不实施）关闭

审计文档剩余 5 项 P2 + 2 项监督，经用户裁定“都不重要”后整体删除：
- 删除 docs/问题记录/错误码传播审计.md（634 行）
- 九类缺陷模式表迁入 docs/编号规范.md §4.2.1（PAT-01~09）
- E-xx 转为纯历史编号族：编号规范 §4.1 属主改“无（原属主已删除）”，
  §4.3 保持冻结；全仓 26 处引用按“保留编号、去悬空文档名”处理
- 顺带修正 N-4 收口遗留：排期详述 C1 才是 E-25/E-27/E-28 的承载处
  （审计 §4 曾误写为登记簿）；README 两处 C1 旧名改回“net 层跨上下文收口”

一并提交此前遗留的体系层评审报告 2026-10-14 复核 WIP（六维评分复核、
未闭环 Top 5→3、三区水位实测刷新）。

校验：Keil 构建 0 错误 0 警告（Code=212344）；check_doc_links
--sections-strict 与 --all（142 文档）通过；内存双台账刷新后均 PASS。
 2026-10-15 07:39:38 +08:00
wandering1 d770e36c7c refactor(NET): 源码注释去阶段化 + 网络两份文档重构 + 不稳根因图更新 
- 源码注释：删去自愈收敛阶段
1/1.5/3等 scaffolding 称谓，改为语义引用
  （E-02 收口 / F-NET-2/3/4 / docs/网络/网络自愈架构设计.md §5.2 E13）；
  涉及 net_socket/.h、net_events、net_listener、net_pending、net_types、
  net_config、ch395f、time_sync、iec104_serv、ui_net_sink、lftpd、
  simulator/sim/net_socket_sim、board/host 测试与探针
- 文档重构：网络自愈架构设计.md 与 Net层阻塞模型架构设计.md 改为现状口径
  （删历史节与阶段叙事），NET/README.md、docs/README.md 同步
- 工具与配图：gen_net_instability_svg.py 与
  docs/images/网络不稳根因总览.svg 随源码口径一并更新
- 门禁：@build 0 错误 0 警告
 2026-10-14 22:05:53 +08:00
wandering1 f849c79b7a feat(NET): SEND pending 二期落地 + 末块挂起越界缺陷修复（台架复测闭环） 
net_pending.c/h 增设第二张挂起表 s_net_send[]（与 recv 表完全独立，收发
互不阻塞）；net_send_locked 快速路径改为有界自旋，单次等待超出
NET_SEND_SPIN_MS(2ms) 即登记挂起 send，由 net_send_pending_tick 按主循环
节拍分块推进，netTask 最坏停滞由 1s 压到 2ms。net_listener_retry_tick 的
挂起保险扩展到 send 侧；net_close_locked / 网络重建 / 状态对账三路均先
取消再动作（取消必通知，调用方永不挂死）。

台架复测（A/B 对照 + 插桩定位）发现并修复末块挂起越界缺陷：内层"等本块
发完(SENBUF_FREE)"位于写块之后，写完末块时 sent 已 == len，若该次等待越过
2ms 预算便会调用 net_send_pending_register，而登记函数按 sent >= len 拒收
并回 -1，把一次实际已完整交付芯片的发送报成失败。修复为内层等待开头判
sent >= len 即跳出（末块已交付、SENBUF_FREE 等待是纯保守自旋），并置于
超时/自旋判定之前；该守卫同时保证后续登记必伴随 sent < len。

复验：ftp_regression 连续 19 次 11/11；ftp_integrity_test 20 轮 x 64KB
STOR/RETR SHA-256 20/20 一致（两轮），吞吐稳定约 80KB/s；设备日志零
write error；ST-LINK 回读 No difference found。

文档：Net层阻塞模型架构设计.md 补二期设计与新增 9.1 缺陷记录，netTask
栈实测峰值按本次台架 920B 订正为 1116/3840（FTP 传输期 1164）；网络自愈
架构设计.md 吸收原监听生命周期文档、新增编号术语导读表，并把 5.2
"实验锚点速查"的 E 编号含义与 E-02 审计编号歧义写在表头（用户反馈该表
E 编号无法读懂）。

门禁：Keil 0 错 0 警；cppcheck / 编码规范 / 乱码零告警；
check_mem_numbers PASS；check_doc_links --all --sections-strict 142 篇 PASS。
 2026-10-14 12:05:21 +08:00
wandering1 a12367981d fix(N34): E14 丢中断复核——芯片不丢事件；listen 排事件挪至 LISTEN 前+全局读收口+全库归因更正 
48 轮直读 SINT 矩阵（8 周期×6 变体）复核历史"丢中断"说法：芯片侧事件
丢失 = 0。归类：drain 读清消费 3/48（drain-int 探针现场抓获）、门控
竞态 2/48、主机同步 1/48、幽灵态 0/48 未复现。

根除性修复：net_listen_locked / net_listener_try 的排事件读清从
listen 后挪至 LISTEN 命令之前——新连接 CONNECT 落进该窗即被本方读清
吞掉，即"数据被吞"的生产侧自伤机制（台架 3/48 为同形态放大版）。

全局读收口：全局中断寄存器唯一读者 = net_poll（I7）；生产/测试/台架
游离全局读全部删除，ch395f.h 声明处加护栏注释。

归因更正：17 文件约 40 处"丢中断"措辞改为"事件未收到/读清消费竞态"
（机制全部保留，仅归因更正）；设计文档 §5.2 新增 E14 锚点；Trap
Records TRAP-NET-17/-20/B3 归因更正段；配图生成器与 SVG 重生成。

台架：事件未收到复核探针保留（drain-int / SINT 补读×3 / 超时归类），
下次跑矩阵自动归类；实验注册（main.c/uvprojx）已完全还原。

验证：@build 0 错误 0 警告；ci_local L0 32/0 + gitlint + L0.5
953/953；doc-links --all --sections-strict 通过；@test PASS（无
[ERR]，net init 619ms）；回归 :7003 300ms×10 = 10/10、:21 n30×50 =
0/50 失败。
 2026-10-14 02:48:50 +08:00
wandering1 1a35b3684c docs(N34): 自愈审计目录 7 份文档合并为单文档，全库引用同步
CI / L0 静态门禁 (pre-commit) (push) Failing after 44s
Details
CI / L0.5 主机侧单测 (MSVC) (push) Failing after 43s
Details 
- `docs/网络/N34-自愈审计/` 目录 7 份文档（根因总览 / net 层盘点 /
  驱动层审计 / 主流对照 / 汇总裁决 / 实施方案 / 实验方案）合并为
  `docs/网络/N34-自愈审计.md`（§0~§6），原目录删除；docs/README.md
  索引与变更日志登记归档
- 全库引用同步：4 篇文档 + 驱动/NET/test 代码注释 + 配图生成器与 SVG
- 内容零丢失抽查：E0~E13 实验记录、E6 裁决（命中=0 不立项）、
  提交表（含 `925058a` 收口行）均在位
- 门禁：@build 0/0（注释级路径更新）；check_doc_links --all 143 文档
  通过（净 −6 = 删 7 增 1 吻合）；ci_local L0+L0.5 全绿
 2026-10-13 23:23:55 +08:00
wandering1 925058a5ae fix(NET)+docs: lftpd 对端地址修复、E6 裁决收口、陷阱编号迁移重排 TRAP-NET-01~21 
- lftpd：net_inet_ntoa 段序改 MSB 首 + 新增 net_getpeername，FTP 日志打印
  真实对端地址（真机实证 192.168.1.2:55524，登记 TRAP-NET-21）
- E6：NET_U15_PROBE 命中=0（含压测）→ 阶段 3 项 4 不立项，U15 登记观察项；
  插桩留仓（宏=0 零成本），soak 驱动 test/host/e6_soak.py 入库
- 编号：全库 Trap NN → TRAP-NET-<nn> 迁移并重排连续 01~21（单调映射，
  沿革见 CH395F_Trap_Records.md 头注）；死号 12/13/19/21 引用全部清除；
  GD5F 域引用补正为 TRAP-GD5F-NN
- 陷阱文档全新化：索引 21 行行行真陷阱；删误判存档/发现时间/git 考古/
  FTP 附录；台架纪律教训沉淀第六章方法论
- RAM：Code 211348→211456（+108 lftpd 修复），RW+ZI 净增 +4B；
  优化方案/台账受管区/tsv 同笔同步
- ftp_abort_probe.py 挪 test/host/；引用关系图重生成
- 回归：@build 0/0；@test PASS；ftp_abort 10/10；relisten :7003 20/20；
  ci_local L0+L0.5 全绿；E6 窗口零复位，7 条 WD stall 登记压测假象备查
 2026-10-13 20:54:31 +08:00
wandering1 83a70721bd docs(N34): E2/E3/E4 实验结果与定案 + bench 实验区复活 
E2：状态回读 18.1us（N=1000x2 逐值一致）；LISTEN 可见延迟 100%
<=10ms 无长尾（24 轮）-> "每 poll 全量刷新"成立、reconciler 去抖
可减为 1。
E3：GET_CMD_STATUS 对 OPEN/LISTEN/CLOSE 无判别力（残留假阳性），
定案 cmd_done 用状态回读判据；SET 类命令态永不更新。
E4：排渣序列定案=读空 RX -> CLOSE -> 排空事件(quiescent) ->
轮询 byte0=00H；C 变体（不排渣）0/20 且级联自持，Trap 23 残渣
恰等于单 Socket RX 缓冲整容（rxdrain=2048，19/20）。
E2 补充发现（Phase 15 板测）：LISTEN 态 CLOSE_SOCKET 二段关闭
（一次只拆监听 byte0 恒 05，再发一次才落 00）——Trap 09 open
重试环的芯片级原因。

bench：ch395f_reuse_bench.c 复活 N30_CHIP_BENCH 门控实验区
（旧 N-30 矩阵 s_bench_legacy=0 停泊），ch395f_reuse_host.py
增 --mode e4。注册（uvprojx/main.c）实验完已还原不入库。
 2026-10-13 12:43:56 +08:00
wandering1 f7f17931c9 feat(N34 阶段2): ch395f 五原语只加不接线 + Phase 15 套件 20/20 
实施方案 docs/网络/N34-自愈审计/实施方案.md §4 五原语，形态按
E2/E3/E4 定案（实验方案.md）：
1. 类型化状态回读 + 每 Socket 缓存（open=0 时 tcp_state 哨兵
   0xFF；sn>7 边界返 {00,FF} 计 fault）；
2. 事件护栏 ch395f_sock_events：只读本 Socket SINT，全局寄存器
   唯一读者=net_poll（F-NET-7 契约）；
3. ch395f_sock_reset_begin/poll 非阻塞状态机：读空 RX -> CLOSE
   -> 排空事件(quiescent 2 轮) -> 轮询 byte0=00H；GRACEFUL/
   QUARANTINE 最短等待 100/400ms（Trap 23）；WAIT_CLOSE 内置
   LISTEN 态二段 CLOSE 补发（TC1502b 实证 ~180ms 落定）；
4. ch395f_cmd_done 状态回读判据（E3：GET_CMD_STATUS 对
   OPEN/LISTEN/CLOSE 无判别力）；
5. 链路态缓存 ch395f_glob_event_feed + link_up/变化计数
   （B9 判据 PHY!=DISCONN）。

Phase 15 板测（硬件层模式，Socket 7，无需 PC）：20/20 PASS，
含二段关闭语义断言（一段 05/00、二段 byte0=00）。

RAM +56B < 64B（g_sock_state 16B + g_rst 32B + 链路/fault 8B）；
产品 Code 与阶段 2 前逐字节同 209780（无调用者被链接器裁剪）。
@test PASS；relisten_stress 20/20、n30 3/3 零回归。
RAM 台账同步：RW_IRAM1 97952B 74.7% / RW_CCM 57376B 87.9%。
 2026-10-13 12:43:17 +08:00
wandering1 33405a57b5 docs(N34)+test: E13 僵尸会话根因坐实；Phase 11 判据修正+一次性报告 
E13（实验方案.md 新增 + E8/E11/E12 口径修正）：
- 风暴态根因=僵尸会话，非芯片残渣：PC 网卡禁用/链路断开时
  Windows 直接丢弃 socket 不发 FIN/RST → 芯片侧 ESTABLISHED 僵尸
  → 单连接监听被占（:21 拒连）→ 下一 PASV 重监听与僵尸竞态
  （accept 为垂死僵尸开枪 20ms 后 DISCONNECT）→ lftpd 5s 窗空转
  → 425；每失败轮再生僵尸 → 自续数分钟
- "残渣跨烧录存活/需断电冷启动"口径作废：板上 CH395F RSTI 接
  MCU NRST（V0.0 网表 :174），每次烧录即芯片硬件复位；"存活"是
  锤击再生错觉。正确控制=下一臂前静置 ≥90s 清僵尸窗
- 自愈链端到端验证：TIMEOUT(在途 TX ≈30s)/keepalive(空闲 60/5/3)
  → pump → relisten → 端口恢复；E11 产品路径验证 17s 判死 PASS
- 4 元组复用假设被否（pasv_probe.py：PASV 端口递增、PC 源端口随机）
- e02_probe listener=FAIL 重解读：探针挂起 socket 未关（PC 内核
  代 ACK keepalive）→ 拒连是单连接正确行为；真缺口=应用无法主动
  拆会话 → 阶段 2 sock_reset 职责

Phase 11 测试修复（net_test_task.c，实跑暴露）：
- 判据 >=60000ms 是按手册公式写的，实测判死 18~31s 会在正确固件
  上假 FAIL → 改有界窗 10s~120s（下限防误杀存活空闲会话，上限
  防判死缺位）
- 报告后不释放 phase_active → 对已死连接 10ms 节奏刷 594 条假
  FAIL → phase11_run 返回完成态，主循环释放等新连接再测
- 复跑两轮验证：30137ms 单次 PASS → 自动等新连接 → 二轮 accept 正常
- Test_Guide TC-NET-1101 判据/耗时同步；ch395f_test.h Phase 14
  共存安全性注释（有整体超时不永久挡 accept）

工具：test/host/pasv_probe.py（每轮打印 PASV 端口+PC 源端口+结果）
 2026-10-13 11:23:40 +08:00
wandering1 13a4a40a14 feat(net): 服务器侧 KeepAlive 转正（§5.56，E11）+ Phase 11 重开回归 
E11（d96113b）证据链："链路在、对端静默"注入下生产参数 60/5/3 实测
判死 ≈30s → TIM_OUT → QUARANTINE → pump 重建；静默但存活对端不误杀。
handle_connect_event LISTENING 分支按手册规定位置开启；反汇编确认
编译器把两分支尾部合并（LISTENING 跳入含 keepalive+fire_event 的公共
尾部，hex 全片仅该分支偏移 1 行差异，Code 尺寸不变属填充巧合）。
Phase 11 重开时发现其拉入 32KB s_rx_buf 超产品 RAM 余量（L6406E 链接
失败）→ 改专用 64B 探针缓冲（本 Phase 仅 64B 探针读，门控注释已留
"勿加回"警示），套件恢复 0 错 0 警；TC-NET-1101 步骤同步死对端注入法
（禁用网卡；Windows 防火墙规则对已建立连接无效，E11 实证）。
验证：产品/套件双构建 0 错 0 警 + 反汇编确认调用落地；台架确认
（:7003 静默对端判死 + Phase 11 实跑）待设备冷启动断电重上电后补做。
 2026-10-13 09:25:06 +08:00
wandering1 b8c6a3dab0 refactor(net)!: N34 阶段1 API 面收敛（对账⑤ + 删 3 个手动自愈 API） 
BREAKING CHANGE: 删除公开 API net_relisten / net_resync_listen /
net_can_accept 与消息类型 NET_MSG_RESYNC_LISTEN / NET_MSG_RELISTEN。
生产调用者为零（仅看门狗文档与 iec104 门控），应用侧无迁移成本；
如有外部消费者须改用对账/pump 自动机制（见下）。

1. 对账①扩展为①②⑤（F-NET-2 缺口，先补缺口再删 API）
   net_reconcile_tick 新增 bad=5：本层 ESTABLISHED 且芯片 0x05/0x01
   （Socket OPEN + TCP LISTEN，静默回收回监听、不发 DISCONNECT）
   → RESYNC 语义只修本层（state→LISTENING + last_peer_port 转登 +
   lost_conn_seen 清零 + 取消挂起 recv），**不发任何芯片命令**
   （纪律同 pump③ U11，run8 实证重下发会 170s 永拒）。
   原判据①要求 TCP==CLOSED、②要求本层 LISTENING，均不命中此形态
   ——此前生产无人认领（仅手动 API 能修）。
2. 删 net_relisten（net_socket.c 函数 + 消息分派 + 头文件声明）
   footgun：对健康监听器无条件 open→USE→close 自毁 ~1s（原注释自认）；
   与 pump(100ms)/D10(30ms) 完全重叠。
3. 删 net_resync_listen（同上；语义并入第 1 条）
4. 删 net_can_accept（net_socket.c + net_socket.h + sim 三处）
   只认 ESTABLISHED 的旧门控把"监听器在服役、待 CONNECT"窗口全挡掉，
   :2404 丢 CONNECT 探针因此从不运行；iec104 门控迁 net_listener_armed。
5. timeSync :8888 会话收尾不再 net_close（同 fd 续 accept，监听跨会话
   常驻；原 close→重建每会话一个 Trap 09 沉降窗）。server 脚本注释同步
   新契约（PC 侧 2s 宽限后自行关闭）。
6. lftpd 应用层阻塞重试退役：lftpd_inet_listen 5 轮(500ms/2000ms，最坏
   10s 阻塞 ftpTask) → 单次 + 失败即 425；cmd_pasv 3×200ms 同删。
   就绪屏障已消除 Trap 09 启动形态，客户端自带传输重试语义。

台架实证修正（本提交内二次修复，务必留痕）：
- net_listener_armed 补齐 **ESTABLISHED 放行**。首版迁移只放行
  LISTENING/CLOSED+残留，漏了 ESTABLISHED=单连接模型的"待 accept"电平
  → iec104 200ms 任务周期抢不过对账② 的 ~400ms 去抖，对账②先 standalone
  accept 转 ESTABLISHED 后 armed=0 → 应用整场不 accept，18/18 检查全 FAIL
  （设备日志证据：sock1 standalone accept 后无 i104 accepted，直至对端 FIN
  才由 closed-with-data 救回）。补放行后 18/18 PASS，且耗时 127s→8.3s。
  该态 accept 必返 fd，无 RPC 风暴风险。
- 期间顺带验证 M3 无辜：sock1 suspect DISCONNECT on live conn 命中后
  defer→对账①→closed-with-data accept 把未 accept 的 RX 数据救回，
  正是 M3 设计意图（资产门保护）。

验证（全绿）：@build 0/0（Code=209580；含 CH395F 套件+Phase13 全量重编
0/0 的编译验证）；@test PASS（回读无差异）；iec104 18/18（8.3s）；
n30 0/50；:21 @0ms 50/50 p50=512；:7003 50/50 p50=517；ftp_regression
11/11；Trap23 RST 5/5 + FIN 5/5；time_sync :8888 连续推送正常（RTC 更新、
无 [ERR]）。文档同步：BSD 指南（§3.3/3.6/10.1/10.2/12 + 变更记录）、
函数调用关系、监听生命周期设计说明、IEC104 上行设计说明、模拟器差距
清单、链路延迟测试说明。

门禁说明：doc-links 工作树 junction 伪影按既定口径 SKIP；mem-budget
分支 .map 漂移同前；cppcheck/coding-standard 手跑 Passed。
 2026-10-13 06:44:26 +08:00
wandering1 4c0a0af9f8 fix(net): N34 阶段0 零风险清理 9 条（注释债/死码/三处小逻辑门） 
纯注释/死码（零行为变更）：
- 0-1 pump 注释 50ms→100ms（宏真值源 100U，net_socket.c）
- 0-2 D10 give-up 文案改"retry budget exhausted, pump takes over"
  （旧文案夸大永久失效语义，pump 100ms 仍周期认领重建）
- 0-7 IP 字节序注释更正：set_ip/gw/mask 实为点分十进制序（调用方
  parse_ip_string 数组直传、芯片按首段接受、台架多年实证）；
  set_des_ip 补"与 get_remot_ipp 输出同序"往返注（ch395f.h/.c）
- 0-8 Trap 13 注释降级为"未证实历史观察"（对齐 2026-10-11 Trap 13
  复核注，与手册 §5.34 相左）：DMA 定容理由改"接收缓冲 2KB 整缓冲
  单读=Trap 25 排空契约形态"；net_socket.c 四处引用改写
- 0-9 删死声明：GET_GLOB_INT_STATUS(0x29)/ENTER_SLEEP/EEPROM×3/
  GPIO×2/SPI_BEGIN_DELAY_MS/GINT_STAT_SOCK0..3（全仓零引用核实）

小逻辑（台架冒烟实证）：
- 0-3 U12 对称：TCP_LISTEN 失败补 close 两处（net_relisten_locked /
  net_listen_locked）——防芯片 Socket 卡"OPEN 无监听"、下轮 open
  恒返 USE（U12 同源事故形态）
- 0-4 retry_tick 状态门：仅 LISTENING/CLOSED 才重试；已转 ESTABLISHED
  （新会话抢先）清陈旧登记，防 open→close 摧毁活连接（认领口径同 pump）
- 0-5 FUN_PARA 裸 0x08 → CH395F_FUN_PARA_SOCKET_CLOSE（复用既有宏
  (1UL<<3)，注释补 §5.52/版本/红线口径；曾重复定义触发 9 警告，
  已并入原宏块）
- 0-6 版本门控：ver<0x46 拒置 bit3 并 [ERR] 留痕（防芯片批次漂移；
  本台架 ≥0x46 行为不变，fun_para 日志改打实际值）

验证：@build 全量重编 0 错 0 警（Code=209580，RW/ZI 不变）；@test
PASS（回读无差异）；冒烟 n30 0/20、:21 @0ms 20/20、:7003 20/20、
ftp_regression 11/11。

门禁说明：doc-links 工作树 junction 伪影按既定口径 SKIP；mem-budget
分支 .map 漂移同前；cppcheck/coding-standard 手跑 Passed。
 2026-10-13 05:54:42 +08:00
wandering1 afb0bfd5ff fix(net-audit): 修 6 处寄存器口径/注释错误 + Trap 记录全量复核与审计章节 
智能体团队四路并行只读审计（驱动层逐命令 / NET+测试层逐调用点 /
Trap 01-12 复核 / Trap 13-25 复核），三源交叉：芯片手册 + WCH 官方
SDK（CH395CMD.c / CH395INC.H / 21 个例程）+ git 历史。本提交只落
"已确认且低风险"的修法，其余发现登记进文末审计章节待逐项决策。

已修（A 类，全部有手册/SDK 出处）：
A1 测试 TC-203 反核实写成 st_chk[0]==CH395F_TCP_ESTABLISHED——§5.22
   byte0 只有 00H/05H，条件恒假，这道 Trap 14 防线自写下起从未生效
   且日志无痕（与 Trap 07 同类的 byte0/byte1 语义越界）。改为
   byte0==OPEN && byte1==ESTABLISHED。
A2 测试 Phase3/4 把 GET_RECV_LEN 返回值直接当读取长度（本地
   rx_buf[300]/[64]，芯片 RX 缓冲 2KB）→ 栈溢出；补夹取 + 留痕
   （同文件 TC201/202/204 早已 clamp，这两处是漏）。
A3 CH395F_GINT_STAT_DHCPV6 由 0x8000(bit15) 改 0x1000：SDK 是
   (1<<12)、§5.16 明确 CH395F 的 [12:15] 保留。全仓零引用。
A4 ch395f.h 命令分组注释字节数错 4 处（GET_GLOB_INT_STATUS_ALL /
   GET_UNREACH_IPPT 归"1 字节输出"、SET_FUN_PARA 归"1 入 1 出"、
   SET_RETRAN_PERIOD 归"3 字节输入"、GET_SOCKET_STATUS_SN 归"1 字节
   输出"）；KeepAlive 参数注释"秒"改"毫秒"（§5.53/5.54 单位 ms）；
   set_retrans_count 删"0=默认值5"（§5.17 默认 12、无 0=默认语义）。
   实现全对、注释误导——Trap 25 的 1 字节缓冲栈越界正是这类注释发起。
A5 net_socket.c 六处注释与手册/HEAD 相反：FUN_PARA(SOCKET_CLOSE=0)
   实为 bit3=1（正是 closed-with-data accept 的契约依据，写反会诱导
   把 0x08 改回去）、"初始化成功后设置 MAC"（§9.2.1 ① 是之前）、
   "复用默认缓冲"（net_init 已为 8 Socket 显式分配）、"由 MSS 推导"
   （固定布局、Trap 21 已解耦）、"等 SEND_OK"（门控是 SENBUF_FREE）、
   UDP 头 [0-1] reserved（§9.2.4 是数据长度）。
A6 ch395f.c write_send_buf 超限静默 return（void 无日志），且上限取
   DMA 2048 而非发送缓冲 1024；读路径有 OVERSIZE 金丝雀、写路径没有
   → 补 [ERR] 留痕 + >1KB 告警，行为不变（分块责任仍在调用方）。

审计确认"不是 bug"的最危险一项：GET_GLOB_INT_STATUS_ALL 拼装方向。
我们"第1字节|第2字节<<8"与官方 CH395CMDGetGlobIntStatus() 逐字相同，
glob & (1<<(sock+4)) = §5.16 bit4..bit11 = SDK GINT_STAT_SOCKn，三源
一致。另 55 条命令码、9 处 16 位字节序、14 条读命令字节数、60 个
常量、12 个单位参数点、48 块缓冲布局逐条核对无异常；17 处
get_socket_status 调用点全是 st[2]，Trap 25 的 1 字节 bug 无残留。

文档：Trap_Records 加文末「2026-10-11 寄存器/数值口径全量审计」章节
（干净清单计数 + 15 条新发现含已修/待修 + 文档待修清单）。就地修正：
Trap 07 定案更正里"全文 RST 仅见于错误码与引脚"的绝对表述（§5.29 /
§9.2.6 其实写了芯片发 TCP RESET，只是都与 close 无关）+ 删不可核验的
"11 个悬空提交"；Trap 16 的"IP/端口寄存器大端"（端口 §5.25/5.26 明确
低字节在前）+ 注明 §5.8 总括与官方例程自相矛盾；Trap 18 删悬空
"Trap 19"（该条从未存在）、net_socket() 改 net_bind()；速查清单 DMA
1500 改 2052；Trap 13 加复核注（最高优先级：其"部分读后 recv_len
归零"与 §5.34 直接相左、与本仓 TC201 注释相反，且同族结论已被 Trap 21
撤回，却仍被 6 处当现行约束引用）；Test_Guide 的 TRAP-07 行仍教
"卡 FIN_WAIT_2 / close(RST)"、悬空的 Trap 19 与两处"见风险 #N"。

待修（B 类，登记未动，需逐项决策与实测）：B1 产品路径从未启用 Socket
KeepAlive（唯一调用点在 client 分支，产品三服务全是 TCP Server，
§5.56 要求服务器在 CONNECT 后开，60s/5s/3 参数空转）；B2 tcp_connect
返回值丢弃且 CONNECTING 不在对账范围；B3 net_listen_locked 全 8 Socket
读即清会吞别槽事件；B4 全局中断 bit0-3 从不消费、get_unreach_info 零
调用；B5 getsockname 的 s_addr 与本层约定相反致 FTP 日志设备 IP 反序
（PASV 双重反转恰好正确，勿误判）；B6 三处判据只看 byte1 未按 byte0
门控；B7 Phase5 单次写 4093B；B8 Phase4 缓冲块与 sock4 交叠；B9 杂项。

验证：产品构建 0 错 0 警、Code=196912（+124B，写路径两条新日志）；
测试路径（PHASE2/3/4 打开）单独编译 0/0；内存快照已刷新；doc-links
EXIT=0、无 U+FFFD、pre-commit 全绿；@test 闭环 PASS（戳匹配 + 回读无
差异 + 锚点 x1 + 548ms）。
 2026-10-12 00:20:17 +08:00
wandering1 bca6cc694c test(net): TC-NET-204 定案 Trap 07——disconnect→close 不卡死，真因是 bit3 
Trap 07（2026-07-19 写成"2025-07"）断言"disconnect→close 让 Socket 卡
FIN_WAIT_2 数分钟、因为 close 不发 RST"。新增定案用例 TC-NET-204（Phase 2
硬件层，同一 Socket、同一 PC 回显、FUN_PARA=0x08，三模式 × 5 轮 = 45 项判定
全过）做受控对照，实测推翻其机制说法、保留其做法：

  A close                → 回 CLOSED 0/0/150/0/0 ms，重开 5/5 OK
  B disconnect → close   → 全部 +0 ms，重开 5/5 OK（"卡死"未出现）
  C disconnect（不 close）→ 10 s 内从未回 CLOSED，byte0 恒 0x05、byte1 0x00；
                            直接 open → 0x20 FAIL（5/5），补 close 后 +0 ms

三条推翻：① FIN_WAIT_2(06H) 全程未出现（15 轮 × 9 采样点），实测过渡态只有
TIME_WAIT(0AH)；② 手册无 RST 语义（§5.35 只说 close 前自动断链），且主动发
FIN 先进 FIN_WAIT_1 才进 FIN_WAIT_2，原说法跳拍；③ 观测越过了 byte1 的语义
边界——§5.22 byte0 只有 00H/05H，官方 SDK 注释明确 byte1 仅在 byte0=OPEN 时
有意义，而当年代码判据用的是正确的 byte0，break 后照样打印 byte1，于是"已
CLOSED 下的残留读数"被读成"卡在某个 TCP 态"。

真因：FUN_PARA bit3 SOCKET_CLOSE=1（§5.52 ②）下产生 DISCONNECT 后芯片不关
Socket、不清缓冲，Socket 停在 0x05(OPEN)/0x00(TCP_CLOSED)，此时 open_socket
必返 0x20 FAIL——即历史那条 Phase 2 open_socket: 0x20 / socket 未完全关闭。
拉回 CLOSED 的动作是 close，与 RST 无关。

git 佐证：ch395f_tcp_disconnect() 自首个提交起只有定义、零调用点（含全部分支
与 11 个悬空提交），"disconnect→close" 从未进入提交代码；当时驱动已轮询
GET_CMD_STATUS（4 s 上限），也不是"命令没等完成"。

做法保留，理由换成三条有支撑的：§5.35 close 已自动断链故 disconnect 多余；
disconnect 制造的 DISCONNECT 事件在 bit3=1 下须我方消费/预清（Trap 14/17/22）；
它把芯片推进 closing 过渡态、重开需沉降（Trap 09）。本轮 15 轮重开均未观察到
残留 DISCONNECT(0x10)——close 顺带清掉锁存，这才是"直接 close"安全的原因。
另消解 Trap 17 与 Trap 07 的旧矛盾：实测支持 Trap 17（close 走 FIN teardown、
0~150 ms 可见 TIME_WAIT），不支持 RST 说法。

文档：Trap_Records.md 加 Trap 07「定案更正」整节 + 改写「驱动关键点 → TCP 关闭
重连」速查清单（删 RST 说法、补 byte0/byte1 口径与 0x20 陷阱）；Test_Guide.md
新增 TC-NET-204 用例表（前置含 tcp_server --timeout 900 这条坑：首连后连接
间隔 >60 s 服务器会自行退出）。

验证：测试构建 0 错 0 警、Phase 2 74/75（唯一 FAIL 是 TC-203 环境守卫，PC 服务
未及时关闭）；宏已还原，产品构建 Code=196788 与 HEAD 一致（用例全在测试宏内、
产品零足迹），@test 闭环 PASS（戳匹配 + 回读无差异 + 锚点 x1 + 590 ms）。
pre-commit 全绿（test-cppcheck / doc-links / no-mojibake 均 Passed）。
 2026-10-11 21:40:45 +08:00
wandering1 d758d5cd7b docs+net: FUN_PARA 定案 0x08——bit0 保留位证伪，Trap18 定案更正 + N-31 
CH395F FUN_PARA 的 bit0 之争定案：取 0x08（bit3 SOCKET_CLOSE=1，bit0=0）。

证据（一手，按强度）：
- 官方手册 V2.2/V2.3 与旧版 V1C/V1E/2020 版 §5.52 位表：bit0 一律
  「保留,必须为0」，任何版本都不存在「bit0=多 Socket」这一行。
- 官方 SDK CH395INC.H:349-353 位宏只有 bit1/3/4/7/8，无 bit0 宏。
- 官方例程直接反例：EXAM5_TCP_Server 传 0x02（bit0=0）却给 Socket 0~7
  全部配缓冲；EXAM11_FTPClient 直接传 0x08；全 EVT 包无一处 0x09。
- 手册命令章前言：8 Socket 是芯片原生能力，靠 _SN 索引寻址；§5.45
  真正的门槛是缓冲分配（Socket 个数 >4 须重分配缓冲）。
- 概念讹传源是 bit1 FUN_PARA_FLAG_TCP_SERVER（服务器多连接，§9.2.6）。
- 互联网检索无任何出处称 bit0 为单/多 Socket 模式。

Trap 18 的「bit0 决定 Socket 数量」是推论而非实测：无日志、无 TC 号，
且当年 Socket 1~7 未显式配缓冲（Trap 01/02 混淆因子未排除）；TC704
40/40 与结论出自同一提交，属自证，不构成 0x08 的对照。

改动：
- net_socket.c：0x09→0x08（原为未提交改动，现已过编译门禁）+ 版本留痕
- ch395f_reuse_bench.c：0x09→0x08，与生产 net_init 同构
- net_test_task.c：TC704 注释纠正（Socket 可用性不依赖 FUN_PARA）
- Trap 18 新增「定案更正」完整证据链；Trap 25 疑点改判为定案
- Test_Guide / 产品需求 / 架构总览 / BSD 调用关系：0x09→0x08 改口径
- 待处理内容.md 登记 N-31：0x08 下多 Socket 台架复测（TC704 降并发
  ≤5 + FTP 回归），补 Trap 25 销项时漏登记的尾巴

验证：@build 0 错误 0 警告；check_doc_links --all 通过；无 U+FFFD。
 2026-10-11 20:05:22 +08:00
wandering1 d1e6bb4ba7 W5波+N-19收口：FTP鉴权落地、Trap25三连定案修复(N-30)、N-20/N-23/N-26 
N-19 FTP 鉴权：
- lftpd_auth（USER/PASS 状态机 + 连续5次失败锁60s）+ SHA-256
  (user||pwd) 口令哈希；config.ini [ftp] 段 user/pwd_hash/write，
  出厂 admin/admin 在用有启动告警；lftpd_log.c 删除并入 lftpd_auth
- ftp_cfg 配置读写；台架 ftp_auth_bench.py 13/13

N-30 / Trap 25（CH395F_Trap_Records.md 四次定案全记录）：
- 修复1 closed-with-data accept：客户端发完正常 FIN 后芯片按
  FUN_PARA(0x09) §5.52② 保留 Socket+RX 缓冲，旧代码把 CLOSED 一律
  relisten 自毁缓冲 → STOR 必挂 425；改为接受"已关但可读"连接排空
- 修复2 丢 CONNECT 中断探针 net_lost_connect_probe + last_peer_port
  幽灵甄别（拆链窗口握手完成但中断丢失，双信源去抖补 accept）
- 修复3 send_list/send_nlst 批量单发：背靠背 ~60B 小段毒化芯片 TX
  （芯片报 SEND_OK 但对端全丢），整份目录一次性写入
- 证伪存档：固定沉降/Socket 轮换冷却/listen 门控（台架 v7 矩阵）
- 台架工具 test/board/ch395f_reuse_bench.{c,h} + host 脚本存档
  （不注册编译；实验分支 n30-chip-bench 保留）

N-20：Error_Handler 死循环降级（记录+复位路径）
N-23：scripts/check_registration.py 双端注册反向校验（pre-commit）
N-26：GD5F NAND 直 DMA 调用方缓冲窗口断言

验证：BUILD_OK 0/0；ftp_regression 连跑 4 轮 11/11（修复前
LIST#4/#7 100% 挂、STOR#2 曾 100% 425）；ftp_auth_bench 13/13；
@test 启动标记 PASS；ci_local L0+L0.5 全过；doc-links 通过。
登记簿 N-30 已销项。
 2026-10-11 18:50:24 +08:00
wandering1 f0300761ae 串口采集/测试去重：删 tools/serial_tool 与 test/host run_boot_test/verify_log 副本，引用改指 .dsh/skills 串口 skill 2026-10-10 15:13:23 +08:00
wandering1 e0b02d397c 修复 P2 全部 10 项：错误传播/竞态/门控/文档失真 
待办池 docs/待处理内容.md §3.2 的 10 个 P2 全部闭环；逐项落代码 + 注释说明。

P2-1  cfg_file: 受管键行超 CFG_LINE_TEST_MAX 拒绝保存（防重复键行）
P2-2  ch395f: DMA 失败传播状态 + 锁存通道故障 + 读不拷不可信数据
P2-7  net_select: LISTENING 不再恒判可读（消除 select 忙轮询地雷）
P2-8  time_sync: 核实 L3 pending 改写已闭环（net_recv_to 分片 + 总预算）
P2-9  sys_log: 挂载改幂等 + 卷锁，defaultTask 2s 重试建 /log
P2-10 sys_log: s_read_raw 纳入卷锁 try（读者/写者 unlink 互斥）
P2-11 net_task: RECONFIG 改 osEventFlagsWait 原子取走 + 清除
P2-12 app_cfg: APP_*_ENABLE 如实标注为未接线占位，删“开关”说法
P2-13 freertos: 产品构建 vTaskDelete(testTask) 回收 8KB CCM 栈
P2-15 download.bat: 先删旧日志 + 增“未产出日志”判定

P2-13 用 USER CODE 区回收而非生成区 #if 门控：生成区改动会被 CubeMX
重生成覆盖，本方案重生成不丢。P2-12 因产品定义 B0 未定、APP_NET_ENABLE
无单一接线点，按修复建议备选（删“开关”说法）处理。

验证：@build 0 错 0 警；主机单测 watchdog 39/39 + sys_clock 100/100 +
cfg_file 149/149（新增 TC-CFG-044）；pre-commit --all-files 17/17。
 2026-10-04 08:30:30 +08:00
wandering1 029437be89 台架执行《实机测试实施指南》步骤 3~7 并闭环 
步骤 3/4（IWDG V2/V4/V5 + 堆低水位 S11）：
- V2 任务饿死 stall 后 ≤2.5s IWDG 复位；V4 关中断死循环 ~4.9s 稳定复位；
  V5 30min 120×FTP 全 PASS、零 IWDG 复位。堆告警全程未触发（min_ever=4728B）。
- task_watchdog.c：stall 证据写盘会经 nand_ftl_wd_feed 喂狗 → 增 s_stall_evidenced
  每次 stall 仅取一次证据，避免"取证据"本身阻止复位。
- default_task.c：堆低水位告警（HEAP_LOW_WATER_B=3072）。

步骤 5（GD5F 错误通道 S9）：gd5f2gq5ue.c/.h + nand_ftl.c 错误码统一为 int32_t 并
全量检查返回值；套件回归 16/16 PASSED。
- test/run_all_suites.py：--forbidden 改为按套件覆盖（GD5F 用 "HardFault;assert"）——
  TC-GD5F-704 故意触发 [ERR] 回落轮询，统一默认值会误判 FAIL。

步骤 6（网络稳定性）：7.1 正常路径 ✅（V5 证据）；7.2 N-2 丢弃可观测性代码已具备、
49s 静默在 V5 未复现（降级低风险观察项）；7.3 N-3 待 PC peer。

步骤 7（工程卫生）：
- S5：新增 test-cppcheck 钩子（仅 warning，排除模拟器桩）。
- S4：新增 scripts/check_test_traceability.py（默认仅告警）。
- 待核实项 TEST_SUITE_SELECTED 实机核实 = 死代码（无使用点）；RTC 套件实际正常执行，
  真缺口 = 缺套件级汇总行 → sd2506_test_task.c 补 === RTC Tests: N/M PASSED === 并
  修正 Phase 级汇总累计问题；test_config.h 补齐 RTC 并注释"当前无引用"。

验证：产品 @build 0/0；pre-commit --all-files 17/17 Passed；
run_all_suites.py --suites RTC → PASS。
文档：实机测试实施指南 / SD2506_Test_Guide / 待处理内容 / 测试与架构改进建议 同步。
 2026-10-04 00:35:06 +08:00
wandering1 2055de0303 测试：落地测试架构改进 T-1~T-5（套件开关门禁/汇总行校验/通用 harness/公共断言宏/多套件编排） 
背景：L0.5 主机侧单测落地后复审测试架构，给出 6 条改进意见（P0~P3），
登记进 docs/待处理内容.md「测试与验证基础设施」后逐条实施。

- T-1(P0) 测试套件开关门禁：新增 scripts/check_test_suite.py + pre-commit 钩子
  test-suite-switch，默认要求产品构建（全部 TEST_SUITE_* 注释），跑套件回归用
  --allow-test-build / ALLOW_TEST_BUILD=1 显式放行。顺带把 test_config.h 中长期
  开启的 TEST_SUITE_CH395F 改回注释（仓库此前躺着的是测试固件）。
- T-2(P1) verify_log.py 增加 --require-suite-summary：要求
  "=== <名称>: N/M PASSED (failed=0) ===" 且 N>0，堵住"套件没跑到汇总行/
  断言数为 0 仍判 PASS"的盲区；run_boot_test.py 同名参数透传。不传参向后兼容。
- T-3(P1) 抽取通用 harness test/host/common/unit_test_harness.py（工具链探测/
  INCLUDE-LIB 拼接/wd4819/GBK 解码/退出码契约）；watchdog 运行器 170→55 行，只声明 TestBuild。
- T-4(P2) 新增 test/board/test_common.h 集中断言内核（TEST_CHECK_IMPL/TEST_REPORT_IMPL），
  4 套件各用一行宏绑定自身统计变量（保持 g_xxx_stats 独立、防跨套件串数）。
  刻意不 include dbg_log.h——否则冻结 DBG_TAG 默认值触发 #47-D 重定义警告。
- T-5(P2) 新增 test/run_all_suites.py 多套件回归编排，try/finally 无条件还原套件开关。

验证：@build 产品构建 0 错 0 警；4 套件逐一构建均 0/0；看门狗单测 39/39 PASS；
pre-commit 14 钩子全通过；编排脚本 dry-run/开关切换/异常还原均实测通过。
 2026-10-01 07:28:57 +08:00
wandering1 22559365b9 整理 App 与 test 目录：按职责分子目录并同步全库引用 2026-09-26 12:52:39 +08:00