fix: restore CH390 bridge flow and sync driver docs

CH390_最终结论报告.md

@@ -5,8 +5,8 @@
 本轮循环调试的最终结论是：
 
 1. 当前工程中的主要软件问题已经完成收敛和清理。
-2. CH390D 仍然无法建立可信通信，但最新证据已不再支持“继续修改普通软件逻辑即可修好”的判断。
-3. 更可信的当前根因方向是硬件/总线/器件侧无响应。
+2. CH390D 驱动、lwIP `netif`、ARP 与 ICMP 基本链路已经在实机上打通。
+3. 本轮最终根因已确认不是普通软件逻辑错误，而是 CH390D 相关供电滤波电容虚焊，导致供电不稳定。
 
 ## 已完成的软件侧工作
 
@@ -32,20 +32,18 @@
 3. `TIM4` 心跳正常。
 4. 运行期不再出现此前已修复的 HardFault 和“长时间假死”症状。
 
-### 2. 硬件 SPI 读 CH390 恒为全 `0xFF`
+### 2. 最终硬件根因已定位
 
-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
-```
+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 对照结果（已归档）
 
@@ -57,28 +55,23 @@ CH390 bitbang VIDL=0xFF VIDH=0xFF PIDL=0xFF PIDH=0xFF CHIPR=0xFF
 
 该历史证据用于定位阶段，当前仅保留结论，不再保留对应代码路径。它说明：
 
-1. 问题不再像单纯的 `SPI1` 模式寄存器或 HAL 事务实现错误。
-2. 即使 MCU 直接软件驱动 `CS/SCK/MOSI`，CH390 端仍未给出有效响应。
+1. 在硬件未修复前，单看软件现象会误导排查方向。
+2. 电源完整性问题会放大为看似“SPI/IRQ/RX/TX 都可疑”的复合症状。
 
 ## 外部参考对结论的支撑
 
 对公开 CH390 / DM9051 实现的对照结果表明：
 
-1. 工作实现普遍使用 `mode 0` 与 `1-bit command + 7-bit address` 事务模型。
-2. packet SRAM 连续事务在这些实现中通常是一次完整 burst，而不是随意拆成多个碎片事务。
-3. 这些信息对后续软件兼容性优化仍有价值。
-4. 但它们更适用于“基础寄存器读写已经成立之后”的阶段。
-5. 对“开机就连 `VID/PID` 都全 `0xFF`”这一症状，公开实现并不支持把根因优先归到 packet SRAM 分帧之类的高层软件问题。
+1. CH390 SPI 访问时序、模式选择和 RX SRAM 连续事务仍然值得严格对照参考实现。
+2. 但本项目最终问题并非“参考实现缺失”，而是硬件供电缺陷放大了调试噪声。
+3. 外部参考对软件排查有帮助，但不能替代板级供电与焊接检查。
 
 ## 当前最可信判断
 
-当前更可信的方向是以下一种或多种板级问题：
+最终确认的板级问题为：
 
-1. `CS` 没有真正选中 CH390。
-2. `MISO` 没有被 CH390 主动驱动，处于悬空上拉高状态。
-3. `RST` 在 CH390 芯片引脚侧没有真正达到有效复位/释放条件。
-4. CH390 电源、内部数字核、PHY 供电或相关时序不满足器件进入 SPI 可响应状态的条件。
-5. 芯片本体损坏，或者焊接/连线仍有隐患。
+1. CH390D 供电滤波电容虚焊。
+2. 该虚焊导致供电稳定性不足，从而引出不稳定的寄存器读写、链路与收发行为。
 
 ## 版本库状态
 
@@ -95,19 +88,18 @@ CH390 bitbang VIDL=0xFF VIDH=0xFF PIDL=0xFF PIDH=0xFF CHIPR=0xFF
 
 ## 推荐的下一步
 
-此后不建议继续盲目修改普通软件逻辑。更高价值的下一步应是板级取证：
+后续更高价值的工作不再是继续怀疑 CH390 是否“完全不通”，而是：
 
-1. 抓取 `CS/SCK/MOSI/MISO/RST/INT` 的实际波形。
-2. 确认 CH390 芯片引脚侧 `RST` 真实状态，而不是只看 MCU 端 GPIO 输出假设。
-3. 确认 `MISO` 是否被器件主动驱动，而不是上拉或悬空导致读到全高。
-4. 确认供电、地、焊接、封装方向、芯片型号与原理图一致。
+1. 在硬件问题修复后补充长时间稳定性测试。
+2. 验证 TCP Server / TCP Client 业务流量与桥接逻辑在修复硬件后的行为。
+3. 保持驱动层日志最小化，仅在重新排障时按需开启详细 RTT。
 
 ## 收尾说明
 
-本轮循环的退出条件已经满足“确定软件无明显剩余普通逻辑问题，而更像硬件存在问题”。
+本轮循环的退出条件已经满足：软件主路径已验证，且硬件根因已定位。
 
-因此当前最合理的结论不是“CH390 软件已经完全正确”，而是：
+因此当前最合理的结论是：
 
-1. 软件侧已经做到了足够强的隔离和验证。
-2. 继续在没有新硬件证据的前提下反复改驱动，收益已经明显下降。
-3. 应转入硬件/总线取证阶段。
+1. CH390D 驱动、lwIP `netif`、ARP 和 ICMP 基本链路已在实机打通。
+2. 本轮真正拦路的不是普通软件逻辑，而是板级供电滤波电容虚焊。
+3. 后续应在硬件修复后的稳定板卡上继续推进应用层联调与文档收口。