CAN总线多节点通信异常分析及解决

一、CAN物理层特征

CAN收发器的作用是负责逻辑电平和信号电平之间的转换。即从CAN控制芯片输出逻辑电平到CAN收发器,然后经过CAN收发器内部转换将逻辑电平转换为差分信号输出到CAN总线上,CAN总线上的节点都可以决定自己是否需要总线上的数据。

市场上常用的收发器(例如: VP230、TJA1040、TCAN337等)多为ISO 11898标准。在此标准中,对于CAN的信号逻辑1和0的产生:当CAN_H为3.5V,CAN_L为1.5V,差值为2V左右时为显性(dominant)电平表示,而两者相等为2.5V左右时为隐性(recessive)电平表示1。

可以看到上图中的当第一段为隐性,CAN_H和CAN_L电平几乎一样,也就是说CAN_H和CAN_L电平很接近甚至相等的时候,总线表现隐性的,而两线电位差较大时表现为显性的,按照定义的:

  • CAN_H - CAN_L < 0.5V 时候为隐性的,逻辑信号表现为"逻辑1"- 高电平。
  • CAN_H - CAN_L > 0.9V 时候为显性的,逻辑信号表现为"逻辑0"- 低电平。

CAN总线采用的"线与"的规则进行总线冲裁。即1&0=0;所以0为显性。这句话隐含的意思是,如果总线上只要有一个节点将总线拉到低电平(逻辑0),即显性状态,总线就为低电平(逻辑0),即显性状态,而不管总线上有多少节点处于传输隐性状态(高电平或是逻辑1),只有所有节点都为高(隐性),总线才为高,即隐性。

CAN总线终端的两个120Ω的终端电阻的作用是使阻抗连续,消除反射。

二、CAN总线三节点通讯异常现象

测试工具:

1.PC端:利用USB转CAN模块将PC机作为一个节点挂载到CAN总线,收发器型号采用TI公司的VP230;

2.ECU:此处使用TI公司的MSP432单片机,由于其电路板没有CAN收发器,所以此处外接收发器VP230;

3.ARM开发板:开发板上已经内嵌了两个CAN通道,收发器采用的是恩智浦的TJA1040。

问题1:ARM用户板(节点1,收发器:tcan337)与ECU(节点2,收发器:vp230)两节点可以正常进行CAN通信,但是当总线上加入第3个节点PC端(节点3,USB转CAN模块,收发器:vp230)后,通信出现异常,节点1和节点3均可以正常发送和接收总线数据,但是节点2可以收到总线数据,却无法发送数据。

针对问题1,使用ARM开发板、ECU、PC分别进行了两节点测试和三节点测试,测试结果证明,PC与ARM、ECU之间的两节点通信均无任何问题;使用两个PC端与ARM、ECU之间分别构成3节点通信也均正常;使用ARM开发板上的两个CAN通道与PC端构成3节点通信也正常;使用两个ECU与PC构成3节点通信也正常。但是,当ARM开发板与ECU同时挂载到CAN总线上时,就会出现通信异常。

问题2:ARM开发板(节点1,收发器:TJA1040)与MCU(节点2,收发器:vp230)两节点进行CAN通信时,节点1发送一次数据后,总线将一直处于占用状态,此后节点1无法发送和接收总线数据,而节点2将一直读取总线数据。

问题3:当PC与ECU两节点通信时,通信正常,但是当总线接入关机状态下的ARM开发板时,总线通信出现异常,ECU将无法收到来自PC端的数据;而当总线接入工作状态下的ARM开发板时,总线异常情况与问题1相同。

三、CAN总线三节点通信异常问题成因分析与解决措施

通过了解CAN物理层特征可知,CAN_H、CAN_L在隐性状态时的对地电压均为2.5V左右,经实际测量, ARM端CAN总线隐性对地电压约为2.3V,PC端CAN总线隐性对地电压约为2.2V,而ECU端CAN总线的隐性对地电压约为1.5V,由于总线电压的差异,CAN总线的对地电压被强制拉低,导致CAN控制器无法正常识别总线数据。

当ECU端的收发器VP230的供电由3.3V更改为5V后,其总线隐性对地电压约等于2.3V,此时ARM、ECU、PC间的任意两节点、三节点通信均正常。

四、CAN总线4、5节点通信测试

为了进一步了解多节点CAN总线通信,将总线上的节点数增加至4节点和5节点,在实际测试中,利用ARM开发板上的2个CAN通道(NXP公司的TJA1040收发器)、2个 USB转CAN模块(TI公司的VP230)、1个ECU(TI公司的VP230)分别进行了各式组合,构成4节点CAN通讯均正常,但是任意5节点通信均出现异常情况,分别由各个节点发送数据,总存在一些节点无法接收到数据。

通过对CAN总线的物理层分析,认为造成这种现象可能有两个原因,一是不同型号的CAN收发器之间通信匹配的问题,二是CAN总线的驱动能力不足造成的。

为了进一步验证上述问题,利用两块ARM开发板上4个CAN通道(NXP公司的TJA1040收发器)进行测试,测试结果发现3个CAN通道可正常通信,但是4节点出现通信异常,异常现象和5节点通信时的问题相同。

由此分析可知,不同收发器的驱动能力会有一些差异,但是这并不是造成此现象的原因。而对CAN总线物理层结构特性进一步了解,总线需要在终端连接两个120欧电阻,但是通过对所有测试点的电路检测可知,每个节点收发器的CAN_H与CAN_L之间均连接了1个120欧电阻,而CAN通信时仅需在总线终端各加1个电阻即可。

将总线中多余的120欧电阻去掉,而只保留两个节点的电阻,通过测试发现,此时的4节点、5节点通信均正常。

那为什么只在物理上最远的两个节点加这个匹配电阻,而不是在所有的节点都加上匹配电阻?

高频信号传输时,信号波长相对传输线较短,信号在传输线终端会形成反射波,干扰原信号,所以需要在传输线末端加终端电阻,使信号到达传输线末端后不反射。对于低频信号则不用。

CAN总线两端必须连接终端电阻才可以正常工作,终端电阻应该与通讯电缆的阻抗相同,典型值为120欧姆。终端电阻的作用,一方面就是吸收信号反射及回波,而产生信号反射的最大来源便是阻抗不连续以及不匹配。另一方面,如果是加在单独的两根线上,相当于一个开环的状态,根据产生信号反射的来源,也就是说这种连接方式会导致单线上阻抗更加不连续,在末端突然变为0,会导致反射成倍增加。高速CAN所加的两个120欧的电阻实际上模拟的是线束连接无穷远的时候在传输线上产生的特性阻抗(而不是实际阻抗),这是个典型经验值,具体值取决于所采用的线束类型。CAN低速之所以不加终端电阻,是因为不同的频率时,同样的连接方式所产生的信号反射和回波差异很大,频率越高,反射和回波就会越强烈。另外不同的频率下,传输线的特性阻抗是不同的。第三方面,当一个显性位发送到至少包含一个CAN驱动处于开启状态的网络上时,意味着有电流经过终端电阻,因此,CAN_H和CAN_L具有了不同的电压值。也就是说,在显性状态时,终端电阻会稳定并增强差分电压,当去掉一个或两个终端,通过示波器可以明显看到一是信号不稳,二是差分电压会有变化,缺少终端或没有终端电阻时所测到的电压是单纯由CAN驱动器所产生的,离发送端越远,电压差异越大。

原文地址:https://www.cnblogs.com/HanCui/p/Han.html

时间: 2024-10-29 00:19:54

CAN总线多节点通信异常分析及解决的相关文章

java.lang.ArrayIndexOutOfBoundsException 异常分析及解决

参考:http://blog.csdn.net/javaeeteacher/article/details/4485834 这是一个非常常见的异常,从名字上看是数组下标越界错误,解决方法就是查看为什么下标越界. 下面是一个错误示例: Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 2 at test4.State.nextStates(State.java:93) at test4.State.m

java.lang.ArrayIndexOutOfBoundsException异常分析及解决

参考:http://blog.csdn.net/javaeeteacher/article/details/4485834 http://bbs.csdn.net/topics/90298133 这是一个非常常见的异常,从名字上看是数组下标越界错误,解决方法就是查看为什么下标越界. 下面是一个错误示例: Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 2 at test4.State.nextSt

jar包中File 文件找不到的异常分析与解决

源链接: http://hxraid.iteye.com/blog/483115#comments 我们常常在代码中读取一些资源文件(比如图片,音乐,文本等等).在单独运行的时候这些简单的处理当然不会有问题.但是,如果我们把代码打成一个jar包以后,即使将资源文件一并打包,这些东西也找不出来了.看看下面的代码: Java代码 //源代码1: package edu.hxraid; import java.io.*; public class Resource { public  void get

SPARK如何使用AKKA实现进程、节点通信

SPARK如何使用AKKA实现进程.节点通信 <深入理解Spark:核心思想与源码分析>一书前言的内容请看链接<深入理解SPARK:核心思想与源码分析>一书正式出版上市 <深入理解Spark:核心思想与源码分析>一书第一章的内容请看链接<第1章 环境准备> <深入理解Spark:核心思想与源码分析>一书第二章的内容请看链接<第2章 SPARK设计理念与基本架构> <深入理解Spark:核心思想与源码分析>一书第三章第一部分

CSR8670脱机运行后串口通信异常

1. UART通信异常 1.1. 现象 周五在调试CSR8670时遇到一个严重的问题:在xIDE环境下调试时,CSR8670收到MCU发来的数据后都会正常应答.一旦脱机运行,CSR8670与MCU的通信发生异常,具体现象如下: MCU发送一条x字节的命令给CSR8670,UART task收到的命令的长度不足x字节,最先发送的若干字节丢失 MCU以较短间隔发送多条x字节的命令给CSR8670,UART task收到的第一条命令的长度不足x字节,之后每条命令的长度都是x字节 1.2. 检查硬件 我

QQ 通信原理分析(转)

之前写过一个简单的IM,当时遇到过各种令人崩溃的问题:事后也没有做很好的总结,现在看到这篇文章,感慨良多,特此转摘过来,以做备忘. 出处:http://blog.csdn.net/lxnkobe/article/details/7521331 下面有4个基本的问答: 问题一:为什么只要可以连上互联网的计算机都可以用QQ相互建立通信,而不需要固定IP?也就是这个QQ用户端是怎样找到另一个QQ用户的,而用户在每次使用时他可能用的是不同的计算机,有着不同的IP地址.服务器端不会以qq用户端的ip作为唯

java.net.SocketException:Software caused connection abort: recv failed 异常分析 +socket客户端&amp;服务端代码

java.net.SocketException:Software caused connection abort: recv failed 异常分析 分类: 很多的技术 2012-01-04 12:54 8004人阅读 评论(6) 收藏 举报 socket服务器bufferstring网络java 第 1个异常是java.net.BindException:Address already in use: JVM_Bind.该异常发生在服务器端进行new ServerSocket(port)(p

MySQL 外键异常分析

外键约束异常现象 如下测例中,没有违反引用约束的插入失败. create database `a-b`; use `a-b`; SET FOREIGN_KEY_CHECKS=0; create table t1(c1 int primary key, c2 int) engine=innodb; create table t2(c1 int primary key, c2 int) engine=innodb; alter table t2 add foreign key(c2) referen

SylixOS 之epoll异常分析

1. SylixOS epoll介绍 SylixOS为了兼容Linux的epoll,创建了epoll的兼容子系统,并支持了epoll的部分功能.SylixOS epoll兼容子系统是由select子系统模拟出来的,所以效率没有select高. 2. epoll异常分析 2.1epoll异常场景 在使用线程A创建AF_UNIX匿名套接字发送数据:线程B把套接字加入epoll监听,且设置属性为一次有效:线程C等待epoll事件产生,并读取套接字中的数据.如程序清单 2-1所示.