docs(vd960DBN): devlog 记录第二分包根因 — 响应缓冲越界踩踏 g_notify_buftemp

vd960DBN/docs/devlog.md

@@ -112,6 +112,41 @@ static void performPeriodicTask(void)
 
 ---
 
+## 2026-08-12 — 续2：第二分包丢失 — 根因确认（响应缓冲越界踩踏 g_notify_buftemp）
+
+### 破案过程（三份现场日志 + .map 对照）
+
+| 证据 | 结论 |
+|------|------|
+| `CLEAR busy resp: amt=2 seq=2 off=130 ret=00008122` | ret 对 .map = `set_response_to_notify` 内部（0x7FEC+0x136）→ 第二包**填充成功**（正常清空），队列清空不是问题 |
+| `BLE ntf flag 1->0 (len=0 temp=0)` 无 `BLE send` | 第二包(49B)从通知缓冲**物理消失**，非发送路径 |
+| `CLR_NTF: buf=20007bdc flag=1 len=93 ret=0000d604` | 第一包发送后正常清空（ret=Peripheral_ProcessEvent 内联 performPeriodicTask） |
+| **`.map` RAM 布局** | `g_buf_ble_response=0x20007B58 +0x6B(107B)`，`g_notify_buftemp=0x20007BDC` → **107B = 7 + dat[100] = MAX_BLE_DAT_BUF_LEN 编译时是 100（旧宏）** |
+
+### 根因链（ODR 违规）
+
+```
+用户 MRS 工程 dbn_ble_srv.h 宏未同步: MAX_BLE_TMP_BUF_LEN/MAX_BLE_DAT_BUF_LEN=100 (repo 为 132)
+→ Buf_DBN_BLE 实际 107B (dat[100]), 链接器把 g_notify_buftemp 排在 0x20007BDC
+→ QUERY 响应组包 130B: tmp_ble_buf[100..129] 越界 + set_response_buf 写 dat[0..129] 越界 30B
+→ 越界写踩中 g_notify_buftemp.flag/len (物理地址重叠)
+→ 第二分包填充后 flag/len 被清零 → 下一 TMOS 周期不发送 → 永久丢失
+```
+
+> 同一时间戳 `BLE resp flag 1->0 (pull=0)` 是越界后的**连锁反应**：notify flag 被清 0 → poll_dbn_ble 走 idle 分支 → `g_flag_notify_temp=0` → 发送周期被跳过。
+
+### 修复（防御性根治，兼容新旧宏）
+
+1. **QUERY 组包动态限制记录数**：`_max_rec = (MAX_BLE_TMP_BUF_LEN - 2) / sizeof(OfflogEvt)` → 宏=100 时最多 3 条（98B），宏=132 时最多 4 条（130B），**永不越界**
+2. **`set_response_buf` 截断防御**：`dat_len > MAX_BLE_DAT_BUF_LEN` 时截断
+3. 验证：旧宏 100 下 3 条 = 98B → 分包 [93, 17] 全合规；新宏 132 下 4 条 = 130B → [93, 49] 全合规
+
+### ⚠ 必做：确认 MRS 工程头文件
+
+**`.map` 铁证：用户编译的固件里 `MAX_BLE_DAT_BUF_LEN=100`（旧宏），repo 已是 132。** 即使加防御，也请确认 MRS 工程 `APP/include/dbn_ble_srv.h` 的 `MAX_BLE_TMP_BUF_LEN`/`MAX_BLE_DAT_BUF_LEN` 均为 **132**（与 repo 一致），否则结构体大小不一致（ODR 违规）的隐患仍在。
+
+---
+
 ## 2026-08-10 — BLE 读取脱机日志接口 (OFFLOG_STAT/QUERY/CLEAR)
 
 ### 背景