docs: record CH390 hardware-bound conclusion

项目技术实现.md

@@ -10,7 +10,8 @@
 2. 软件架构改为 `bare-metal main loop + DMA/IDLE + EXTI`
 3. 网络栈采用 `lwIP RAW API + NO_SYS=1`
 4. 调试输出采用 `SEGGER RTT`
-5. 构建目标已通过 `MDK-ARM` 编译，适配 `64KB Flash / 20KB SRAM`
+5. `CH390` 运行时访问已收敛为单一拥有者 `ch390_runtime`
+6. 构建目标已通过 `MDK-ARM` 编译，适配 `64KB Flash / 20KB SRAM`
 
 ## 二、硬件与资源约束
 
@@ -30,6 +31,12 @@
 - `DMA1`：UART 收发 DMA
 - `EXTI0`：CH390 中断输入
 - `IWDG`：独立看门狗
+- `TIM4`：LED 心跳定时器
+
+当前说明：
+
+1. `IWDG` 外设仍保留在工程中，但当前调试基线默认不在 `main()` 中启用 `MX_IWDG_Init()`
+2. `App_Poll()` 已对 `HAL_IWDG_Refresh(&hiwdg)` 做句柄保护，避免未初始化句柄导致 `HardFault`
 
 ### 2.3 当前引脚分配
 
@@ -80,6 +87,9 @@
 | Main Poll Loop                                   |
 | ethernetif_poll / sys_check_timeouts / watchdog  |
 +--------------------------------------------------+
+| CH390 Runtime Owner                              |
+| ch390_runtime (single runtime SPI owner)         |
++--------------------------------------------------+
 | Peripheral/Event Layer                           |
 | UART DMA+IDLE / DMA IRQ / EXTI / SysTick         |
 +--------------------------------------------------+
@@ -93,9 +103,10 @@
 当前执行模型为：
 
 1. `SysTick` 提供全局毫秒时基
-2. `EXTI0` 只置位 CH390 待处理标志
+2. `EXTI0` 只置位 CH390 待处理标志，不直接做 SPI/CH390 访问
 3. `DMA IRQ` 和 `UART IRQ` 只完成回调分发与 IDLE 采样
-4. 主循环统一执行网络轮询、超时推进、串口桥接和看门狗喂狗
+4. `ch390_runtime` 成为唯一的 CH390 运行时访问源
+5. 主循环统一执行网络轮询、超时推进、串口桥接和看门狗喂狗
 
 ## 五、当前模块实现状态
 
@@ -156,8 +167,16 @@
 
 1. `SPI1 + GPIO CS + EXTI0` 驱动 CH390
 2. `ethernetif.c` 采用 `NO_SYS=1` 路线
-3. CH390 中断在主循环中轮询处理
-4. 配置中的 MAC 地址会在初始化时写入 CH390
+3. 新增 `Drivers/CH390/ch390_runtime.c`，统一负责 CH390 初始化、链路查询、IRQ pending 消费、RX/TX 服务与启动诊断快照
+4. `main.c` 不再直接读取 CH390 原始寄存器，启动诊断通过 `ch390_runtime_get_diag()` 获取快照
+5. `EXTI0_IRQHandler()` 只投递 IRQ pending，不再直接混入 CH390 访问
+6. 配置中的 MAC 地址会在初始化时写入 CH390
+
+当前状态：
+
+1. 运行时架构层面的 `SPI/LwIP/CH390` 多源访问问题已经消除
+2. `HardFault` 与“运行一会儿卡死”问题已修复
+3. CH390 当前仍未建立可信通信，最近稳定读回表现为全 `0xFFFF` 或全 `0x0000`，说明剩余问题已经收敛到低层器件响应/总线层面，而不再是运行时并发问题
 
 ### 5.6 RTT 调试输出
 
@@ -227,7 +246,9 @@ while (1)
         NVIC_SystemReset();
     }
 
-    HAL_IWDG_Refresh(&hiwdg);
+    if (hiwdg.Instance == IWDG) {
+        HAL_IWDG_Refresh(&hiwdg);
+    }
 }
 ```
 
@@ -244,11 +265,9 @@ while (1)
 当前构建结果：
 
 1. `0 Error(s)`
-2. `0 Warning(s)`
-3. `Code=39988`
-4. `RO-data=1272`
-5. `RW-data=172`
-6. `ZI-data=19188`
+2. 当前收敛目标已变更为 `0 Warning(s)`，并已在源码中清理已确认的未使用变量/重复复位噪声
+3. 代码体积仍满足 `STM32F103R8T6` 资源约束
+4. `MDK-ARM` 工程可直接编译并下载验证
 
 说明当前版本已经满足：
 
@@ -261,13 +280,16 @@ while (1)
 ### 9.1 功能限制
 
 1. 当前使用静态 IP，不支持 DHCP
-2. 目前未提供上板网络与串口吞吐测试结论
-3. `config` 模块仍保留较重的字符串解析逻辑，但当前体积已可接受
+2. CH390 当前仍未返回可信的 `VID/PID/REV`，最新稳定读回表现为全 `0xFFFF/0xFF`
+3. 因此当前不能宣称网络链路已经真正建立，`LINK` 位读数也不可信
+4. 目前未提供上板网络与串口吞吐测试结论
+5. `config` 模块仍保留较重的字符串解析逻辑，但当前体积已可接受
+6. 新增 bit-bang 诊断读也返回全 `0xFF`，说明问题不再像单纯的 STM32 硬件 SPI 外设配置错误
 
 ### 9.2 上板验证重点
 
-1. 验证 CH390 INT 极性与 EXTI 触发行为
-2. 验证 `SPI1` 与 CH390 的稳定性
+1. 验证 CH390 `CS/SCK/MOSI/MISO/RST/INT` 的实际波形与极性是否和当前软件假设一致
+2. 重点验证为何 CH390 在硬件 SPI 与 bit-bang 两条读路径下都稳定返回 `0xFFFF/0xFF`
 3. 验证 `TIM4` 1ms 中断稳定性与 `PC13` 1秒翻转节拍
 4. 验证 `UART2/UART3 DMA + IDLE` 在长连续流量下的行为
 5. 验证 TCP Server 与 TCP Client 双链路同时工作时的稳定性
@@ -277,8 +299,19 @@ while (1)
 
 下一阶段建议按以下顺序推进：
 
-1. 上板联调 CH390 链路与 RTT 输出
-2. 验证 UART2/3 透传功能
-3. 补充双向透传稳定性与丢包测试
-4. 视需要继续优化 `config.c` 的体积与命令集
-5. 若后续必须支持 DHCP，再单独评估资源预算
+1. 暂停继续盲目修改 CH390 软件驱动；当前软件侧已基本排除到足以支持硬件优先排查
+2. 先做板级波形与供电/复位取证，重点看 `CS/SCK/MOSI/MISO/RST`
+3. 若板级取证证明 CH390 端真实有响应，再回到软件侧处理 `mode0` 与 packet SRAM 连续事务等兼容性问题
+4. 在 CH390 可可信通信后，再验证真正的链路建立、收发与中断路径
+5. 验证 UART2/3 透传功能
+6. 补充双向透传稳定性与丢包测试
+
+## 十一、当前结论
+
+截至本轮调试：
+
+1. 系统主循环、RTT、定时器心跳、UART 配置路径均可正常工作
+2. 已修复并验证多个真实软件问题，且相关中间里程碑已提交版本库
+3. CH390 当前失败边界已被压缩到“器件未在总线上给出可信响应”
+4. 在相同板卡上，硬件 SPI 读寄存器与 bit-bang 读寄存器均返回全 `0xFF`
+5. 因此最可信的当前判断是：剩余问题更偏向硬件/总线/器件状态，而不是普通软件逻辑错误