【CAN】CAN通信协议栈


前言

CAN(Controller Area Network)是汽车电子中应用最广泛的一种通信总线。就目前笔者所接触到的开发模式,都是从EB或者Vector公司买来软件包进行配置,然后自动生成这部分代码,也就是说手写的不多。虽然不需要手写代码,但是基本的框架和思想还是要知道的,不然很可能出现即使有工具也配不出来的情况。


一、框架

1.CAN通信协议的概念

在AUTOSAR框架下,CAN通信协议栈位于运行时环境(RTE)和微控制器抽象层(MCAL)之间,以实现应用层和底层之间的数据交互,总体框架如下图所示:
 CAN通信协议栈架构

(1)CAN Driver:硬件相关,CAN驱动
(2)CAN IF:CAN Interface,主要实现驱动和上层之间联系的接口
(3)CAN TP:CAN Transport Protocol,负责CAN报文的组包拆包
(4)PDUR:PDU(Protocol Data Uint),PDU路由器,起路由作用。
CAN的通信消息分为3种,App报文、NM报文和诊断报文, PDUR将接收到的App报文和诊断报文区分开来,分别发给COM模块和DCM模块
(5)COM:服务层通信,COM层就是负责App报文通信的
(6)DCM:诊断通信模块

2.通信过程

数据发送:
CAN总线数据发送示意(图源:Vector)

(1)COM层收到应用层信号(Signal),写入PDU Buffer
(2)PDUR将PDU发送至Interface相应通道
(3)Interface再把数据发送到CAN驱动,最终实现数据发送

数据接收:
CAN总线数据接收示意(图源:Vector)
(1)CAN Driver发出Rx中断,数据被传输到Interface
(2)Interface传给PDUR
(3)PDUR把数据传给COM层,最终通过RTE层传给应用层

<think>好的,我现在需要回答用户关于AUTOSAR CAN通信协议栈的常见问题及解决方法。首先,我需要回忆一下AUTOSAR的基本架构,特别是CAN通信协议栈的组成部分。AUTOSAR的分层结构包括应用层、RTE、基础软件层(BSW)等,其中CAN协议栈属于BSW的一部分,可能涉及CAN接口模块、CAN驱动、CAN状态管理、传输协议模块等。 用户提到的问题可能包括通信失败、总线负载过高、报文丢失或错误、节点无法通信、休眠唤醒问题等。我需要针对每个问题分析可能的原因,比如配置错误、硬件问题、协议栈参数设置不当等。同时,要结合引用内容,特别是引用[3]中提到的LIN总线的错误率问题,但用户关注的是CAN,所以可能需要对比说明CAN的CRC校验机制更可靠,但配置错误仍可能导致问题。 接下来,我需要考虑解决方案和故障排查步骤。例如,检查PDU路由配置、确认波特率设置、使用诊断工具读取故障码(引用[1]中的故障码概念),以及Vector工具链的支持(引用[2]提到Vector提供调试工具)。还需要提到如何利用CANoe等工具监测总线负载,分析日志,检查硬件连接等。 可能的相关问题需要围绕用户的问题扩展,比如与其他协议的对比、具体工具的使用、如何优化配置等。需要确保回答结构清晰,分点列出问题、原因和解决方法,并正确引用相关材料。</think>### AUTOSAR CAN通信协议栈常见问题及解决方法 #### 1. **通信失败或报文丢失** - **原因**: - CAN控制器初始化参数错误(如波特率配置不匹配)[^3] - PDU路由配置错误,导致报文未正确映射到信号层 - 硬件问题(如终端电阻缺失、线缆阻抗异常) - **解决方法**: - 使用工具(如CANoe)校验总线波形和波特率设置 - 检查`CanIf`模块的PDU路由表配置,确认信号与报文ID的映射关系 - 通过示波器检测总线物理层信号质量 #### 2. **总线负载过高** - **原因**: - 周期性报文发送频率设置过高 - 错误帧或重传机制触发频繁 - **解决方法**: - 使用`CanSM`(CAN状态管理器)优化通信模式,动态调整报文周期 - 启用硬件过滤器减少无效报文接收 - 分析总线日志,统计负载峰值并调整ECU通信调度策略 #### 3. **节点无法进入休眠/唤醒异常** - **原因**: - `CanTrcv`(CAN收发器驱动)未正确处理低功耗模式切换 - 网络管理报文(NM-PDU)超时配置错误 - **解决方法**: - 检查`CanTrcv`的电源管理模式与硬件规格是否匹配 - 配置`CanNM`模块的休眠阈值和唤醒条件,例如: ```c CanNm_SetState(NetworkHandle, CANNM_STATE_READY_SLEEP); ``` #### 4. **校验错误或CRC故障** - **原因**: - CAN协议栈的CRC算法实现与硬件不兼容 - 报文DLC(数据长度码)与实际数据长度冲突 - **解决方法**: - 对比`CanDrv`驱动层与控制器寄存器配置的CRC校验方式 - 使用`DBC`数据库文件验证信号长度和对齐方式 #### 5. **诊断通信故障(UDS/OBD)** - **原因**: - 诊断报文(如$10 02$服务)未正确路由到`CanTp`模块 - 多帧传输(Multi-Frame)超时时间设置过短 - **解决方法**: - 在`CanTp`模块中配置`N_BS`(块大小)和`N_CR`(重试次数)参数 - 通过诊断工具(如Vector的Indigo)模拟发送诊断请求并捕获响应[^2] --- ###
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值