太好了 👍 这个问题非常典型,也非常有学习价值。
我帮你把整个排查逻辑完整梳理一遍,你可以直接当笔记保存。
一、问题现象
-
CAN 总线上能看到报文
-
RTE 收不到信号
-
COM 层 IPDU Callout 不触发
二、接收路径完整链路(标准 AUTOSAR)
在 AUTOSAR 架构中,
CAN 报文接收流程如下:
CAN总线
→ CanDrv
→ CanIf_RxIndication()
→ PduR_CanIfRxIndication()
→ Com_RxIndication()
→ Com_RxIndication_Processing()
→ Callout
→ Signal unpack
→ Rte_Write()
三、你本次排查的过程
第一步:确认底层是否收到
你验证了:
-
✅ CanIf_RxIndication 进入
-
✅ PduR_CanIfRxIndication 进入
-
✅ Com_RxIndication 进入
结论:
报文已经成功到达 COM 层
问题一定在 COM 内部。
第二步:发现进不了 Processing
你发现:
Com_RxIndication_Processing() 进不去
这说明:
COM 在进入真正处理前被拦截
第三步:定位拦截条件
在 COM 源码中一般有逻辑:
if (Com_RxPduGrpActive[groupIndex] == TRUE)
{
Com_RxIndication_Processing();
}
你查看到:
Com_RxPduGrpActive[2] == 0
这说明:
该 Rx I-PDU 所属的 IPduGroup 没有被启动
四、问题本质
❗ 不是"报文没收到"
❗ 不是"DLC 不匹配"
❗ 不是"UpdateBit"
❗ 不是"PduR 路由错误"
真正原因是:
IPduGroup 未被 Start
五、AUTOSAR 中的关键机制
在 AUTOSAR COM 里:
-
每个 I-PDU 必须属于某个 ComIPduGroup
-
只有 Group 被启动(Com_IpduGroupStart)后
-
才会真正处理接收报文
否则:
-
进入 Com_RxIndication
-
但不会进入 Processing
-
不会调用 Callout
-
不会更新信号
-
不会通知 RTE
六、为什么 AUTOSAR 要这样设计?
因为需要支持:
-
网络管理(NM)
-
总线 Sleep / Wakeup
-
模式切换
-
诊断模式
-
Partial Networking
所以报文的启停必须可控。
七、完整排查思路总结(建议收藏)
以后遇到:
RTE 收不到信号
按这个顺序查:
✅ 1️⃣ CanIf_RxIndication 是否进入?
- 否 → 看硬件滤波 / HRH / 波特率
✅ 2️⃣ PduR_CanIfRxIndication 是否进入?
- 否 → 看 PduR 路由配置
✅ 3️⃣ Com_RxIndication 是否进入?
- 否 → 看 RxPduId 映射
✅ 4️⃣ Com_RxIndication_Processing 是否进入?
-
否 → 重点检查:
-
IPduGroup 是否 Start ⭐⭐⭐⭐⭐
-
RxPduGrpActive 数组
-
Group 索引是否匹配
-
✅ 5️⃣ Processing 进了但无信号?
再检查:
-
DLC 是否匹配
-
UpdateBit
-
Rx Filter
-
Signal byte order
八、本次问题的最终结论
你这个问题的核心是:
Com_RxPduGrpActive[groupIndex] == 0
导致:
Com_RxIndication_Processing() 不执行
解决方法:
正确调用 Com_IpduGroupStart()
或
修正 BswM 控制逻辑
九、这类问题的典型特征
| 现象 | 真正原因 |
|---|---|
| 底层都正常 | COM Group 未启动 |
| Callout 不触发 | IPduGroup 未 Active |
| RTE 无数据 | 信号未解包 |
十、经验总结(非常重要)
-
看到"收不到信号"不要直接怀疑 CAN
-
先分层确认数据走到哪
-
只要能进 Com_RxIndication
→ 80% 以上概率是 Group 或 DLC 问题
-
COM 内部不处理 ≠ 没收到报文
十一、一句话记忆法
能进 Com_RxIndication 但没信号
第一件事:看 Com_RxPduGrpActive