docs: README 同步电机控制台, 记下邮箱楔死判据

脚本表: 四个已删探针换成 motor.html/motor.js 与 test_motor_backend.py。
启动说明: 补电机控制台入口(/motor.html, 需先连接并进 OP)。
注意事项: 记下"SM 寄存器正常但 SDO 持续失败 = SSC u16EscAddrSendMbx 错位"
这个判据与固件 1.5.52 分界; 提醒 ecat.css 被两个页面共用, ?v= 要一起 bump。

README.md

@@ -27,10 +27,8 @@ venv\Scripts\python.exe -m pip install -r requirements.txt
 | `ecat_esc_regs.py` | 从**网络侧**直读 LAN9252 ESC 寄存器，绕开 GD32/PDI，用于判断 EEPROM 加载是否真的失败；支持 `--reload` |
 | `ecat_flash_eeprom.py` | 通过网线烧写 `gen_eeprom.py` 生成的 SII 镜像，逐字回读校验（烧完需断电重启让 ESC 重新加载） |
 | `ecat_sniff.py` | 旁路抓包，hexdump SOEM 自己发出的帧，用于对照裸帧格式 |
-| `_probe_wedge.py` | 邮箱楔死现场逐环节定位：A 写 SM0 的 WKC → B `0x220` bit0 是否置位 → C SSC 是否清事件并置 SM1 就绪 → D SM1 是否滞留旧响应，用于区分 ESC 硬件楔死与 SSC 软件死循环 |
-| `_probe_wedge2.py` | 按真实邮箱协议探测：查写邮箱空 → 写满 256B → 验事件/响应 |
-| `_probe_stuck.py` | 验证「SM1 响应滞留 → 邮箱死锁」假说：复现失败 → 手动读走 SM1 清 bit3 → 再读是否恢复 |
-| `_probe_scan.py` | 扫描定位响应帧头在 SM1 RAM 中的确切偏移，同步 dump SM0 请求侧 |
+| `motor.html` / `motor.js` | 电机控制台：N1–N9 九节点，走 EtherCAT 过程数据（不经 WiFi/HTTP）。节点总览、8 种 Control_Mode、STATUS 实时解码、示波器曲线 |
+| `test_motor_backend.py` | 电机后端自测，**不接硬件**（假从站模拟 GD32 buildInput/processOutput）。跑法：`venv\Scripts\python.exe test_motor_backend.py` |
 
 ## 启动方式
 
@@ -42,9 +40,17 @@ venv\Scripts\python.exe -m pip install -r requirements.txt
 | `ecat.bat` | 命令行工具入口，如 `ecat.bat status`、`ecat.bat flash` |
 | `run_scan.bat` | 直接跑 bring-up 扫描，无参数则列出 Npcap 适配器 |
 
+电机控制台在服务起来后从主页右上「电机控制台」进入，或直接访问 `/motor.html`。
+它只读写 EtherCAT 过程数据，需先在主页点「连接」并让从站进入 OP。
+
 ## 注意
 
 - ESC 的 SyncManager 寄存器是 `0x0800 + 8n`：邮箱是 SM0=`0x0800`、SM1=`0x0808`，
   `0x0810`/`0x0818` 是 SM2/SM3（过程数据）。写诊断代码时别混用，否则抓到的现场会误导判断。
+- **邮箱楔死判据**：SM0/SM1 寄存器正常（start=0x1000/0x1200、act=01）但 SDO 持续失败，
+  就是 SSC 的 `u16EscAddrSendMbx` 错位——响应帧写到 SM1 start+4/+8 且逐会话累积，
+  断电才清零。固件 <1.5.52 无自愈需断电重启，1.5.52+ 有守护自动写回。
+  `config_map` 失败时后端会自动转储 4 个 SM 现场，可直接对照。
 - 前端 CSS/JS 改动后记得 bump `?v=` 缓存版本，否则浏览器会加载旧代码。
+  `ecat.css` 被 `ecat.html` 与 `motor.html` 共用，两处版本号要一起改。
 - EEPROM 烧写后必须断电冷启动，ESC 才会重新加载配置。