wandering1
bca6cc694c
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）。
test/board/ — 板端测试套件
⚠️ 编入固件的测试代码（由 testTask 执行）。这些
.c已注册到 Keil 工程MDK-ARM/STM32F4-Demo.uvprojx，占用 MCU 的 RAM/Flash。
文件一览
| 文件 | 测试对象 / 作用 |
|---|---|
test_config.c/h |
测试任务配置：TEST_SUITE_* 套件选择开关（互斥）+ ENABLE_DESTRUCTIVE_TESTS |
test_common.h |
公共断言内核：test_stats_t + TEST_CHECK_IMPL/TEST_REPORT_IMPL；各套件用一行宏绑定自身统计变量（T-4） |
ch395f_test_task.c/h + ch395f_test.h |
CH395F 以太网（硬件层 Phase 1 |
gd5f_test_task.c/h + gd5f_test.h |
GD5F2GQ5UE SPI NAND 存储 |
sd2506_test_task.c/h + sd2506_test.h |
SD2506 RTC |
storage_test_task.c/h + storage_test.h |
存储性能 |
net_test_task.c/h |
网络层测试 |
net_latency_test.c/h |
链路时延探针（DWT CYCCNT 时基，MCU 专属） |
⚠️ 构建约束（AGENTS.md 详述）
- 套件互斥：
test_config.h的TEST_SUITE_CH395F/STORAGE/GD5F/RTC一次只能启用一个 （违反则#error）；全部注释 = 产品构建 - ⚠️ 测试固件不得静默提交：
TEST_SUITE_*开关受 pre-commit 钩子test-suite-switch门禁——默认要求全部注释。跑完套件回归务必改回产品构建再提交（2026-10-01 实测已提交 HEAD 里TEST_SUITE_CH395F就是开启状态，纯靠人记得改；故补此门禁）。确需提交测试构建时用ALLOW_TEST_BUILD=1 git commit ...或python scripts/check_test_suite.py --allow-test-build显式放行 - 破坏性用例默认关闭：
ENABLE_DESTRUCTIVE_TESTS（默认注释）控制写/擦 NAND、格式化、 坏块注入。关闭时为只读模式（横幅mode: READ-ONLY），可随时在在用设备上跑 - ⚠️ 实测一轮破坏性 GD5F 运行即让 dhara 多记一个坏块（容量下降且需全片擦除恢复）—— 只在产线首启或明确需要时打开
- CH395F 套件：硬件层与 NET 层模式互斥
- 总线独占：CH395F 硬件层模式下 netTask 自挂起，testTask 独占 CH395F
添加新测试套件
- 在
test_config.h加开关（并入互斥#error检查） - 新建
<模块>_test_task.c/h - 注册进 Keil 工程（
<FilePath>..\test\board\xxx.c</FilePath>） - 跑回归：
@test（.dsh/skills/serial-boot-test/scripts/run_boot_test.py）
相关文档
- 测试指南：
docs/测试说明/CH395F_Test_Guide.md、GD5F2GQ5UE_Test_Guide.md、SD2506_Test_Guide.md、FTP_Test_Guide.md - 套件配置：
AGENTS.md「测试与验证」章 - 容量恢复：
docs/测试说明/存储维护与容量恢复.md