docs: record CH390 hardware-bound conclusion

CH390_最终结论报告.md

@@ -0,0 +1,113 @@
+# CH390 最终结论报告
+
+## 结论
+
+本轮循环调试的最终结论是：
+
+1. 当前工程中的主要软件问题已经完成收敛和清理。
+2. CH390D 仍然无法建立可信通信，但最新证据已不再支持“继续修改普通软件逻辑即可修好”的判断。
+3. 更可信的当前根因方向是硬件/总线/器件侧无响应。
+
+## 已完成的软件侧工作
+
+本轮已完成并验证的事项包括：
+
+1. 修复 PHY 访问无超时导致的永久卡死风险。
+2. 修复未初始化 IWDG 句柄刷新导致的 HardFault。
+3. 清理 CH390 运行时中断屏蔽范围，消除阻塞式 SPI 访问造成的运行时假死。
+4. 重构 CH390 运行时所有权，避免多层并发触达底层 SPI 路径。
+5. 在 `main()` 中移除重复 CH390 复位，避免启动阶段额外复位噪声。
+6. 清理已确认 warning 来源，避免无效变量继续污染构建结果。
+7. 增加 CH390 identity gate，避免在无效寄存器读回前继续执行默认配置和 PHY 初始化。
+8. 增加 bit-bang 诊断读，专门区分 STM32 硬件 SPI 实现问题和板级总线/器件无响应问题。
+
+## 实机关键证据
+
+### 1. MCU 自身正常工作
+
+已验证：
+
+1. RTT 正常输出。
+2. 主循环正常运行。
+3. `TIM4` 心跳正常。
+4. 运行期不再出现此前已修复的 HardFault 和“长时间假死”症状。
+
+### 2. 硬件 SPI 读 CH390 恒为全 `0xFF`
+
+RTT 实测：
+
+```text
+TCP2UART boot
+ETH init: gpio
+ETH init: spi
+ETH init: reset
+ETH init: probe
+ETH init: invalid chip id
+CH390 VID=0xFFFF PID=0xFFFF REV=0xFF NSR=0xFF LINK=0
+CH390 NCR=0xFF RCR=0xFF IMR=0xFF INTCR=0xFF GPR=0xFF ISR=0xFF
+```
+
+### 3. bit-bang 读 CH390 仍为全 `0xFF`
+
+在绕过 STM32 硬件 SPI 外设、直接用 GPIO 软件时序读取 `VIDL/VIDH/PIDL/PIDH/CHIPR` 后，RTT 输出为：
+
+```text
+CH390 bitbang VIDL=0xFF VIDH=0xFF PIDL=0xFF PIDH=0xFF CHIPR=0xFF
+```
+
+这一点非常关键，因为它说明：
+
+1. 问题不再像单纯的 `SPI1` 模式寄存器或 HAL 事务实现错误。
+2. 即使 MCU 直接软件驱动 `CS/SCK/MOSI`，CH390 端仍未给出有效响应。
+
+## 外部参考对结论的支撑
+
+对公开 CH390 / DM9051 实现的对照结果表明：
+
+1. 工作实现普遍使用 `mode 0` 与 `1-bit command + 7-bit address` 事务模型。
+2. packet SRAM 连续事务在这些实现中通常是一次完整 burst，而不是随意拆成多个碎片事务。
+3. 这些信息对后续软件兼容性优化仍有价值。
+4. 但它们更适用于“基础寄存器读写已经成立之后”的阶段。
+5. 对“开机就连 `VID/PID` 都全 `0xFF`”这一症状，公开实现并不支持把根因优先归到 packet SRAM 分帧之类的高层软件问题。
+
+## 当前最可信判断
+
+当前更可信的方向是以下一种或多种板级问题：
+
+1. `CS` 没有真正选中 CH390。
+2. `MISO` 没有被 CH390 主动驱动，处于悬空上拉高状态。
+3. `RST` 在 CH390 芯片引脚侧没有真正达到有效复位/释放条件。
+4. CH390 电源、内部数字核、PHY 供电或相关时序不满足器件进入 SPI 可响应状态的条件。
+5. 芯片本体损坏，或者焊接/连线仍有隐患。
+
+## 版本库状态
+
+本轮已创建一个阶段性 checkpoint commit：
+
+1. `1808f99` `fix: harden CH390 bring-up diagnostics`
+
+该提交记录了：
+
+1. warning 清理
+2. 移除重复复位
+3. CH390 早期 identity gate
+4. 链路变化稳定等待
+
+## 推荐的下一步
+
+此后不建议继续盲目修改普通软件逻辑。更高价值的下一步应是板级取证：
+
+1. 抓取 `CS/SCK/MOSI/MISO/RST/INT` 的实际波形。
+2. 确认 CH390 芯片引脚侧 `RST` 真实状态，而不是只看 MCU 端 GPIO 输出假设。
+3. 确认 `MISO` 是否被器件主动驱动，而不是上拉或悬空导致读到全高。
+4. 确认供电、地、焊接、封装方向、芯片型号与原理图一致。
+
+## 收尾说明
+
+本轮循环的退出条件已经满足“确定软件无明显剩余普通逻辑问题，而更像硬件存在问题”。
+
+因此当前最合理的结论不是“CH390 软件已经完全正确”，而是：
+
+1. 软件侧已经做到了足够强的隔离和验证。
+2. 继续在没有新硬件证据的前提下反复改驱动，收益已经明显下降。
+3. 应转入硬件/总线取证阶段。