TCP2UART/CH390_最终结论报告.md

CH390 最终结论报告

结论

本轮循环调试的最终结论是：

1. 当前工程中的主要软件问题已经完成收敛和清理。
2. CH390D 驱动、lwIP netif、ARP 与 ICMP 基本链路已经在实机上打通。
3. 本轮最终根因已确认不是普通软件逻辑错误，而是 CH390D 相关供电滤波电容虚焊，导致供电不稳定。

已完成的软件侧工作

本轮已完成并验证的事项包括：

1. 修复 PHY 访问无超时导致的永久卡死风险。
2. 修复未初始化 IWDG 句柄刷新导致的 HardFault。
3. 清理 CH390 运行时中断屏蔽范围，消除阻塞式 SPI 访问造成的运行时假死。
4. 重构 CH390 运行时所有权，避免多层并发触达底层 SPI 路径。
5. 在 main() 中移除重复 CH390 复位，避免启动阶段额外复位噪声。
6. 清理已确认 warning 来源，避免无效变量继续污染构建结果。
7. 增加 CH390 identity gate，避免在无效寄存器读回前继续执行默认配置和 PHY 初始化。
8. 曾增加 bit-bang 诊断读用于快速隔离问题，该临时调试路径已在当前代码中移除。

实机关键证据

1. MCU 自身正常工作

已验证：

1. RTT 正常输出。
2. 主循环正常运行。
3. TIM4 心跳正常。
4. 运行期不再出现此前已修复的 HardFault 和“长时间假死”症状。

2. 最终硬件根因已定位

最终实板排查结果：

1. 板载一颗 CH390D 供电相关滤波电容存在虚焊。
2. 该问题导致 CH390D 供电不稳定，表现为寄存器读写、链路状态和报文收发在调试过程中不一致。
3. 修复硬件后，实机已观察到：
   • VID=0x1C00、PID=0x9151、REV=0x2B
   • PHY 寄存器稳定可读
   • lwIP netif 能进入 LINK_UP
   • 设备可接收 ARP request 并发出 ARP reply
   • 设备可接收 ICMP Echo Request 并发出 Echo Reply

3. 历史 bit-bang 对照结果（已归档）

在早期调试中，曾绕过 STM32 硬件 SPI 外设、直接用 GPIO 软件时序读取 VIDL/VIDH/PIDL/PIDH/CHIPR，RTT 输出为：

CH390 bitbang VIDL=0xFF VIDH=0xFF PIDL=0xFF PIDH=0xFF CHIPR=0xFF

该历史证据用于定位阶段，当前仅保留结论，不再保留对应代码路径。它说明：

1. 在硬件未修复前，单看软件现象会误导排查方向。
2. 电源完整性问题会放大为看似“SPI/IRQ/RX/TX 都可疑”的复合症状。

外部参考对结论的支撑

对公开 CH390 / DM9051 实现的对照结果表明：

1. CH390 SPI 访问时序、模式选择和 RX SRAM 连续事务仍然值得严格对照参考实现。
2. 但本项目最终问题并非“参考实现缺失”，而是硬件供电缺陷放大了调试噪声。
3. 外部参考对软件排查有帮助，但不能替代板级供电与焊接检查。

当前最可信判断

最终确认的板级问题为：

1. CH390D 供电滤波电容虚焊。
2. 该虚焊导致供电稳定性不足，从而引出不稳定的寄存器读写、链路与收发行为。

版本库状态

本轮已创建一个阶段性 checkpoint commit：

1. 1808f99 fix: harden CH390 bring-up diagnostics

该提交记录了：

1. warning 清理
2. 移除重复复位
3. CH390 早期 identity gate
4. 链路变化稳定等待

推荐的下一步

后续更高价值的工作不再是继续怀疑 CH390 是否“完全不通”，而是：

1. 在硬件问题修复后补充长时间稳定性测试。
2. 验证 TCP Server / TCP Client 业务流量与桥接逻辑在修复硬件后的行为。
3. 保持驱动层日志最小化，仅在重新排障时按需开启详细 RTT。

收尾说明

本轮循环的退出条件已经满足：软件主路径已验证，且硬件根因已定位。

因此当前最合理的结论是：

1. CH390D 驱动、lwIP netif、ARP 和 ICMP 基本链路已在实机打通。
2. 本轮真正拦路的不是普通软件逻辑，而是板级供电滤波电容虚焊。
3. 后续应在硬件修复后的稳定板卡上继续推进应用层联调与文档收口。