wandering1
|
7708f12c10
|
fix(ui/screenlink): 按键应答扣到按键后画面,反馈典型 250-450 ms 降至 70-135 ms
按键召唤答的是按键前的旧帧:uiTask 还没消化键答案就发走了,新画面
只能等下一次周期召唤(280 ms/轮)才带得出——真机反馈 250-450 ms 的
主构成(根因账本 docs/子系统设计/屏板链路设计说明.md §7.1)。
改动(用户批准范围 A+B+C;屏板固件未动,决策三不变):
- sb_link:按键召唤改为只入队不起发;uiTask 同拍重绘并组帧成功后交
凭据(sb_link_key_rendered),TIM3 1 kHz 的 sb_link_ms_tick 以 ≤1 ms
放行新帧。140 ms 截止(SB_KEY_RESP_MAX_MS,+59.6 ms 线上 <205 ms
屏板放弃线)保底发旧帧,"一召一答"契约不破;线忙时同旧丢单、
不留扣件。起发两中断源(USART1 IDLE/TIM3)共用 sb_tx_kick,
"判忙→占位"在 PRIMASK 临界区原子完成。
- ui_task:排空注键挪到组帧之前,注键→即派即绘→组帧同拍闭环;
组帧返回 BSP_OK 才交重绘凭据(BUSY 拍帧还没反映按键)。
- ui_port:注键单槽改 8 深环(连按不再互相覆盖,满丢最旧+计数);
新增 ui_port_service_keys:同拍 lv_indev_read + lv_refr_now,
省掉 indev ≤20 ms + 刷新 ≤20 ms 两段等待。
- ui_menu_view:菜单移动选中只失效新旧两行带(黄金参考零像素变化),
滚动/异常回退整框失效。
- simulator:窗口循环 sleep 扣除本轮已耗时(原先无条件睡满
lv_timer_handler 返回值,叠加 Windows Sleep 15.6 ms 粒度放大观感)。
- 串口 TX 上报新增 dfok/dfold(凭据放行新帧数/超时保底旧帧数):
dfold 连涨 = uiTask 被饿 ≥140 ms 的直接现场证据。
验证:test/host/sb_link 164/164(新增 18 条:不立刻起发/凭据放行/
140 ms 截止保底/忙时不留扣件/陈旧凭据不放行等边界);菜单 8 状态 +
内容页 66 张黄金像素 PASS;Keil @build 0 错误 0 警告(两次);
BOM 99 文件无漂移、代码规范、doc-links 本次文件零问题、cppcheck PASS。
文档:屏板规划文档已被主干收编进设计说明,延迟账本落
docs/子系统设计/屏板链路设计说明.md §7.1,并同步 §4 口径、§8 接口、
§9.1 单测台账 146→164、§10 坑账本补条。
RAM 台账(分支不跑 --write,并行分支提交约定):本笔盖戳行
RW_IRAM1 94,336 B (72.0%) / RW_CCM 57,376 B (87.9%),较上一台账行
+4,400 B——为距上次台账构建以来分支累计差(含批 3 状态灯等未盖戳
提交),非全部本笔引入;本次自身增量按对象计为 ui_port.o +12 B
(8 深键环+丢计数+indev 指针)与 sb_link/o 数十字节级。
gate: only mem-budget/mem-numbers pending lead ledger backfill
(合并落主干后 Lead 统一 --write 回填受管区)。
|
2026-10-30 09:50:31 +08:00 |
|
wandering1
|
f754d59218
|
docs(测试说明): 按用途分六个子目录并同步全库引用
分层:流程与规范/ 单元测试/ 板级测试/ 专项验证/ 测试工具/ 测试数据/,
顶层只留新增的目录导航 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 处(无新增断链)。
|
2026-10-30 07:16:07 +08:00 |
|
wandering1
|
1166ab1c2e
|
fix(adc): 挂 DMA 前关闭 ADC,消除乒乓缓冲 +2 格相位旋转
问题:ADC1 在 MX_ADC1_Init() 里使能,而 DMA 在 app_main_init() 步骤
4b 才挂载,中间隔着 GD5F 全片 BBT 扫描(数秒)。台架同一次开机内用
无 DMA 单通道逐路取真值、与 DMA 路径对照,得 9/9 完美置换:乒乓缓冲
从 rank 3 开始搬,槽 i 装的是 rank ((i+1) mod 9)+1,整体错开 2 格。
表象是"接地 AIN2、UB 却读到别的通道的值",极易误判为映射表写错或
注入点标签不对。
修法:新增 adc1_disable()(Src/adc.c 的 USER CODE BEGIN 1),在
app_main_init() 步骤 4b-pre 调用,把 ADC 置为关闭态,使能动作交给
HAL_ADC_Start_DMA() 内部完成(它自己 __HAL_ADC_ENABLE + 等 Tstab
约 20 us,紧接着开 CR2.DMA 并启流),使能与搬运之间不留可观测间隔。
顺序不可调换:本调用必须严格早于 adc_input_init()。
台架验证:在 MX_ADC1_Init() 末尾关闭 4/4 次、在 4b-pre 调本 API
3/3 次,均 UB=0;同开机对照差值 <=4 码(修前 7/7 次 UB=783~786)。
文档:ADC采样节拍设计说明.md 新增 4.5 节(9 行证据表、判据陷阱、
根因与修法)与设计铁律第 8 条。
台账:Flash 261,764 -> 261,928 B(+164,新增函数),RAM 无变化;
CubeMX 存活审计基线重建(adc1-calibration-impl / adc1-dma-link
两项漂移均属本次有意改动,锚点已逐条复核在位)。
|
2026-10-27 20:42:06 +08:00 |
|
wandering1
|
b623a406ad
|
fix(栈·存储·UI 收尾): 断掉临界区↔断言幻影环回到 1,464,标定门控单点化,卷锁五态可观测
这四笔在主树里已经互相纠缠(同一次 @build 编译、同一份 .htm 度量),拆成四笔就不
存在任何一个被真编过的中间态,所以合一笔入库;下面按模块分段陈述,作者与出证归属
逐段写明。
—— 一、崩溃证据路径的整行独占收尾(log-maint-writer,task-26)——
上午那笔 1d4b6a17 之后,stack_report 报 iec104Task 静态最坏链 1,544 / margin 1,016,
低于 1,024 的 ISR 底线。真因不是新增局部缓冲,而是本模块与内核临界区之间新长出
一条环:taskEXIT_CRITICAL ⇒ vPortExitCritical ⇒ configASSERT ⇒ vApplicationAssertFailed
⇒ dbg_console_write_raw ⇒ 回到本模块。armlink 把这一整坨计入**每一个含临界区的
任务链**(vApplicationAssertFailed 的 Max Depth 由约 40 B 涨到 128 B + In Cycle),
所以九条链同涨约 80 B——同涨本身就排除了任何单个调用方。
改法两处:① 本模块三处窗口(取凭证 / 还凭证 / 整行入环)改用 CON_CRIT_ENTER/EXIT
(PRIMASK 保存恢复到局部变量;注释写全为什么不能直接 __enable_irq()——嵌套时会
替别人打开任务级临界区——以及屏蔽面变宽是有意为之);② 异常/终点钩子里那对
自证空转的 begin/end 摘掉(异常态 begin 放行但不持有、end 是幂等空操作,调它只有
成本没有收益),任务态 STALL 行保留 begin/end,这个区分写进两处注释与文档 §4.4.1。
实测四棵树逐个 .htm 解析(身份钉 tree + Linker run 时刻 + 产物来源):A=77779d49
链 1,456;B=1d4b6a17 链 1,464 / margin 1,096 PASS;C=含未提交钩子接线的工作树
1,544 / 1,016 FAIL;D=本轮修复后(Linker run 22:52)回到 **1,464 / 1,096 PASS**,
九条链齐降 80 B。断环图证:vPortExitCritical 由 136 B + In Cycle 变 8 B 且不再
In Cycle,con_tx_release 子树 152→8;Error_Handler 回到 280 + In Cycle = A 树同值
(既有发送环无人拆动)。顺带删掉 Src/freertos.c 崩溃路径里最后一个 HAL_Delay(200)
(该文件真实调用现为 0)。
测试:console_log 152→**153** 条(只增不减);换钉不删防——015 现在钉「PRIMASK
窗口 2 次、深度 1、内核临界区 0 次」,新钉 015c 绝不等待,160 注入点搬到
con_pm_hook,176 强化到未调度路径连 PRIMASK 窗口都不开;红线水位
con_pm_at_tx_max 与 con_uart_crit_at_tx_max 双 0;判据⑦(延后的行与当场直发逐
字节相同)170b/171/178 仍全绿。作者自报并纠正一处:换钉时曾把 TC-CONLOG-015b 改
编号,而 015b 在生产注释与文档里都被引用——已恢复「编号不退役、语义搬过去」。
覆盖率 App/log/console_log.c 199/200 → 256/257 行、21/21 函数(只增)。
—— 二、未标定闭锁判据收成单点访问器(ui-param-writer,task-16)——
「UA/UN/IA 三相 VALID 全置位才允许跑判据」这条门控原先在两处各自镜像实现
(protect_task.c 的 s_cal_locked 与 ui_data_feed.c 的 feed_cal_block),改一处另一处
静默失效且无门禁可照。现新增 adc_cal_prot_blocked() 落在 App/algo/adc_cal,DTU_BENCH
特例收进一处;两个消费者同批改调、本地副本删除。作者还查实并纠正了我先前一句
错判:全仓 App/app→App/task 的 include 实为 0 条,故访问器不能落在 protect_task。
新增 TC-ADCCAL-018 八条(含冷启动即闭锁),adc_cal 套件 99/99。
—— 三、共享卷锁五态可观测性(ui-param-writer,task-17)——
原状比登记簿写的更糟:五个可区分态(未调用 / try 超时 / 分片超时 / fail-open /
未持锁却 release)生产侧零留痕,且 vol_lock.c 的返回值注释与代码相反——
fail-open(锁没建成、互斥已失效却在读写盘)被返 1 **谎报成取到锁**,而那正是
vol_lock.h 记录的台架实证故障(并发写坏 FTL → 喂狗点饥饿 → IWDG 误复位)的前置。
锁层加四个 volatile 计数(16 B 静态,零新局部、零新 callee、零日志、零 FatFs)与
不取锁的 vol_lock_get_stats();13 处 try 调用点一字未动。**刻意不在锁层记时刻**:
记时刻要读 tick,等于给 defaultTask 取锁链添帧——诊断不值那几个字节;消费方若
自盖时间戳,那只能是被观测到的时刻而非发生时刻,.h 里已写明不得写成首次/末次。
四套本地假件各加 s_last_wait_to(字段名逐字一致),把「喂狗点取锁一律 timeout=0」
与「ftpTask 分片一律 100 ms」从注释纪律升级成会 FAIL 的断言;红-绿反证:临时把
sys_log_mcu.c 的 0u 改 50u → TC-SYSLOG-010/012 双红,把 lftpd_io.c 的 100u 改 0u →
TC-LFTPIO-034 红,两处按原串改回并用 SHA-256 证明逐字节还原。TC-VOLLOCK-015~019
共 45/45(无新桩)。
—— 四、UI 死接口清理(ui-maint-writer,task-6 收尾)——
删掉 ui_data_maint_ready():全仓零消费者、只有它自己的用例在读。**更值得记的是
它为什么能活过一整轮评审**:头注释写的是「页面用它决定这页能不能操作」,而页面
从来没用过它——注释陈述的是意图,评审读的是意图,门禁读的是可达路径,两者都不
反驳「意图未实现」。作者对「连用例一起删」做了显式抗命:TC-UIDATA-025 的 13 条里
只有 4 条读那个死口,另 9 条钉的是真防线(六口未注入安全返回 / 残表整表拒绝 /
被拒不覆盖已生效的好表),故删冗余的 025a、把 025i/025k/025m 换成用 reset_req()
的可观察返回值判定,性质不丢。ui_data 套件 244 → 243(净减 1),黄金 40 页与
池 5448 B 未变(该刀零像素影响,参考图无 diff)。
—— 门禁与未跑项(本笔如实留账)——
cubemx-survival 基线已 --write(漂移 6 项全部是上述意图内区域:断言/栈溢出钩子
实现、看门狗模块行等),基线文件同笔入库,随后 --check 通过。
本笔未跑的钩子只有两条:mem-numbers 与 mem-budget——磁盘 .map 出自 22:52 那次
构建、含尚未入库的 UI 与工具改动,与 HEAD 台账必然不同码;按仓库既有约定允许
--no-verify + 正文留证,回填在紧随的台账一笔统一做(含 ram_baseline --update 与
覆盖率基线两条 [NOTE]:ui_data.c 65→316、iec104_comm.c 36/36)。
两条已挂着的账:① id-check 不可判定引用 1,162 / 上限 1,166,**余量只剩 4**,
主要吃进者是我今天推进的 UI 那笔(68 条文本断言的注释引用),账在 Lead;
② 崩溃注入腿(故意复位)台架复验未跑,需先由代码道提交触发器,且判据只判原子性
不判 [ERR]=0——IPSR 路径的主张归主机侧套件,硬件照不出来。
产物身份(按 D 表要求钉死,避免数字与树脱钩):本笔包含的固件树就是那张 D 表对应的
那一棵——MDK-ARM/.../STM32F407-Demo.htm 的 mtime = 2026-10-26 22:52:12(.htm/.map 按
约定不入库,故把时刻写进正文)。提交前在本树复跑 stack_report.py:exit 0,
iec104Task 1,464 / margin 1,096(42%)PASS、defaultTask 3,040 / 2,080(40%)PASS,
与 D 表逐项一致;本次运行不含任何未提交固件源码之外的新改动。
|
2026-10-26 23:31:05 +08:00 |
|
wandering1
|
0f7b5a87fb
|
chore(编号): 存量编号全量转语义短语,门禁识别面与语料同批重打
登记簿、文档与代码注释里的存量字母加数字编号(N-x / S-x / T-x / E-x / A-x / 卡号)
一律改写为语义短语,净删 2,028 处引用;删除基线与待确认、并行分道方案、排期详述、
采集保护收尾 4 篇(内容已并入 docs/任务规划/README 与登记簿)。
门禁机器与三张账同批重打:check_ids.py 新增变更记录行豁免与第二根护栏
undecidable_total_ceiling;check_test_traceability.py 只加 stdout/stderr UTF-8
reconfigure(TC_RE 未动);check_cubemx_survival.py 的 --write 固定 newline=LF;
id_registry / id_aliases(+19 条 retired-to-phrase)/ id_known_backlog 重打。
test/ 56 个文件同步 TC 标签语义化,其中 18 个 TU 改了 CHECK / printf 里的标签文字,
是本批唯一改变构建产物的文件集合。
为什么合成一笔、不拆四笔(实测撞闸,非偏好):pre-commit 跑钩子前会 stash 未 staged
部分,拆开后中间提交必然是「新规则 + 旧语料」——实跑可判定 85.15% < 基线 86.00%、
不可判定 1,453 > 上限 1,166,编号门禁直接拦下。编号识别面与它描述的语料只能同码移动。
实跑基线(工作区全量):754 文件 / 8,230 处编号字面量 / 可判定 7,079 = 86.01%
(基线 86.0%,容差 0.1pp)/ 不可判定绝对数 1,151(上限 1,166)/ 校验 1-6 错误级 0 /
告警 = 悬空 2(App/algo/freq.c 的 S2,属 §4.4 同号不同义)+ 孤儿 50。
基线从 84.0 抬到 86.0 的理由见 docs/门禁说明/id-check.md §7.6:本批真删了 2,028 处
引用,可判定面随真实内容上升,不是把分母做小。同批新增排除 docs/硬件平台/ 语料,使
识别面少 264 处——芯片手册位号与网表料号不属编号空间(registry 有 excluded_paths_note)。
⚠ 余量只剩 0.11pp(约 10 处)与绝对数 15 处:把「可判定的引用」改成散文会立刻撞第二
根护栏。另遗留一项:id_aliases 里 retired 的 N / S / T / A 别名没有 scope(U1~U5 有),
今后有人新写一个 A-4,校验 3 不会响,只能靠人,建议下批补 scope。
固件不变证据:115 个 .c/.h 剥注释并归一字符串后与 HEAD 逐字节全等,残留代码差异 0;
App / Src / Drivers 的字符串字面量零改动。@build 0 错误 0 警告;40/40 主机套件、2,889
断言全通过;覆盖率 line 89.2% / func 92.6%;pre-commit 48 钩子 --all-files 全绿;
check_doc_links --all 通过(176 文档,章节引用无法判定 0);逐字节卫生核过:14 个带
BOM 文件与 HEAD 一致、0 个 CR、0 个 U+FFFD,字符串字面量纯 ASCII。
.cubemx_survival_baseline.json 的 watchdog-module 哈希 56bf27 变 2bb051 属合法:
Src/freertos.c 的 USER CODE 区内只有注释文字随编号改写,代码未变。
同批带上体积同码凭证与 RAM 台账行(@build 之后盖戳):RW_IRAM1 79,008 B / 60.3%,
RW_CCM 57,376 B / 87.9%,阈值 92%。
|
2026-10-26 12:28:14 +08:00 |
|
wandering1
|
2d16fdddc0
|
fix(看门狗): 停喂判定按位分账——复合串窗不再误停喂(2026-10-25 大窗判读 F2)
道F task-23。动因 = 2026-10-25 台架大窗判读:9 条 stall 行里 16:24/16:28 两起为
复合判据误升级——旧逻辑喂狗前置 = 全必需位同窗跑过,任一窗缺任一位即断喂,
复合连续 8 窗申报 stall;UI 一窗缺、IEC104 下一窗缺、再下窗 FTP 缺这类互不相干
的亚秒抖动被串成 800ms 假停摆(mg=877/918,两事件中无任何任务达单任务容忍线)。
16:39 那起才是真 UI 单任务串(~1.2s,bit4 到 8 连击——受害者面修复 = F3 票)。
【改造】stall/停喂唯一判据 = 任一必需位自己的连续缺席窗数(s_miss_bits[] 分账,
+9B BSS):同一任务 8 窗(800ms)没跑过 → 申报 + 停喂 → IWDG 自然溢出
(IWDGRSTF 权威归因不变);所有位连击 <8 的缺席窗照常喂狗;位出现即该位清零,
掩码外位不入账(wd_required_mask 随构建变化自动跟随、不留旧账)。`MISS start`
保留为复合边沿诊断行(不再代表停喂,判读口径以设计说明 §6.1/§11.1 为准)。
代价:真停摆从挂死到复位总时长最坏 +约 0.7s(≈2.5s 最坏 / ≈3.3s 标称),V2
台架判据「声明 stall 后 ≤2.5s 复位」不受影响(申报时点未变,停喂起点即申报)。
【测试】test/host/watchdog 断言按新判据改写 5 处(004/005/006/008/013:缺席窗
照常喂),新增 TC-WATCHDOG-017(20 窗 UI/NET 交替缺席:零 stall + 20 窗持续喂——
旧复合判据必在第 8 窗误报,回归钉)与 TC-WATCHDOG-018(同位 8/9/10 连击必报停
+ 停喂;恢复窗喂、账本重启,第二段亚容忍串重新从零计)。47/47 全绿。
【文档】看门狗设计说明 §0/§2.2(停喂链加「v1.5 起字面成立」注)/§3.2/§5.3/
§6.1/§11.1/§11.6 大窗补记 + 变更记录;看门狗单元测试说明(用例表 + 47 断言 +
变更记录,顺带修正 TC-WATCHDOG-003 行 10-12 后未跟的 `0x37`→`0x1F7`)。
【越界申报】① docs/测试说明/看门狗单元测试说明.md——票面写域外,但该文档
§4 自要求「行为变更须同步改单测与本文」,执行性同步;② 根目录
.cubemx_survival_baseline.json——cubemx-survival 钩子对 task_watchdog.c(watchdog-
module 审计项 = 全文哈希基线)明示「有意改动请 --write 重建基线」,重建后
31 通过 / 0 失败。均非他人并行改动面。
【门禁】@build 0 错误 0 警告(Code=224768 RO=24640 RW=1328 ZI=135096)。
--all-files 43 绿;红仅 mem-numbers/mem-budget = 台账漂移(vs 2026-10-25 行:
Code +80B / ER_IROM1 249328→249408 / ZI +8B(s_miss_bits)/ IRAM1 约 +8B,待回填)。
id-check 增量拦截通过(首跑拦下变更记录里 TC-003/TC-004 裸形,已改全 ID)、
test-coverage 通过、cubemx-survival 通过。
gate: only mem-budget/mem-numbers pending lead ledger backfill
【台架】等你排窗两轮(各 ≥30min):单独 relisten_stress :7003 / 探针轮。判据按
v1.1 口径 = stall 行零为硬判据;预期本修复后 16:24/16:28 型复合误升级归零,
MISS start 仍会出现(诊断量);16:39 型 UI 真单串在 F3 落地前仍可能照报——
那属于「判据抓对了人」,请连同 mask 一起记给我。
|
2026-10-25 17:58:18 +08:00 |
|
wandering1
|
a9ba8ec745
|
fix(WD): HW 测试模式掩码死分支复活——include 缺失自 7feeea6
结论先说:wd_required_mask() 里那条"硬件层测试构建剔除 netTask"的分支,自它被写进
仓库那天起**从未生效过**——不是逻辑错,是本编译单元根本看不见判据宏。台架一轮
(2026-10-25,boot log 20261025_050539)把它照出来了:
- 468 条 [ERR][WD] task stall 里,**431 条是 mask=0x1F5 / req=0x1F7**;
- 0x1F5 恰好等于那条死分支本该要求的集合(default|ftp|ui|timesync|adc|iec104|
protect,NET 位不在内)——该动的任务全动了,只是"要求方"看不见自己的例外,
于是按产品掩码 0x1F7 追 netTask 的心跳位;而 netTask 在 ENABLE_HW_LAYER_TESTS
下按设计入口自挂起(CH395F 归 testTask 独占),永远追不到。
根因:ENABLE_HW_LAYER_TESTS 定义在 test/board/ch395f_test.h(经 test_config.h 拉入),
而本文件没有 include 任何一条通往它的路径 → #if defined(...) 在本 TU 恒为假 → 死代码。
同一个需求早有既有做法:App/task/net_task.c:39 就为这个宏 include 了 test_config.h,
注释还写着"产品构建全未定义,无作用"——本文件只是漏了这一步。
修法:补 #include "test_config.h",并把根因与 req/mask 证据写在包含点上方(同一事实
不另开文档;销项时 docs 引这里)。写域扩到 App/util 由 lead 背书(看板 task-9)。
零产品影响(实测,不是推演):
- 产品态(TEST_SUITE_* 全注释、宏未定义 → 走原分支)@build 0 错误 0 警告,
Code/RO/RW/ZI = 214104 / 20388 / 1204 / 131852,与主干 2026-10-25 台账逐项相同。
- 测试态 hw_nopc 尺寸也与修复前逐项相同:改的只是"选哪个常量",没有新代码路径。
- 修复后净效果(下一轮台架复核):431 条 net 类 stall 消失,剩下的是 uiTask 间歇
缺位的 37 条(0x1E7 / 0x1E5)——那是另一件事,不在本提交里掩盖。
顺手记两条**没在本提交改**的发现(判据语义,归 lead 裁):
1) 抽样判定是**精确匹配**(注释自述:"掩码必须恰等于会置位的任务集合")。而 netTask
自挂起前会喂一次位 → 那一瞬间 mask=0x1F7 又不等于剔除后的 0x1F5 → 照样报 stall。
即"从掩码里剔一位"与"精确匹配"天然打架;要不要放宽成"观测 ⊇ 要求即可"值得单定。
2) 本轮 miss 一路涨到 1971 而**没有停喂、没有复位**:说明"连续未达标即停喂"的阈值
路径在 HW 层测试构建里未被触发(或 IWDG 尚未启动)。这条对产品侧更重要,值得单查。
随附 .cubemx_survival_baseline.json:本文件在存活审计里是 kind="generated" 的整文件
哈希项 watchdog-module("非 CubeMX 管辖,但须确认未被误删"),有意改动按脚本自述用
--write 重建基线。**先证明漂移 100% 来自本笔**:把我的 include 临时撤掉再跑
--check → rc=0(基线与 HEAD 逐项相符),因此不存在"别人早就改了没登记"的情况。
--write 顺带补出一条**基线里原本缺失**的条目 net-msgq-adopt(Src/freertos.c 的
RTOS_QUEUES 区,须含 net_msg_queue_adopt):它此前不在基线里 → --check 一直在静默
跳过这一项。本笔把它一并登记,属于意外收获,不是本笔的目的。
gate:cppcheck / coding-standard / bsp-err / id-check / no-mojibake /
trailing-whitespace / end-of-file-fixer / mem-numbers / mem-budget /
cubemx-survival(已 --write 重建基线)全 0;
未用 --no-verify。
|
2026-10-25 05:32:24 +08:00 |
|
wandering1
|
36a3c3449c
|
refactor(task): 19 处任务句柄裸 extern 收拢为 task_handles.h 引用契约
推荐清单第 3 步(结构债 S-2 剩余面),用户批准"按你推荐做"。
新建 `App/task/task_handles.h`——**只有声明、没有 `.c`**:头文件不需要双端注册,
且 `../App/task` 本来就在 uvprojx 的 `<IncludePath>` 里,所以这一步零构建面。
- `App/task/default_task.c:52-69` 的 18 行局部 extern(9 个句柄 + 9 个 attributes)
删除,改 include;栈水位观测用的任务清单表本体仍留在该文件
- `App/task/adc_task.c:125` 的 1 行同法收口
- `Src/main.c` 函数内的 `extern volatile uint32_t g_rcc_csr_latched;` 移进
`App/app/app_main.h`(`main.c` 本来就 include 它),USER CODE 区内只留"读
RCC_CSR → 写 RMVF 清除"两句,顺序约束的原注释保留
为什么值得做:原先每加一个任务都得记得往 `default_task.c` 再抄两行 extern,抄
漏一行 = 读别人的栈(静默,无报错)。现在只有一个改动点;而且 CubeMX 若把句柄
改名,报错会落在链接期而不是静默通过。
**镜像逐项体积不变**:`Code=213,188 RO-data=18,580 RW-data=1,184
ZI-data=131,504`,`@build` 0 错 0 警告 → 行为中性。
`check_cubemx_survival.py` 对这次有意的 USER CODE 区改动报"漂移",已按其文档流程
`--write` 重建基线(`.cubemx_survival_baseline.json` 仅 1 个指纹变化;顺手把该脚本
写文件带来的 CRLF 归一回 LF,符合 `* text=auto eol=lf`),`--check` 复跑通过、易失
清单 29 项全部到位。
报告 §0.4/§9 的 S-2 口径同时改成**精确分类**:该修的手写跨模块裸 extern **24 处,
今天已消 22 处,只剩 2 处**(`ch395f.c:177` 的 `g_spi1_dma_done` 与 `net_socket.c:77`
的 `netMsgQueueHandle`);`stm32f4xx_it.c:241-256` 那 16 条是 CubeMX「External
variables」生成块(删了会被重生成写回来,**不算债**),`:183/195/207/220` 那 4 条
是手写在 `__asm` Handler 里引用汇编标签(ARMCC `__asm` 取不到 C 数据符号,
**合法例外**)。上一版写的"25 处"把这三类混在一起了,一并更正。另更正 §0.4 的
S-1 一格:不是"运行时属主纪律被破"(UI 只投递 `net_cfg_save_request()`,写盘在
defaultTask),也不是"进不了主机侧单测"(模拟器已跑整条链),要修的只是静态分层
方向。
门禁:`@build` 0/0;`cubemx-survival --check` 通过;`check_doc_links.py --all
--sections-strict` 146 文档 0 问题;`check_ids.py --strict` 增量拦截通过、可判定
82.83%;`mem-numbers` 0。字节卫生:新增头文件与各改动文件 BOM 无 / CR 0 /
U+FFFD 0。未推送。
|
2026-10-22 19:09:20 +08:00 |
|
wandering1
|
51bc325b57
|
fix(stack): N-33 抬栈收口 defaultTask/timeSyncTask 栈余量(2 FAIL -> 0 FAIL)
既有债收口(非新引入):B7 定值持久化把 defaultTask 静态最坏链推到
3016 B、timeSyncTask 推到 1264 B,两者跌破 stack_report 判据
(余量 >= max(1024 B ISR, 配置 x 30%))。本轮只抬栈,不动调用链。
前基线(stack_report,9 任务):
- defaultTask cfg 4096 B / 静态 3016 B / 余 1080 B (26%) FAIL
- timeSyncTask cfg 2048 B / 静态 1264 B / 余 784 B (38%) FAIL
- 其余 7 任务 PASS(net 2112/1728、ftp 1456/2640、ui 1336/15048、
test 736/7456、adc 1320/1240、iec104 1456/1104、protect 872/1176)
改动:
- defaultTask 1024 -> 1280 words(4096 -> 5120 B):余 2104 B / 41%
- timeSyncTask 512 -> 640 words(2048 -> 2560 B):余 1296 B / 50%
- 后基线:9 任务 0 FAIL(stack_report 退出码 0)
堆开销(任务栈来自 FreeRTOS 堆,.map 静态数字不变):
- defaultTask +1024 B、timeSyncTask +512 B,合计 +1536 B
- 台架背书基线 heap free=17936 / min_ever=10000 B(B6),抬后
min_ever 预计 ~8464 B,仍远高于 3072 B 告警线
防丢失(CubeMX 存活 L1 纪律):
- STM32F407-Demo.ioc 的 FREERTOS.Tasks01 同步改 1024 -> 1280
(.ioc 是 CubeMX 生成任务栈值的事实源,未跑重生成)
- Src/freertos.c 生成区 .stack_size 与 .ioc 保持一致
- USER CODE BEGIN Variables 核算注释块补 N-33 依据(栈值理由唯一落点)
- .cubemx_survival_baseline.json 经 --write 重建(仅 ioc-task-stacks 一行)
task-table 生成区随栈变更再生成(README.md + AGENTS.md 的
TASK_TABLE 锚点区各 2 行,锚点区外无任何改动)。
验证:@build 0 错误 0 警告(Program Size 与改前逐字节一致);
ci_local 全绿(L0 + L0.5,826/826 断言);stack_report 前后各跑一次。
台架 @test 与串口 [STACK] 水位复测在提交后单独跑。
|
2026-10-12 17:47:15 +08:00 |
|
wandering1
|
90db528032
|
W1 功能主线完成:内存台账三件套(W1-0) + IEC104 上行(B4) + protectTask 板端接线(B5)
W1-0 台账三件套:scripts/ram_baseline.py(四模式)+ ram_baseline.tsv 趋势 +
docs/内存管理/RAM预算台账.md + pre-commit mem-budget 钩子(RW_IRAM1/RW_CCM >92%
即 FAIL + Top-10 附表);审查报告 §5.5 三条闭环。
B4 IEC 60870-5-104 上行(被控站,TCP 2404):App/protocol/iec104/ 三模块
(asdu 编解码 / pts 点表+数据源 vtable / link APCI+FSM,纯逻辑零 I/O)+
App/task/iec104_serv.c(iec104Task,NET_READY 屏障 100ms 分片喂位)。
82 断言 L0.5 全绿 + iec104-unit-test 钩子(第 31 钩子);
设计说明 docs/子系统设计/IEC104上行设计说明.md 全量回填。
B5 protectTask(L3 板端接线):App/task/protect_task.c——20ms 判据节拍
prot_elm_run + L5-4 采样故障闭锁(adc_health 电平位→元件复位)+ L5-1 定值
校验和巡检;新增 prot_elm_request_reset() 收口跨上下文复归(104 YK11 落请求、
eval 头部消费);定值/元件初始化移入 app_main_init(内核前)。TC-PE-010
(prot_elm 28 用例)。
门禁与内存:TASK_WD_PROTECT=8 入 required_mask(产品 0x77→0x1F7、HW 层
0x1F5,看门狗单测 39 断言同步);FreeRTOS 堆 48→56KB(.ioc L1 参数 +
FreeRTOSConfig.h 同步,RAM预算台账 §6 登记配额 48→56KB)。
ZI 144,008→152,204(+8,196 B = 堆 +8KB,B5 扩容);Code=204,348。
stack_report:protectTask 512 words 静态链 872 B/余 57%、iec104Task
640 words 1456 B/余 43% 均 PASS;RW_IRAM1 73.1% / RW_CCM 87.9%(<92%)。
验证:@build 0 错 0 警;ci_local 全绿(31 钩子 + 13 主机侧单测);
doc-links 135 文档 PASS。登记簿 B4/B5 销项、W1 波次完成;保护规划/看门狗
说明/AGENTS(9 任务)/RAM 三文档全部同步。
遗留(验收窗口,非代码空洞):台架第三方 104 主站往返(送检窗口)、
标准源注入动作判据、@test PROT 锚点 + protect 栈水位 + 新堆 min_ever 复测。
|
2026-10-12 12:36:23 +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
|
9231a3c22c
|
adcTask 事件驱动消费(P1-5 方案 a)+ 补 F4 ADC 上电自校准 + 修正 2 ms 忙等过期表述
P1-5 方案 a(事件驱动消费,Task #32):
- TIM6 1 kHz ISR 除触发 CONVST 外再调 adc_tick_irq_notify(),置位
ADC_WAKE_FLAG;adcTask 循环尾改 osThreadFlagsWait(osWaitForever),
删除 ADC_TASK_BEAT_MS 定时轮询
- adcTask 优先级 Normal(24) -> AboveNormal(32)(Src/freertos.c USER CODE 区)
- 补消费者就绪门(规划未预见):TIM6 在 app_main_init 就启动,比调度器
早约 100 ms,未就绪时 ISR 不得 osThreadFlagsSet
- 实测 6 次上板:idle 由 1~649 降到 0/20000 拍,frames 1000.0 Hz,
seq-frames=7 正是就绪窗口;UI 侧 uip/uiw/uis 无退化
补 STM32F4 ADC 上电自校准(此前项目从未做过):
- 核查证实裁剪版 HAL 无 HAL_ADCEx_Calibration_Start、裁剪版 CMSIS 头无
ADC_CR2_CAL -> 按 RM0090 13.3.6 在 Src/adc.c 的 USER CODE 区手写
adc1_calibrate(),MX_ADC1_Init() 末尾调用
- 新增 cubemx-survival 审计项 adc1-calibration-call / -impl(清单 21->23)
- 实测校准前后同一拍 STM32 侧 6 路同向偏移 +10~+63 LSB,TPAFE 侧不变
修正两处过期表述(实测反证):
- 原文 9 通道全超时最坏 = 18 ms 连占 有误:stm32_scan() 在首个超时处即
Stop+return,单拍上界 = 一次超时约 2~3 ms
- adcm 约 2.1 ms 的峰值归因由 ADC 采集改判为每 10 s 一次的心跳日志;
6 次对照 adcp = 122 us(无超时)/ 2209 us(超时 1 次)
- 同步修正 adc_task.c 两处过期注释;新发现超时拍 STM32 侧静默沿用
上一拍值的正确性代价,硬化排序记入 4.4 / 10.4(未实施)
验证:@build 0 错 0 警(Code 256728 -> 256868);@test 6/6 PASS;
stack_report 7 任务全 PASS(adcTask 832 B / 余 59%);18 钩子全绿
|
2026-10-10 22:41:19 +08:00 |
|
wandering1
|
883c9dd0cc
|
feat(adc): B1 实现 ADC 采集链路(adcTask + 看门狗)
B1(ADC 采集链路)落地,消化 P1-1:
- adc_task.c:空桩 -> 真实消费者。每 1ms 触发一次 CONVST,
用 tpafe5160_snapshot() 原子取数(AGENTS 铁律)+ 帧统计 +
每 10s 心跳日志。只取数,不做保护运算。
- Src/freertos.c:手工创建 adcTask(512 words / Normal,落
USER CODE 保护区,同 timeSyncTask 先例)。
- task_watchdog:新增 TASK_WD_ADC;required_mask 产品 0x37 ->
0x77、ENABLE_HW_LAYER_TESTS 0x35 -> 0x75。
- default_task.c:栈水位探针增列 adcTask(extern + 表项)。
- 脚本:stack_report.py 增 ROOTS/RUNTIME_ALIAS;gen_task_table
增 adcTask(README/AGENTS 任务表已 --write)。
- 单测:watchdog_test.c beat_all/掩码断言同步(39 断言全绿)。
- 文档:待处理内容/看门狗设计/RAM 方案/继保规划 同步。
验证:@build 0 错 0 警;stack_report 静态最坏链 504B(余 75%);
pre-commit 全绿。剩 @test 实机闭环。
|
2026-10-10 14:33:32 +08:00 |
|
wandering1
|
0779d3a075
|
栈整改不抬栈:删旧档迁移、FIL静态化、日志行缓冲按模块收紧、钩子脱离HAL,defaultTask链5312→2776B
|
2026-10-10 10:17:00 +08:00 |
|
wandering1
|
29df7bf8fb
|
4 个 Fault Handler 迁入 USER CODE BEGIN 0(L3→L2):生成区恢复 CubeMX 原样,重生成零 diff
CI / L0 静态门禁 (pre-commit) (push) Has been cancelled
CI / L0.5 主机侧单测 (MSVC) (push) Has been cancelled
|
2026-10-10 02:02:58 +08:00 |
|
wandering1
|
e2e1d0fd42
|
IWDG 延后启动改走宏改名(L3→L2):生成调用变空操作,重生成后不再需要手工删
|
2026-10-10 01:30:47 +08:00 |
|
wandering1
|
5eed2151de
|
CubeMX 生成 ADC1(9 通道)+ 复原重生成定制,FreeRTOS 加固迁 L1、钩子落 USER CODE 4/5,门禁豁免生成文件空白改写
|
2026-10-10 00:53:20 +08:00 |
|
wandering1
|
ed463716f6
|
netTask 栈 1024→960:按静态最坏链核算并同步 .ioc/README/审计基线
静态最坏链 2664B(日志主导:链上 5 帧各含 192B __con_line + 尾部 696B)
3840B 配置下余量 1176B(30.6%),过 stack_report 规则
net_drain_chip_rx scratch 静态化实测仅省 16B 栈、反增 256B BSS,已回退
.ioc FREERTOS.Tasks01 同步 960(L1 记账,重生成不丢)
|
2026-10-09 17:14:52 +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
|
3cc08f5d53
|
实机测试规划改造为执行判据说明:删除一次性台架窗口状态(§0.5取证记录)与规划框架,A1~A4代码状态按代码核对改写,16处外部引用重指向模块文档
|
2026-10-02 23:46:27 +08:00 |
|
wandering1
|
930215f81a
|
修复IWDG超时未配置与dhara resume回滚:看门狗误复位与复位后写入全部丢失,台架全量自检PASS
|
2026-10-02 20:48:30 +08:00 |
|
wandering1
|
73941da6b1
|
看门狗判定状态机增加主机侧单元测试(L0.5 层)
为 task_watchdog.c 的判定逻辑(位图取走清零 / 必需掩码 0x37 判定 /
miss_streak 连续 8 次停喂 / 100ms 抽样节流 / tick 回绕安全)补一层
主机侧纯逻辑单元测试,弥补此前只能靠真机或模拟器才能发现回归的空白。
架构(沿用项目既有"共享核心 + 平台后端"做法,参照 cfg_file_store):
- task_watchdog.h 末段新增"平台后端(内部)"声明 3 个钩子
(wd_platform_feed / _start / _tick_ms),MCU 端以 __weak 提供默认实现,
行为与重构前逐字一致(@build 0 错误 0 警告,Flash +20B)。
- 主机侧单测以同名强符号覆盖三钩子,即可离线注入/观测,无需碰 MCU 代码。
- 测试文件 #include 生产源文件本身,保证测的是真代码而非副本。
- 测试专用复位 task_wd_test_reset() 仅 TASK_WATCHDOG_UNIT_TEST 下编入,
MCU 构建零代码零符号。
测试(test/host/watchdog/,MSVC 离线编译,纯标准库驱动):
- 39 项断言全过(退出码 0);注入故障可复现退出码 1。
- run_unit_test.py 直接拼 INCLUDE/LIB 调 cl.exe,绕开本机被禁的 reg.exe。
- stub/ 三桩头覆盖 main.h / iwdg.h / dbg_log.h。
门禁:pre-commit 新增 watchdog-unit-test 本地钩子(L0.5 层),仅被测文件
或其测试变动时触发;测试开发标准流程.md 新增 L0.5 层说明。
顺带改善:task_watchdog.c 的节流基线 s_last_tick 由函数内 static 提为文件
static(可测性 + 模块状态归一)。
|
2026-10-01 06:57:01 +08:00 |
|
wandering1
|
8a18e388c7
|
四个 Fault 全部采集现场:MemManage/BusFault/UsageFault 由空死循环升级
原状:HardFault 已有崩溃采集,但 MemManage / BusFault / UsageFault 仍是空
while(1) —— 这三类故障发生时日志完全静默,且因 SHCSR 默认未使能,实际会
被升级成 HardFault,报告出笼统的 "HARDFAULT"、看不出根因。
改动:
- Src/stm32f4xx_it.c:三个 Handler 升级为手工 __asm 版(取 MSP/PSP 帧指针)
-> B 到 per-fault C 入口 fault_entry_{mem,bus,usage} -> hard_fault_report()。
hard_fault_report 增加 tag 参数,日志统一为
"[ERR] <TAG> PC=.. LR=.. xPSR=.. R0-R3=.. CFSR=.. HFSR=..[/BFAR][/MMFAR]"。
生成实体经 #define X X_Gen 改名保留,链接器各移除 2 字节(.map 已验)。
三个各带独立锚点 MEMFAULT/BUSFAULT/USAGEFAULT-ANCHOR。
- 新增 fault_handler_enable()(USER CODE BEGIN 1 区):使能 SHCSR 的
MEMFAULTENA/BUSFAULTENA/USGFAULTENA。声明入 Inc/stm32f4xx_it.h,调用在
app_main_init() 第一行(纯寄存器写,不依赖日志/时钟)。
- 刻意不启用 CCR.UNALIGN_TRP / CCR.DIV_0_TRP:会把普通 bug 升级成死机,
对本项目弊大于利(说明写进函数注释)。
实现约束(本轮踩坑):ARMCC 的 __asm 块取不到 C 的数据符号(ADR r1, xxx_tag
报 A1516E: Bad symbol,去 static 也无效),也无法给 C 函数传字符串参数,
故故障名必须由 C 侧 per-fault 入口带上。
配套:
- check_cubemx_survival.py:新增 fault-handlers-3 / fault-handler-enable 两项,
UNPROTECTED_LEGACY 清掉三个 Fault(WARN 2->1),清单 16 -> 18 项。
- AGENTS.md:新增"4 个 Fault 全部采集"条目;ARMCC 汇编条目补 A1516E 第 3 坑;
校验标记补 [ERR](四个 Fault 日志都以它开头 -> 一律判 FAIL,刻意)。
- 看门狗设计说明.md:§6.1 补 4 条 Fault 标记与 @test 禁项关系;
§10.2 L3 清单与四个 Fault 采集小节;§11 结论表与变更记录。
- 待处理内容.md:新增 N-03d(已完成),N-03c 补第二次重生成结论。
验证:@build 0 错误 0 警告(Flash +156 B,RAM 无变化);pre-commit 13 钩子
全通过;审计 18 通过 / 1 警告 / 0 失败。
|
2026-09-29 09:16:19 +08:00 |
|
wandering1
|
67d26ac37a
|
修正 CubeMX 重生成防丢失机制:审计脚本实测有效,恢复 5 处被覆盖定制
第二次重生成验证了审计机制,并证伪了上一轮的一处假设:
- 审计脚本 check_cubemx_survival.py 准确检出全部 5 处覆盖(16 项中 5 FAIL),
机制有效;Src/main.c 复位原因锁存(USER CODE BEGIN Init 区)完好,
是"USER CODE 区有效"的正向证据。
- 关键发现:CubeMX 本次换了一代中断函数模板(旧 HardFault_Handler /
HardFault_Report 自造区 → 新函数体内 HardFault_IRQn 0 / W1_HardFault_IRQn 0),
"生成区之外的自造标记区"同样不被保留,旧假设被证伪。
恢复方案(第二次升级):
- stm32f4xx_it.c:报告实现迁入 USER CODE BEGIN 0(区名从未变过的标准保护位);
Handler 本体改为生成区整函数替换,用 #define HardFault_Handler
HardFault_Handler_Gen 把生成实体改名保留,链接器自动移除(.map 实证
Removing ... (2 bytes)),向量表指向手工 __asm 版(0x080001a1,18 字节)。
- iwdg.c:去掉 HAL_IWDG_Init() 调用,补 IWDG-DEFER-START-ANCHOR 锚点注释。
- FreeRTOSConfig.h:恢复 FREE_RTOS_CONFIG_HARDENING 块(两个加固宏)。
- freertos.c:补回两处任务栈中文注释(栈值未丢,.ioc 已同步)。
配套:
- check_cubemx_survival.py:hardfault-handler 改 wholefile + 锚点检查;
UNPROTECTED_LEGACY 清单更新。
- AGENTS.md:新增"CubeMX 换模板"与"ARMCC 内联汇编语法"两条铁律,
以及"uvprojx 被 Keil 自动改写不入库"条目。
- 看门狗设计说明.md:§10.1 补第二次重生成验证结论与模板换代发现,
§10.2 L2/L3 全面改写(自造区名不可依赖)。
验证:@build 0 错误 0 警告;pre-commit 13 钩子全通过;审计 16 通过 / 2 警告 / 0 失败。
|
2026-09-29 07:52:39 +08:00 |
|
wandering1
|
7a18d2ce28
|
加 CubeMX 重生成存活审计:防标记区外定制被静默覆盖
背景:.ioc 的 KeepUserCode 只保护 USER CODE 标记区,标记之外的手工改动
重生成即被覆盖,且多数不报编译错(2026-09-29 实测一次覆盖 4 处,含
HardFault_Handler 崩溃采集被打回空 while(1)、两个 FreeRTOS 加固宏被删)。
新增 scripts/check_cubemx_survival.py:
- 16 项易失清单(IWDG 延后启动 / 崩溃采集 / 栈溢出检测 / 堆失败钩子 /
断言改造 / 看门狗模块与工程挂载 / 复位原因锁存 / HAL 驱动与使能 /
.ioc 关键项),断言前剥掉 C 注释防误报
- 哈希基线漂移检测(.cubemx_survival_baseline.json),--write 重建
- 标记区外存量以 WARN 提示(3 个 Fault 处理函数、栈注释)
已挂 pre-commit cubemx-survival 钩子(改动 .ioc / Src / Inc /
task_watchdog / .uvprojx 时触发)。
文档:看门狗设计说明 §10.2 新增"重生成不丢的三层手段"方法论
(L1 写 .ioc > L2 搬进 USER CODE 区(可自造标记区)> L3 审计兜底)
及 .ioc / USER CODE 区可用位置 / 存量清单三张对照表;AGENTS.md 平台约束
新增该规则;pre-commit 使用说明 §2.12 新增钩子详解。
门禁:build 0 错误 0 警告;pre-commit 全通过。
|
2026-09-29 07:30:00 +08:00 |
|