docs: add tcp bridge debug tool workflow

工程调试指南.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`