From 394f473df084b4c48364d3c3e1f4a6bde806538e Mon Sep 17 00:00:00 2001 From: QIU SHENGMING Date: Fri, 2 Oct 2026 10:08:40 +0800 Subject: [PATCH] Correct the overlay cause: the log order rules the sector-cache overwrite out The flash probe records every transaction in order and the last one for that launch is the app's own code load (addr=103000 len=544, first bytes f0b583b0); nothing follows before the app is gone, so no font or resource read lands on the running app in that window. The 7848 font-region reads in the log belong to the firmware's own repainting. What stands measured: the loader copies and jumps (a PC sample lands in the overlay, and a 16-byte app that calls nothing loops there forever); the app dies well under 100 ms (panel reads at t+113 ms still show the menu, at t+193 ms only the launcher's title box); an app that spins first survives a bar, a blit and led and dies around delay_ms; one that calls blit immediately is gone before it can be seen. Next: drop the PC probe interval from 100 ms to a couple of milliseconds, which is a one-line model change and turns it into a real trace of the app's short life. --- AGENTS.md | 19 +++++++++++++++++++ AGENTS.zh-CN.md | 15 +++++++++++++++ 2 files changed, 34 insertions(+) diff --git a/AGENTS.md b/AGENTS.md index 8d5bd6d..9b930f1 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -771,6 +771,25 @@ must gate the sector cache while an app is loaded, and **that gate is what the m Next: find the gate in the firmware's flash driver (a memory flag, a register, a GPIO) and check what the model answers for it. This is the first time the failure has a name and a reproducible three-app comparison behind it. +**Correction: the sector-cache explanation is not supported by the log order.** + +The flash probe records every transaction in order, and the last one for that launch is the app's own +code load (addr=103000 len=544, first bytes f0b583b0). Nothing follows it before the app is gone, so no +font or resource read lands on top of the running app in that window -- the sector-cache overwrite cannot +be the cause here. What the log does show is 7848 reads in the font region over the session, all of them +part of the firmware's own repainting rather than the app's life. + +Where that leaves the search, with everything that is actually measured: the loader copies and jumps (a +sample lands inside the overlay, and the 16-byte app that calls nothing loops there forever); the app then +dies within well under 100 ms (panel reads at t+113 ms still show the menu and at t+193 ms the launcher's +title box alone); an app that spins first survives a bar plus blit plus led and dies around delay_ms; and +one that calls blit immediately is gone before anything of it can be seen. The killer is inside the first +hundred milliseconds and is not a flash read. + +Next instrument, and it needs a one-line model change rather than more guessing: the PC probe ticks every +100 ms, which is the same order as the app's whole life. Dropping that interval to a couple of milliseconds +turns it into a real trace and would show where in the overlay the app stops. + ## The keypad: two real bugs, both fixed The old note here said "keys reach the firmware but the UI does not react" and diff --git a/AGENTS.zh-CN.md b/AGENTS.zh-CN.md index e812c9e..50a1cae 100644 --- a/AGENTS.zh-CN.md +++ b/AGENTS.zh-CN.md @@ -627,6 +627,21 @@ app 区被读过 —— 而多系统菜单读的是**固件槽**，不是应用 下一步：在固件的 flash 驱动里找到这道门（一个内存标志、一个寄存器、还是一根 GPIO），再看模型在被问到时答的是什么。 这是第一次，这个故障有了名字、也有了三个应用的可复现对照。 +**更正：扇区缓存这条解释，与日志的时间顺序不符。** + +flash 探针是按顺序记录每一笔事务的，而那一次启动的**最后一笔**正是应用自己的代码加载 +（addr=103000 len=544，首字节 f0b583b0）。此后到应用消失为止**没有任何事务** —— 也就是说，在那个窗口里 +**没有**字库或资源读取压在运行中的应用头上，**扇区缓存被覆盖在这里不可能是原因**。日志真正显示的是：整个会话里 +有 7848 次字体区读取，它们都属于固件自己重绘画面的过程，而不属于应用的生命期。 + +于是搜索范围收敛到（只列实测过的）：加载器会拷贝并跳转（有采样落在叠加区内，而且那个 16 字节、什么都不 +调用的应用能在里面永远循环）；应用随后在**远不到 100 ms** 内死亡（t+113 ms 读屏还是菜单，t+193 ms 只剩启动器 +的标题框）；先自旋再动作的应用能活过一条横杠 + blit + led，而在 delay_ms 附近死掉；一上来就调 blit 的应用 +则连影子都还没留下就没了。**凶手在这最初的一百毫秒之内，而且不是 flash 读取。** + +下一个仪器，只需要改模型一行而不是继续猜：PC 探针每 100 ms 采样一次，而应用整个生命期就是这个量级。把这个 +间隔降到几毫秒，它就变成真正的 trace，能看出应用**停在叠加区的哪个位置**。 + ## 键盘：两个真 bug，都已修复 这里原来的笔记写的是"按键到达了固件但界面不反应"，并且归咎于机器模型。结果发现有**两个