diff --git a/工程调试指南.md b/工程调试指南.md index e2b7169..f111f7b 100644 --- a/工程调试指南.md +++ b/工程调试指南.md @@ -144,6 +144,59 @@ 4. `ch390_runtime_output()` 是否能正确等待 `TCR_TXREQ` 清零并发送帧 5. 网络端与 UART2/UART3 透传是否联通 +### 5.4.1 最小 TCP 调试工具 + +当需要验证 `TCP server(8080)` 到 `TCP client(8081)` 的原始桥接行为时,优先使用仓库内置的最小工具,而不是直接依赖 VOFA 这类带协议/显示假设的上位机工具。 + +推荐工具如下: + +1. `tools/tcp_debug_server.py` + - 纯 Python 原始 TCP 服务端 + - 可直接打印连接、收包、文本视图和十六进制视图 + - 适合确认“板子到底有没有把原始 payload 发到 PC 的 8081 端口” +2. `tools/start_tcp_debug_server.ps1` + - PowerShell 包装脚本 + - 会先清理本机 `8081` 端口上的现有监听,再启动 Python 调试服务端 + - 适合避免 `ncat`、遗留 Python、VOFA 等进程抢占 `8081` + +推荐使用方法: + +```powershell +powershell -ExecutionPolicy Bypass -File ".\tools\start_tcp_debug_server.ps1" -Port 8081 -NoStdin +``` + +如需回显模式: + +```powershell +powershell -ExecutionPolicy Bypass -File ".\tools\start_tcp_debug_server.ps1" -Port 8081 -Echo +``` + +直接运行 Python 服务端也可以: + +```powershell +python .\tools\tcp_debug_server.py --host 0.0.0.0 --port 8081 --no-stdin +``` + +使用该工具时,推荐调试顺序如下: + +1. 先关闭 VOFA、`ncat` 和其它可能占用 `8081` 的进程 +2. 启动 `start_tcp_debug_server.ps1` +3. 再让板子连接 `192.168.31.1:8081` +4. 然后从 PC 连接板子的 `192.168.31.100:8080`,发送一段明确文本,例如 `hello` +5. 观察 Python 工具是否打印: + - 客户端已连接 + - 收到的原始字节长度 + - 文本视图与十六进制视图 + +如果板子 RTT 显示 `TCP client connected to ...:8081`,但 Python 工具没有任何连接提示,优先检查本机端口占用: + +```powershell +Get-NetTCPConnection -LocalPort 8081 -ErrorAction SilentlyContinue | +Select-Object LocalAddress,LocalPort,RemoteAddress,RemotePort,State,OwningProcess +``` + +若存在多个监听者,优先清理后再测,否则板子可能连接到错误的本机进程。 + ### 5.5 P4:验证系统级联调 最终再验证: @@ -191,6 +244,7 @@ 3. 不要在没有芯片脚侧证据前,只凭 MCU 侧 GPIO 就认定 `RST/CS/SCK/MISO` 正常 4. 不要在基础寄存器读写尚不可信时,直接调高层 `TCP/UART` 业务逻辑 5. 不要把一次性的 bring-up 实验代码长期留在正式启动路径中 +6. 不要让 `VOFA`、`ncat`、自写 Python 服务端等多个进程同时监听 `8081`;否则板子可能连接到错误的本机进程,导致 RTT 显示 `connected` 但目标工具无数据 ## 8. 当前推荐结论表达方式 @@ -210,3 +264,5 @@ 2. `CH390D_硬件检查指南.md` 3. `uart-ch390-debug-handoff.md` 4. `PCB/SCH_Schematic1_2026-03-26.pdf` +5. `tools/tcp_debug_server.py` +6. `tools/start_tcp_debug_server.ps1`