docs: add debug handoff package
This commit is contained in:
@@ -356,3 +356,95 @@ case ETHTYPE_ARP:
|
||||
2. `项目技术实现.md`
|
||||
3. `项目需求说明.md`
|
||||
4. `Keil工程配置说明.txt`
|
||||
|
||||
---
|
||||
|
||||
## 11. 近期调试经验固化（2026-04）
|
||||
|
||||
本节用于固化这一轮 `FreeRTOS + lwIP + CH390` 联调过程中已经验证过的经验，后续调试默认以本节为前提，不要反复回到已排除的旧假设。
|
||||
|
||||
### 11.1 构建结果的真值来源
|
||||
|
||||
当前工程的构建真值必须以 `Keil` 实际构建日志为准，而不是辅助 viewer。
|
||||
|
||||
推荐优先级如下：
|
||||
|
||||
1. `MDK-ARM/build_capture.txt`
|
||||
2. `MDK-ARM/TCP2UART/TCP2UART.build_log.htm`
|
||||
3. `MDK-ARM/TCP2UART/TCP2UART.map`
|
||||
|
||||
说明：
|
||||
|
||||
1. `keil-build-viewer.exe` 只能辅助观察内存占用或旧构建快照
|
||||
2. viewer 未刷新时，不代表当前代码没有变化，往往只是最新构建没成功或 viewer 数据滞后
|
||||
3. 后续任何“编译通过 / RAM 变化 / 目标器件切换”的判断，都必须引用以上三类 Keil 真实产物
|
||||
|
||||
### 11.2 近期已验证的事实
|
||||
|
||||
以下结论已经被本轮调试反复验证：
|
||||
|
||||
1. `DIAG_TASK_ISOLATION=1` 时，系统可以稳定运行
|
||||
2. `DIAG_TASK_ISOLATION=0` 时，full-task 模式仍会卡死
|
||||
3. 启动阶段 `lwip_netif_init()`、deferred `xTaskCreate()`、`netif-ready` 等关键日志已经真实跑通
|
||||
4. 之前通过加日志、分阶段创建 TCP 任务、调整栈大小后，卡死边界会继续后移，但问题不会完全消失
|
||||
5. 这说明当前问题不是单一固定点故障，而是“逻辑路径 + 极低资源余量”共同作用的结果
|
||||
|
||||
### 11.3 已排除或降级优先级的方向
|
||||
|
||||
以下方向目前不再应作为一号假设：
|
||||
|
||||
1. **startup/init 失败**
|
||||
- 当前日志已能稳定走到 `netif-ready`
|
||||
- 因此主要问题不再是最初的 bring-up 链路本身
|
||||
2. **单纯 CH390 TX 无限等待是当前主因**
|
||||
- 已为 TX 路径增加过 bounded wait / timeout 观察点
|
||||
- 最新故障没有先落到 `[ETH] tx timeout` 分支
|
||||
3. **只靠继续增大 TCP task 栈就能解决问题**
|
||||
- `256 -> 384 words` 后，故障边界虽然继续后移，但系统仍会卡死
|
||||
- 栈确实曾是问题的一部分，但不是唯一剩余问题
|
||||
|
||||
### 11.4 当前最重要的资源压力结论
|
||||
|
||||
当前 `STM32F103RCT6`（48KB SRAM）上的真实资源压力已经高到会直接干扰调试判断：
|
||||
|
||||
1. 真实构建中，`ZI-data` 已接近物理 RAM 上限（约 95%+）
|
||||
2. 在 `DIAG_TASK_ISOLATION=0` 下，创建完四个 TCP 任务后，`xPortGetFreeHeapSize()` 只剩约 `944 bytes`
|
||||
3. 这个余量不足以让后续 `netconn_*`、semaphore、mailbox、任务栈回旋空间保持清晰边界
|
||||
4. 因此当前在 `RCT6` 上继续做 discriminator 时，结果会持续混入“资源边界噪声”
|
||||
|
||||
这也是为什么本轮调试后半段已经把重点从“继续在 RCT6 上做更多小修补”切换到“先换更大 RAM 的 pin2pin 器件再继续分析”。
|
||||
|
||||
### 11.5 当前推荐的硬件调试策略
|
||||
|
||||
当前推荐的下一阶段策略如下：
|
||||
|
||||
1. 先从 `STM32F103RCT6` 切换到 pin2pin 的 `STM32F103RDT6`
|
||||
2. 在切换器件后，尽量保持当前代码基线不做大改
|
||||
3. 先复测当前版本的 RTT 与运行边界，看故障是否：
|
||||
- 消失
|
||||
- 明显后移
|
||||
- 仍然停在相同 enabled path
|
||||
4. 再根据新器件上的表现，区分：
|
||||
- 资源压力主导
|
||||
- 逻辑 / 时序 / API 使用问题仍然存在
|
||||
|
||||
### 11.6 换片后第一轮调试目标
|
||||
|
||||
切换到 `RDT6` 后，第一轮调试不追求立刻修复，而是优先回答下面几个问题：
|
||||
|
||||
1. 当前 full-task 模式是否仍然卡死
|
||||
2. `free/min heap` 是否明显高于 `RCT6` 版本
|
||||
3. enabled 的 `S1 / C1` 是否能够继续进入更深的 `netconn_new / bind / connect / listen / accept` 路径
|
||||
4. 之前为了定位问题而加入的 discriminator（例如 `C1 first-connect defer`）是否仍然影响故障边界
|
||||
|
||||
如果这些问题不先回答，后续继续改代码的结论可信度会很差。
|
||||
|
||||
### 11.7 当前建议保留的调试原则
|
||||
|
||||
后续 agent 或开发者继续接手本工程时，建议遵守以下原则：
|
||||
|
||||
1. 不要在 `RCT6` 上继续大量加日志、加栈、加 queue 深度后再试图解释现象
|
||||
2. 不要把 viewer 当作当前构建真值
|
||||
3. 不要忽略 `DIAG_TASK_ISOLATION=1 正常、=0 异常` 这个前提
|
||||
4. 不要一次性修改 `C1/S1/CH390/lwIP` 多个方向，避免再次失去因果关系
|
||||
5. 每次只做一个能明显改变故障边界的最小改动，并用 RTT + Keil build 结果交叉验证
|
||||
|
||||
Reference in New Issue
Block a user