wandering1/STM32F4-Base
1
0
Fork 0
Code Issues 30 Pull Requests Actions Packages Projects 2 Releases Wiki Activity
Files
1780e5320bf81c03ec974af7e55aa2ce6c15a5f4
STM32F4-Base/docs/待处理内容.md
T

12 KiB
Raw Blame History

待处理内容（登记簿）

用途：跨文档的待办/观察项登记——台架与审计过程中发现、但不属于当前修复范围 （或 A/B 归因为既有问题）的事项，在此留档防丢失。每项带发现日期、证据与出处。 消化即销项：事项修复/关闭后，直接从本表删除该行（结论与证据应已沉淀进 对应模块文档/问题记录，此处不再保留），并同步清理其他文档对本编号的引用。 创建：2026-09-22（L3 pending 台架收尾时建立，AGENTS.md 既有引用自此落文件）。

网络（CH395F / net 层）

# 事项 发现 证据与现状 出处
N-2 49s 全系统日志静默（defaultTask/NAND syslog 排空停滞）——串口日志 49s 无行（testTask 10s 周期行/netTask 事件行/[STACK] 行全缺），期间 net 栈照常处理外部连接（FTP banner 92ms）→ 日志管线（defaultTask 排空 → NAND+UART）停滞，队列满后各任务日志行被丢；系统功能不受损 2026-09-22 17:23:52~17:24:41（L3 台架 F2 运行中，gen 181） A/B 归因：L3 不触碰 defaultTask/syslog 路径 → 既有存储侧现象。待办：① 复现条件定位（NAND 写/GC 长尾 vs UART TX 卡滞——对照 CH395F 无关的 SD2506 侧日志）② 日志队列满的丢弃计数/告警（现静默丢行，排障不可见）③ 与 S8（非阻塞日志）合并评估 错误码传播审计.md E-02 阶段二"台架新发现②"；链路延迟测试说明.md §6.7 注
N-3 L5 队列往返基线（1223/988µs）的 L3 后重验——L5 测 DONTWAIT 队列全程；L3 对该路径逐位不变、pending tick 无 pending 时为 µs 级指针读 → 机制上无影响，但基线数值属分片时代，严格重锁需跑一轮 Phase 13（需 PC peer） 2026-09-22（L3 收尾留档） 低风险：10ms/100ms 阈值余量 >8×；下次 Phase 13 窗口顺带重锁即可 链路延迟测试说明.md §6.4 L5 注¹

存储 / 日志管线

# 事项 发现 证据与现状 出处
S-1 defaultTask 静态最坏链余量贴线：2872B/4096（余量 1224B = 29.9% < 30% 判据，差 4.8B）——storage_bring_up → … → dhara GC → SPI 链，L3 前即如此（L3 不触 defaultTask 调用链） 2026-09-22（L3 产品构建栈报告） 处置方向二选一：栈 4096→4608（CCM 堆余量 4816B 可覆盖 +512B）或 GC 链缓冲局部削减；与 S8（非阻塞日志）并案评估 scripts/stack_report.py（L3 产品构建档）
S-2 N-2 消化后，台架 20MB 串口日志截头会丢早期 [STACK] 水位行——跨构建的"前后"栈水位对照建议固化 boot_log 快照（%TEMP%\opencode\boot_log_*.txt）进 docs/测试说明/ 存档目录 2026-09-22（L3 收尾发现：切片时代水位行已被截头，A/B 只能定性） 流程项，无代码改动 本文件 N-2 佐证
S-3 USART1 TX-only 结构根治（灭 ORE 僵尸机制）——ORE 锁存在外设软复位后毫秒级重锁（PA10 悬空 + RX 使能），是 2026-10-02 台架"背靠背 drain 拉长主循环 → 喂狗节奏饥饿 → IWDG 误复位"的机制根源。现仅有缓解（round-3 单次 drain 250ms 预算 + round-6 发送故障后 300ms 冷却），未根治 2026-10-02（台架 gen-288，见 控制台单写者日志设计说明.md §12） 待办：改 .ioc 令 USART1 为 TX-only（不使能 RX / PA10 不复用为 USART1_RX）→ CubeMX 重生成 → 跑 scripts/check_cubemx_survival.py。属结构性改动，需单开一轮并复跑台架闭环 子系统设计/控制台单写者日志设计说明.md §12（含 O4）；App/log/console_log.c 2026-10-02 修改记录
S-4 dhara 重试自旋残留——try_recover() 的 DHARA_MAX_RETRIES(8) 自旋在坏块密集时仍可能长时间占用 defaultTask（喂狗点） 2026-10-02（round 7/8 取证期观察） 低优先：现有 vol_lock + 喂狗节奏缓解；若台架再出"存储侧喂狗饥饿"再排期 Lib/dhara/map.c
S-5 可选全序列卷锁——现卷锁仅覆盖 syslog / cfg / lftpd 三条路径（vol_lock_wait(0) try 语义），其它潜在访问点（如 UI 读日志）未纳入 2026-10-02（卷锁落地时） 待评估：先确认是否真有第二写者；无则关闭本项 App/fs/vol_lock.{c,h}
S-6 dhara resume 回滚：复位后所有写入全部丢失 2026-10-02（round 9 取证） ✅ 已修：dhara_journal_resume() 的 epoch 锚点改为比较两个候选 epoch（回绕后锚"低地址=最新"）。详见 架构设计/STM32F4-Base存储架构说明.md §5.4.1。判定手法已固化为开机日志 Map head=… tail=… epoch=… Lib/dhara/journal.c 2026-10-02 本地修复注释

网络（二期排期，随第二档 #1）

# 事项 说明 出处
N-4 pending 机制二期：ACCEPT + SEND 阻塞路径 pending 化——E-06（accept 轮询计时失真）、E-20（lftpd 控制通道 errno 分类/501）、E-21（timeSync errno 分级）剩余分量共用该机制扩展；届时 L3/L5 基线再重锁、探针族扩充（close/reconfig/EOF/disconnect-during-pending）、看门狗接 selftest 留痕、模拟器差距清单 +1 一期（RECV）已落地并入主线：a45c0cb（+文档闭环 7ff2958）；架构现状见 Net层阻塞模型架构设计.md，二期设计基线与门禁见 下一步任务规划.md §3.1 同左 + 错误码传播审计.md 第二档 #2
N-16 A2/A4 专项场景台架验证待办（正常路径已实测零回归，2026-10-03）：① PHY 拔线负向测试——断链需断 DTU 侧线缆或关受管交换机端口（拔交换机侧线缆链路仍 UP，CH395 对交换机拓扑），断链后复位验证 PHY: DISCONNECT + 自检台账 comms fault 降级放行；② A2 芯片级 net_init 失败分支（需 SPI 故障注入，验证 net init fail 自检 + 30s 重试恢复）；③ A4 短写压测（需远显客户端 + UI 推流压力，验证 remo send short 告警/阻断/重连恢复） 2026-10-03（台架；台架拓扑 = CH395↔交换机，拔线操作受限） 实机测试实施指南.md §3.2 真机判定表

可靠性与自恢复

# 事项 说明 出处
N-03 引入独立看门狗（IWDG）+ 任务心跳位图——现状全库无看门狗（HAL 驱动源码也不在仓库），任何形态死机不可自恢复；另 configASSERT 为关中断死循环（连日志都不打）。代码已落地并编译通过（2026-09-29）：CubeMX 生成 IWDG（Prescaler=64/Reload=1249）+ App/util/task_watchdog.{c,h} 心跳位图 + 6 任务埋点 + RCC_CSR 复位原因锁存 + configASSERT 改造 剩台架验证（故障注入 V2/V4、长跑 V5 ≥30 min）；文档 §10 第 7~10 步待办 见 子系统设计/看门狗设计说明.md（§10 有实施状态表）
N-03a configASSERT(x) = taskDISABLE_INTERRUPTS(); for(;;);（Inc/FreeRTOSConfig.h）→ 断言时无任何输出 ✅ 已修（2026-09-29）：改为 vApplicationAssertFailed(__FILE__, __LINE__)，打印文件名+行号后主动复位（Src/freertos.c）；宏已迁入 USER CODE BEGIN 1 区防重生成丢失 同上 N-03b
N-03b 启动段（app_main_init + defaultTask bring-up）在新方案下无看门狗保护 显式代价（未变）：看门狗设计说明.md §4.5 决策 C + §9 R1；该段死机表现为"无输出 + LED 不闪" 同上 N-03c
N-03c CubeMX 重生成会覆盖 USER CODE 标记区之外的定制 ⚠️ 2026-09-29 两次重生成实测确认：首次覆盖 4 处、第二次覆盖 5 处（P0 Src/iwdg.c 自动启动、P1 HardFault_Handler 打回空死循环、P1 FreeRTOSConfig.h 两个加固宏被删、P2 freertos.c 中文注释）。✅ 已建立自动检出：scripts/check_cubemx_survival.py（18 项清单 + 哈希基线，已挂 pre-commit）——第二次实测准确检出全部 5 处。⚠️ 关键发现：CubeMX 换了一代中断模板，"生成区外的自造标记区"同样不被保留（详见设计文档 §10.1）。今后每次重生成后跑一次该脚本即可 本次实施记录
N-03e 判定状态机缺主机侧纯逻辑回归（改动后只能靠真机/模拟器才发现回归） ✅ 已落地（2026-10-01）：硬件访问收敛到薄平台层（App/util/task_watchdog.h 末段声明 3 个 __weak 钩子），新建 test/host/watchdog/ 单元测试（39 用例，#include 生产源码 + 强符号覆盖钩子），挂 pre-commit watchdog-unit-test 钩子。MCU 端行为零变化（@build 0/0）。新增测试分层 L0.5 见 测试说明/看门狗单元测试说明.md
N-03d 3 个次要 Fault（MemManage/BusFault/UsageFault）为空 while(1)，死机静默 ✅ 已修（2026-09-29）：升级为与 HardFault 同一套崩溃采集（手工 __asm Handler → per-fault C 入口 → hard_fault_report(tag, frame)，日志打 [ERR] MEMFAULT/BUSFAULT/USAGEFAULT + 全量现场）；新增 fault_handler_enable() 使能 SHCSR 后三者（默认只开 HardFault，否则故障被升级、看不出根因），在 app_main_init() 第一行调用。刻意不启用 UNALIGN_TRP/DIV_0_TRP（避免把普通 bug 升级成死机）。@build 0/0；审计 18 通过 / 1 警告 / 0 失败 见 子系统设计/看门狗设计说明.md §10.2

测试与验证基础设施

来源：2026-10-01 测试架构评审（L0.5 主机侧单测落地后的复审）。 P0/P1 属闭环缺口（会漏检真实故障），P2 属工程效率（减重复、降误提交概率）。 实施依据见 测试说明/测试开发标准流程.md；消化即销项。

已销项（2026-10-01，同日实施）：

  • T-1（P0）：scripts/check_test_suite.py + pre-commit 钩子 test-suite-switch ——默认要求产品构建，跑套件回归用 --allow-test-build 显式放行。 顺带修复：test/board/test_config.h 长期开启的 TEST_SUITE_CH395F 已注释（现为产品构建）。
  • T-2（P1）：verify_log.py / run_boot_test.py 新增 --require-suite-summary ——要求 === <名称>: N/M PASSED (failed=0) === 且 N>0。
  • T-3（P1）：通用 harness test/host/common/unit_test_harness.py； 看门狗运行器 170 行 → 55 行声明式。
  • T-4（P2）：test/board/test_common.h 集中断言内核，4 套件绑定自身统计变量。
  • T-5（P2）：test/run_all_suites.py 多套件编排（try/finally 无条件还原开关）。
  • T-6（P3）：Gitea Actions CI 落地（补办，2026-10-01）。远程为 Gitea 1.25.4（gitea.bitnasdaq.vip/wandering1/STM32F4-Base.git），已启用 Actions → 新增 .gitea/workflows/ci.yml：两个 Windows job，l0-gates（pre-commit run --all-files，检测不到 Keil .map 时自适应跳过 mem-numbers）+ l05-host-unit-tests（遍历 test/host/**/run_unit_test.py，缺 MSVC 则打 WARNING 降级跳过）。刻意不跑 @build（需 Keil 授权）。 另新增 scripts/ci_local.py（本地跑与 CI 等价的门禁，自动选用装了 pre-commit 的解释器；退出码 0/1/2 与 CI 对齐）。 登记依据见 测试说明/测试开发标准流程.md §9；覆盖边界与"刻意不含项"见该节与 ../.gitea/workflows/ci.yml 文件头。

⚠️ 部署前置（未完成，需人工确认）：CI 仅在 runner 就绪后才真正生效—— ① Gitea 实例 [actions] ENABLED = true；② 注册一个 Windows runner（labels 含 windows），装 Python 3.x / cppcheck / pre-commit / MSVC（VS C++ 工具链 + Windows SDK）。 runner 未就绪前，提交前仍须在本地跑 scripts/ci_local.py 或 pre-commit run --all-files 自查（这是 L0 的唯一保障，不能因"已配 CI"而放宽）。

# 事项 优先级 问题与证据 处置方向 出处
（暂无待办） — — — — —
Reference in New Issue View Git Blame Copy Permalink