自研 USB CAN 板：CAN FD 5M 收发验证
这次测试对象是采用 CANable 2.0 硬件方案的自研 USB CAN 板，有三颗独立 STM32G431 MCU。它与之前测试的 RK3588 / 5IO 开发板是两块不同的板。
结论：CAN0 ↔ CAN1 在本轮 FD 1M/5M 物理收发中通过完整性检查。CAN2 已刷写并启动，尚未接线，未做物理收发验证。
硬件与软件环境
| 项目 | 本次条件 |
|---|---|
| 接线 | CAN0 与 CAN1 对接，真实物理总线，未使用内部回环 |
| 主控 | STM32G431 × 3，各通道独立刷写 |
| 固件 | 上游 normaldotcom/canable2-fw，固定提交 b158aa7，未修改上游固件 |
| 主机接口 | USB CDC / ttyACM*，非标准 SLCAN FD 协议 |
| 位时序配置 | 仲裁 1 Mbit/s，FD 数据 5 Mbit/s，BRS 开启 |
| 连续测试负载 | 每帧 64 字节，逐帧核对对端序号、ID、长度和完整载荷 |
实际收发结果
| 阶段 | 发送窗口 | 实收帧数 | 实际帧率 | 完整性 |
|---|---|---|---|---|
| CAN0 → CAN1 | 10 秒 | 16,603 | 1,660.30 帧/秒 | 缺失、重复、内容错误、乱序均为 0 |
| CAN1 → CAN0 | 10 秒 | 16,615 | 1,661.50 帧/秒 | 缺失、重复、内容错误、乱序均为 0 |
| 同时双向 | 60 秒 | 每方向 54,929 | 每方向 915.48 帧/秒 | 缺失、重复、内容错误、乱序均为 0 |
三阶段合计 143,076 帧全部收到。固件 E 错误寄存器均返回 0。
另外完成两组独立检查：
- Classic 1M、FD 2M / 5M 功能测试共 164 帧，覆盖标准 / 扩展 ID，以及 Classic 0–8 字节和 FD 全部合法长度。
- 发布版 CLI 再测双向 5 秒、4,565 帧，全部收到；这组数据与上表分别计数。
5M 和实际吞吐有什么区别
这里的 5M 是 FD 数据阶段的配置位速率。单向测试实际有效载荷约 0.85 Mbit/s；USB ASCII 协议、程序调度以及 CAN 帧开销都会影响应用吞吐。
本次没有把总线跑满。最长同时双向窗口为 60 秒，不能据此推断数小时或数天运行的丢包率。完整 TEC / REC 硬件计数及示波器位宽均未取得，E 寄存器不能替代这些测量。
三个通道分别验证到了哪一步
| 通道 | 原 Flash 备份 | 逐字节读回 | 重启版本查询 | 对端收发 |
|---|---|---|---|---|
| CAN0 | 完成 | 通过 | 通过 | Classic 1M、FD 2M / 5M 通过 |
| CAN1 | 完成 | 通过 | 通过 | Classic 1M、FD 2M / 5M 通过 |
| CAN2 | 完成 | 通过 | 通过 | 未接线，未运行 |
过程中发现的串口抢读
机器上已有 root 电池程序会扫描并抢读 ttyACM*，导致 USB 串口回复被截取。原连续测试临时排除了该进程对所选端口的访问，测试后恢复；发布版工具会检查占用并拒绝运行。
TIOCEXCL 不能阻止 root 进程抢读。后续正式集成应修正电池程序的设备选择，避免把串口被抢读误判为 CAN 物理丢包。
报告与原始记录
下一步可以补测 CAN2 对端收发、总线满载、更长时间运行，以及独立分析仪或示波器测量。