q11设备：RDK S100 + MCU扩展板
用途：双臂机器人遥操作与数据采集
目标：连续完成100组以上数据采集，CAN通信不中断，遥操作控制周期不受影响
一、系统和软件版本
系统版本：
4.0.3-Beta
内核版本：
Linux 6.1.112-rt43-DR-4.0.3-2508182243-g2e3829-ge68b6e
相关软件包：
hobot-multimedia 4.0.3-20250818223354
hobot-multimedia-dev 4.0.2-20250818223743
hobot-firmware 4.0.3-20250818222930
hobot-configs 4.0.3-20250818222725
动态库：
/usr/hobot/lib/libhbcanhal.so.1.0.0
/usr/hobot/lib/libhbipcfhal.so.1.0.0
MCU1固件：
S100_MCU_DEBUG.elf
使用的CANHAL目标：
CAN6：can6_ins0ch6
CAN9：can9_ins0ch3
两个通道都使用IPCF instance 0。
二、实际业务负载
CAN6：
左臂8帧CAN FD控制帧，25Hz，每周期一次合包发送
固定云台4帧Classic CAN控制帧，10Hz，每周期一次合包发送
持续接收左臂和云台反馈
CAN9：
右臂8帧CAN FD控制帧，25Hz，每周期一次合包发送
持续接收右臂反馈
IPCF配置：
fifo_size=64000
pkg_size_max=4096
recv_timeout=0
MCU侧CAN反馈合包：
CAN_IPC_MERGE_NUM=8
MERGE_TIMEOUT_US=1000
三、故障现象
系统启动和前几分钟收发正常，遥操作也正常。
持续采集一段时间后，CAN6和CAN9会在很短时间内同时出现：
[CANHAL][ERROR][ipcf_dev.cpp:160]:
HorizonHal_IPCF_Send of id:0 failed, ret is -14
[CANHAL][ERROR][ipcf_dev.cpp:160]:
HorizonHal_IPCF_Send of id:1 failed, ret is -14
应用层最终报错：
OSError: canSendMsgFrame(‘can6_ins0ch6’) failed with ret=-14
OSError: canSendMsgFrame(‘can9_ins0ch3’) failed with ret=-14
内核随后出现：
ipc-shm-hal: [0][6] can’t obtain buf size 112
并伴随channel cnt持续增加。
故障发生后，-14不会在短时间内自行恢复，新的机械臂控制帧无法发送，硬件worker退出，平台进入recovery_required，双臂停止遥操作。
四、一次完整复现数据
本次从CAN通道注册到第一次持续-14约278秒。
故障前CAN6统计：
成功发送9733个包
其中6952个8帧机械臂包
2781个4帧云台包
合计66740帧
故障前没有发送失败
故障前CAN9统计：
成功发送6954个8帧机械臂包
合计55632帧
故障前没有发送失败
故障时间：
约278.1秒，CAN6首次持续-14
约278.4秒，CAN9首次持续-14
约279.1秒，CAN6持续1秒仍未恢复
约279.6秒，CAN9持续1秒仍未恢复
两个通道开始失败的时间只相差约0.3秒。
五、已经完成的应用层排查
-
已在机械臂准备位发送第一帧前启动反馈接收，启动、等待和采集期间持续排空CAN6/CAN9反馈。
-
已将每条机械臂每周期8帧合成一个CANHAL包，不再逐帧调用canSendMsgFrame。
-
使用最新目标邮箱，旧控制目标会被新目标覆盖，不存在Python控制包无限排队。
-
CAN6和CAN9分别调度；每个通道分别有一个RX线程和一个TX线程，发送调用做了串行保护。
-
对短暂的-13/-14进行有限重试，但持续1秒不可用后安全退出，没有无限重试。
-
已记录每个通道的发送包数量、帧数量、失败次数和反馈接收调用次数。
-
故障发生期间RX线程仍在运行：
CAN6 rx_calls：151550增加到151864
CAN9 rx_calls：143747增加到143988
这说明发送失败不是因为应用停止读取反馈。
-
MCU1在故障后仍显示running，没有发现：
Enter Abort Handler
DeadLoop
remoteproc crash -
CAN6和CAN9几乎同时失败，而且都依赖IPCF instance 0，因此怀疑不是单个电机、单条CAN线或单个CAN控制器故障，而是instance 0共享发送buffer/credit无法继续获取或回收。
六、需要官方确认的问题
- HorizonHal_IPCF_Send返回-14在当前CANHAL/IPCF版本中的准确含义是什么？
安装的头文件、官方CAN示例和实际日志对-14的解释似乎不完全一致。它究竟表示channel invalid、CAN_TRY_AGAIN，还是底层no buffer？
- “ipc-shm-hal: can’t obtain buf”对应的buffer/credit正常回收流程是什么？
发送完成后由Acore驱动回收，还是必须等待MCU返回completion/ack后回收？
- CANHAL是否提供查询