wandering1
f754d59218
分层：流程与规范/ 单元测试/ 板级测试/ 专项验证/ 测试工具/ 测试数据/， 顶层只留新增的目录导航 README.md（归层判据 + 硬约束 + 本次处置记录）。 - 搬迁 28 个路径：测试数据三个目录 58 个文件为纯改名（R100，内容逐字节不变） - 全库引用同步 124 个文件：AGENTS / docs 索引 / skills / 门禁注释 / scripts - 门禁面：scripts/check_test_traceability.py 的 glob 改 rglob （分层后不递归扫描＝追溯门禁直接瞎掉） - scripts/rename_ref.py：收尾的 ℹ 提示在 GBK 代码页抛 UnicodeEncodeError， 让进程以退出码 1 收场而改写其实已落盘（RC 与真实结果相反）；改为把 stdout/stderr reconfigure 成 UTF-8，与 check_doc_links.py 等同法 - docs/文档规范.md §1.1 补「子目录文件过多时再分一层」；§3.6 补 rename_ref 搬整目录的两个实测坑：① 会改写目录内部文件的内容 ② 内部文件的 ../ 出链 不补层级（本次 23 个被误改的证据文件已按 HEAD 原始字节逐字节还原） - docs/README.md §6 改为与六个子目录一一对应，并补登原先漏登记的 「启动日志原子性复验流程」一行 - .cubemx_survival_baseline.json：App/util/task_watchdog.c 的注释路径也随分层更新， 该文件是存活审计的 watchdog-module 漂移锚点，按脚本自己的提示跑 --write 重建基线 （实测重建后仅 watchdog-module 一条哈希变化） - 铁律 4 例外（本次在任务树里改了单写者文件）：AGENTS.md 与 .pre-commit-config.yaml 只被 rename_ref 改写路径字面量（后者全在注释行）， 任务表块与钩子声明一字未动 验证：check_doc_links.py --sections-strict 覆盖全部 88 个改动 .md 全绿； check_test_traceability.py 输出与主树逐行一致；196 个文本文件无 BOM、无新增 CR、无 U+FFFD、无行尾空白；陈旧引用面由主树 25 处降到 6 处（无新增断链）。
4.0 KiB
4.0 KiB
name, description, whenToUse
| name | description | whenToUse |
|---|---|---|
| stlink-flash | ST-LINK 命令行烧录/复位/回读校验（自带独立脚本 stlink_flash.py，纯标准库，拷到任何 ST-Link+STM32 项目即用）：-P 烧录+复位运行 / -CmpFile 全片回读比对 / 只复位。封装"烧后必须 -Rst -Run + 回读校验"的铁律与 -CmpFile 复位目标等实测陷阱。 | 需要向 STM32 目标烧录 .hex/.bin、只复位重启目标、校验芯片内容与刚构建镜像是否一致、或排查"反复重下载芯片仍是旧镜像"类烧录假成功时。 |
stlink-flash — ST-LINK 烧录/复位/回读（独立可运行 skill）
执行体 = 本 skill 自带脚本 .dsh/skills/stlink-flash/scripts/stlink_flash.py
（纯标准库；拷整个 skill 目录到别的 ST-Link 项目即可用，不依赖仓库脚本）。
# cwd = 项目根目录
& $PY ".dsh\skills\stlink-flash\scripts\stlink_flash.py" list
& $PY ".dsh\skills\stlink-flash\scripts\stlink_flash.py" flash [hex] # 烧录 + -Rst -Run
& $PY ".dsh\skills\stlink-flash\scripts\stlink_flash.py" cmp [hex] # 回读比对（会复位目标）
& $PY ".dsh\skills\stlink-flash\scripts\stlink_flash.py" reset # 只复位运行
& $PY ".dsh\skills\stlink-flash\scripts\stlink_flash.py" hard # nRST 100ms 脉冲（CLI 拒 RM= 时自动降级为复位）
镜像缺省取项目档案 hex；ST-LINK_CLI 解析：--cli > 档案 stlink_cli >
$DSH_STLINK_CLI > $DTU_STLINK_CLI > PATH（显式设了但无效 = 立即报错，不回退）。
退出码：0=OK / 1=探针或目标错误 / 2=CLI 未找到 / 3=用法。
成功判据内置：flash = rc0 + Programming Complete；cmp = 行首 No difference found
（输出原样透传，serial-boot-test 的 readback_ok 默认值直接可用）。
本仓库
@download = 本 skill（2026-10-10 起为仓库文档口径）。原 MDK-ARM\reset.bat
（flash/cmp/halt/run/list 子命令）已并入本 skill 的
flash/cmp/reset/hard/halt/run/list 并于 2026-10-10 删除；@build/@download
两条旧批处理入口至此全部收敛到 skill（一个能力一个实现）。
环境变量 DTU_STLINK_CLI（未设回退 PATH；设了但无效 = 报错 exit 2）。
铁律与陷阱（实测教训）
- 烧录必须带
-Rst -Run，不可省略：裸-P会报Programming Complete，但目标核 处于死循环/异常状态时写入并不落地（芯片内容不变）——"反复重下载、芯片一直是旧镜像、 二分法失效"的根因。上层若做自动闭环，固件里加编译期身份戳（fw build: __DATE__ __TIME__）才能把这种假成功揪出来（serial-boot-test 的fw_marker机制）。 - 烧录后必须回读校验：
-CmpFile全片逐字节比对，No difference found才算真写入； 不一致 = 本次运行作废。 -CmpFile连接时会复位目标：板子当场重打一遍开机日志——在自动闭环里必须排在 串口日志采集之后，否则开机日志被截断、启动锚点计数误判成"中途复位"。- 只重启不烧录用
reset子命令（-c SWD -Rst -Run）；nRST 未接线的台架（3 线 SWD） 这是唯一复位手段——hard（RM=Hrst -HardRst PULSE=100）在部分 CLI 版本（v3.5.0 实测） 被拒，本 skill 会打印RESET_NOTE并自动降级为这条系统复位（仍按降级结果给 rc）。 - 探针在位先
list；Programming Complete但行为像旧固件 → 先怀疑缺-Rst -Run， 再怀疑 hex 没重编（对比 hex 时间戳）。 - 完整复位语义/故障排查（本仓库）：
docs/测试说明/测试工具/ST-LINK_CLI_复位使用说明.md。
与其它 skill 的衔接
- 编译 =
keil-buildskill（先 0 错 0 警再烧）。 serial-boot-test档案里flash_cmd= 本 skill 入口（如".venv\\Scripts\\python.exe .dsh\\skills\\stlink-flash\\scripts\\stlink_flash.py flash"）、readback_cmd="... stlink_flash.py cmp {hex}"、readback_ok=no difference found——闭环脚本已保证"回读排在采集之后"。