Files
STM32F4-Base/docs/测试说明/boot_log_data/20261027_bench42_verdicts.txt
T
wandering1 9a231831bc test(台架): HEAD 固件仅复位 4/4 全绿——两条曾被啃的行逐字节完整,并拿修复前归档反证
这是今天第一份**硬件侧**证据(此前所有绿色都只到静态与主机侧为止)。身份按新口径钉:
以固件身份戳为准、SHA 只当坐标——**fw build: Oct 26 2026 22:52:09 suite=NONE dstr=off**
(坐标 HEAD b24b2b5f;该像与在库固件源同一棵树已由两条机械判据证过)。

计数严格按两句并列,不合并:**烧录启动 1 次**(00:25:06,@test rc=0,不进仅复位序列)+
**仅复位 4 次**(01:46~01:52,serial gen 273→276 单调递增,逐圈自证窗口不重叠、零重烧),4/4 PASS:
· [ERR] / CONSOLE dropped / 任一 Fault 令牌 / ERROR / assert 全部零命中;
· 两条历史受害行逐字节完整:[PROT] 91 px、[NAND_FTL] 56 px(行首 '[' 齐全、loose_neighbours=0、
  head_bad=0)——这正是「未注册期裸发丢行首」那一类缺陷的正面判据;comm init 57 px;
  prot set loaded ×4、CORRUPT ×0;boot→net init 733~786 ms;
· **反证**:同一把尺指向修复前归档 → rc=1 FAIL 并打回缺行首的邻居 ⇒ 四个 PASS 不是空跑;
· 锚定用的是仓内 verify_log.py --exact(b1280e3c 并进的那半,今晚第一次自用);
· 堆与栈:heap free=15624 / min_ever=8464 与 task-30 逐字节相同;ui 峰值 4188 四轮内部零摆动、
  与上轮 max 持平(按 task-32 未定稿口径只报数、不做单次比较);
· -CmpFile 排在全部采集之后(它会导致目标复位)→ No difference found。

**执行类页面的硬闸在真机上证死了**:--to clear / --to reset 在下钻前就拒绝(非零退出、连轨迹
文件都不生成、理由文本点名「第二次 ENTER 即真执行」);--to clock 正常到达(9 步,ENTER 全落在
菜单上下文),时钟页渲染无缺字白框(年月日时分秒与页码行全显)。帧与判定已归档。

作者自报两次测量错误(都不是板子的问题,也都没有产出假绿,处理方式正是本仓要的):
① 01:34 头一圈采到 0 字节。根因在测量侧:**常驻 serial daemon 已经死了**,而 serial_tool.py 的
   status 会自动拉起一个新 daemon,于是它一直「正常」地报 port.ready=false / rx_lines=0、日志只剩
   58 B——**status 的自愈把端口是死的这件事遮住了**。已立口径:每圈复位前 open + 断言 ready + 观察
   rx_lines 增长,不假设 @test 留下的端口状态能过夜。该圈按两条独立理由排除(前面有烧录、实际
   零字节),不进任何计数。
② 我自己加的 Forbidden 令牌 Fault 是**假红**:子串命中 de**fault**,打到 factory default password
   与 [STACK] default peak_used。已换成显式故障令牌(四个 Fault 本来都以 [ERR] 开头,裸 Fault 只是
   噪声)。这条口径移交 task-32:**Forbidden 令牌要短到不落在英文单词内部**。

一条观察移交(不下结论、不属台架职责):装置墙钟显示 2026-10-26 18:00:35,而主机记录是当日
01:5x +08:00,固件日志时标与 daemon 时标也恒差 8 小时——**RTC 与 UTC/本地时区的语义归谁**由 Lead
路由(已立案,见 task-44)。

归档物:boot_log_data 下 20261027_bench42_{reset_only_boots_r1_r4,verdicts}.txt
与 _ui_clock_page.png;
README 台账行按新口径书写。编辑 README 前重读、编辑后复核:其他两条道的「证据可达性」规则与 §2.1
都还在,无 BOM / 无 U+FFFD / LF。
2026-10-27 02:29:10 +08:00

71 lines
6.7 KiB
Plaintext

2026-10-27 bench task-42 verdicts -- UI-landed image, 4 counted reset-only circles
identity: fw build: Oct 26 2026 22:52:09 suite=NONE dstr=off (suite=NONE => product build; dstr=off => non-destructive)
coordinate: HEAD b24b2b5f; firmware .c/.h identical to b623a406..HEAD (mechanically checked: no commit touched .c/.h after b623a406,
working tree had no dirty .c/.h; the only source newer than the .hex is test/host/console_log/console_log_test.c,
a HOST unit test not present in the uvprojx) => main-tree .hex IS HEAD firmware, no rebuild needed.
reporting rule (agreed with lead): flash boot and reset-only circles are counted SEPARATELY. A circle that had a flash in
front of it does NOT join the "consecutive reset-only" count (task-32 rule 4), and the 01:34 attempt is excluded
twice over: it had a flash behind it AND it captured 0 bytes (measurement failure, no data exists to count).
BOOTS REPORTED:
flash boot x1 (00:25:06, @test rc=0, NOT in the reset-only sequence): 9 required markers incl. identity stamp,
forbidden 0, banner x1, boot->net init 777 ms, readback "No difference found".
reset-only x4 (01:46-01:52, the sequence proper):
boot_r1_gen272 verdict=FAIL banner=0 cause="" forbidden_hits=0 [] boot->net_init=n/a
heap: - ui: - protect: -
prot_set: - comm: - CONSOLE dropped: absent
boot_r1_gen273 verdict=PASS banner=1 cause="software (NVIC_SystemReset)" forbidden_hits=0 [PROT=91px nb=0 head_bad=0] [NAND_FTL=56px nb=0 head_bad=0] [APP=57px nb=0 head_bad=0] boot->net_init=745 ms
heap: heap free=15624 min_ever=8464 ui: [STACK] ui peak_used=4188/16384 free_min=12196 (74%) protect: [STACK] protect peak_used=492/2048 free_min=1556 (75%)
prot_set: prot set loaded (/prot_set.bin) comm: comm init: OK (ca=1 port=2404) CONSOLE dropped: absent
boot_r2_gen274 verdict=PASS banner=1 cause="software (NVIC_SystemReset)" forbidden_hits=0 [PROT=91px nb=0 head_bad=0] [NAND_FTL=56px nb=0 head_bad=0] [APP=57px nb=0 head_bad=0] boot->net_init=786 ms
heap: heap free=15624 min_ever=8464 ui: [STACK] ui peak_used=4188/16384 free_min=12196 (74%) protect: [STACK] protect peak_used=492/2048 free_min=1556 (75%)
prot_set: prot set loaded (/prot_set.bin) comm: comm init: OK (ca=1 port=2404) CONSOLE dropped: absent
boot_r3_gen275 verdict=PASS banner=1 cause="software (NVIC_SystemReset)" forbidden_hits=0 [PROT=91px nb=0 head_bad=0] [NAND_FTL=56px nb=0 head_bad=0] [APP=57px nb=0 head_bad=0] boot->net_init=733 ms
heap: heap free=15624 min_ever=8464 ui: [STACK] ui peak_used=4188/16384 free_min=12196 (74%) protect: [STACK] protect peak_used=492/2048 free_min=1556 (75%)
prot_set: prot set loaded (/prot_set.bin) comm: comm init: OK (ca=1 port=2404) CONSOLE dropped: absent
boot_r4_gen276 verdict=PASS banner=1 cause="software (NVIC_SystemReset)" forbidden_hits=0 [PROT=91px nb=0 head_bad=0] [NAND_FTL=56px nb=0 head_bad=0] [APP=57px nb=0 head_bad=0] boot->net_init=776 ms
heap: heap free=15624 min_ever=8464 ui: [STACK] ui peak_used=4188/16384 free_min=12196 (74%) protect: [STACK] protect peak_used=492/2048 free_min=1556 (75%)
prot_set: prot set loaded (/prot_set.bin) comm: comm init: OK (ca=1 port=2404) CONSOLE dropped: absent
NEGATIVE CONTROL (proves these PASSes are not vacuous) -- same verifier, same flags, pointed at the pre-fix defective capture:
rc=1
[FAIL] exact line: \[[^\]]*\]\[PROT\] uncalibrated -> protection blocked \(UA/UN/IA hits=0 lens=[] loose_neighbours=0
[FAIL] exact line: \[[^\]]*\]\[NAND_FTL\] Initializing NAND FTL\.\.\. hits=0 lens=[] loose_neighbours=1
inexact neighbour: 26-10-26 08:37:07][NAND_FTL] Initializing NAND FTL...
VERDICT: FAIL
EXECUTIVE-ACTION PAGE GATE, PROVEN ON REAL HARDWARE (not simulator):
--to clear -> refused before ANY key was injected (no trace file was even written), rc non-zero:
raise RuntimeError("刻意跳过执行类页面 " + pid + ":进入后第二次 ENTER 即真执行"
RuntimeError: 刻意跳过执行类页面 clear:进入后第二次 ENTER 即真执行(强制复归 = 复归保护位并写 SOE;清除记录 = 清 SOE/运行/操作记录)。显示正确性请走模拟器黄金参考;确需真机下钻才加 --allow-exec-pages。
--to reset -> same refusal, same reason:
raise RuntimeError("刻意跳过执行类页面 " + pid + ":进入后第二次 ENTER 即真执行"
reason text names the exact stacking hazard: entering the page + a SECOND ENTER executes
(强制复归 = reset protection bits + write SOE; 清除记录 = clear SOE/run/op records).
clock page navigation (9 steps, keys e,l,d,d,d,d,e,e,e -- every ENTER in a menu context): reached, kind=PAGE, ink=3018
FINAL READBACK (last hardware action, after every capture, since -CmpFile resets the target):
rc=0
CMP: MDK-ARM\STM32F407-Demo\STM32F407-Demo.hex vs device flash @ 0x08000000 (NOTE: connecting resets the target)
No difference found.
INCIDENTS AND SELF-REPORTED MEASUREMENT ERRORS IN THIS WINDOW (kept because they are the useful part):
1) 01:34 first attempt captured 0 bytes. Root cause NOT the board: the long-running serial-assistant daemon
(pid 18020, uptime 156589 s) had DIED, and "serial_tool.py status" auto-spawns a fresh daemon, so status kept
answering happily with port.ready=false / rx_lines=0 / 58-byte log. Verified afterwards: the board had booted
normally from that very reset (uptime t=386840 ticks matched 01:34:08 and PROF lines streamed).
=> Rule for every window: run "open" and assert port.ready AND watch rx_lines grow BEFORE the first reset;
never assume the port state left behind by @test survives (it does not survive an hour).
2) My own forbidden pattern "Fault" is a false red: it substring-matches "de*fault*" and hit two innocent lines
([FTP] using factory default password / [STACK] default peak_used). Replaced by the explicit fault tokens.
Any Fault dump starts with [ERR] anyway (platform convention), so bare "Fault" added nothing but noise.
3) My harness parsed the verifier's --json from stdout+stderr concatenated; on a non-zero exit that breaks parsing.
Fixed by keeping the streams apart. Also "serial_tool.py log" returns JSON, not plain text (first attempt
filtered lines starting with "[RX]" and silently got zero) -- that is the second time tonight I assumed an
output format instead of reading it.
OBSERVATION (not a verdict, not my scope): the device wall clock reads 2026-10-26 18:00:35 while the host logged
2026-10-27 01:5x+08:00, i.e. ~8 h behind local and a few minutes off true UTC; firmware log stamps show the same
8 h offset against the daemon stamps. Frame evidence: 20261027_bench42_ui_clock_page.png. Left for the lead to
route (RTC/timezone semantics), with no claim attached.