三、CAN调试

根据项目的需求，现在需要外接毫米波雷达到TDA4板子上，毫米波雷达为CAN接口，所以要进行TDA4板子上Can接口的调试，下面根据调试的步骤来进行说明

一、软件回环测试

在实验之前先简单说明一下，在Linux上can接口是以socket的形式来操作的，也称socket can，应用程序只需要把要发送的can数据打包成can帧的数据包，然后使用socket来发送或者接收，应用程序是非常简单的。

can数据主要是以can frame的形式传输的，数据结构定义为

struct can_frame {
	canid_t can_id;			                                        //标识符,也叫做can_id
    	__u8 can_dlc;			                                                //数据的长度
	__u8 data[8] __attribute__((aligned(8)));		//数据
};

canid_t定义为32bit的无符号整形，它各个位的作用如下所示

    Bit0 ~ B28		        帧ID,如果帧为标准帧，帧ID有效为bit 0~bit10，如果为扩展帧，帧ID有效为Bit0~Bit28
	Bit29				错误帧标识位，值为0时为数据帧，值为1时为错误帧
	Bit30				远程帧标识位，值为1时为远程帧
	Bit31				帧格式标识位，值为0时为标准帧，值为1时为扩展帧

更多的内容可以在百度上进行搜索，相关内容非常的多，也可以参考CAN的说明和操作这篇文章，讲的也是很通俗易懂

要进行软件回环测试之前，要对can进行一些配置
设置速率

ip link set can0 type can bitrate 125000

回环，也可以在代码中直接配置

ip link set can1 type can bitrate 50000 loopback on

查询

ip -details link show can1

启动

ifconfig can0 up
或者
ip link set can0 up

发送can数据

      形式为      canid#can数据
cansend can1 0x260#0011223344556677

可以直接用candump来查看can数据，我这里是有一个应用程序，就直接使用应用程序来进行实验了
在后台运行的程序

使用cansend命令发送数据，其中canid为260，注意这是0x260,因为在代码中设置了过滤，所以使用它接收的canid
后台程序捕获到的can数据

二、硬件回环测试

软件回环测试是单纯的协议层面的测试，can数据不会走到真实的can接口上，现在做硬件回环测试，就要把两个can接口使用杜邦线连接起来，让数据进行回环测试，注意：连接的时候CAN-h接CAN-h,CAN-l接CAN-l

TDA4平台默认使能了4路can，并且这4路can的引脚也外接到板子上了，本次实验使用can1和can2进行实验
阅读相关资料，把can1和can2对应的pin脚用杜邦线连接起来

操作

开启两个can接口
ip link set can1 type can bitrate 125000
ip link set can1 up

ip link set can2 type can bitrate 125000
ip link set can2 up

can1在后台读数据
candump can1 &

使用can2发数据
cansend can2 120#11223344

然后，问题就出现了（哈哈，意料之中，不会这么顺利）

说明：这个问题我再网上查了一下，也有一个朋友遇到了这个问题，基本上是硬件出问题，因为我使用的是开发板，所以硬件不会有问题，如果大家使用自家公司生成的板子，可能就要去查一下硬件有没有问题

2.1原理图及设备树

硬件没有问题的话就从软件开始排查，先看一下原理图，对情况有个了解

使用的是1046这个can收发器，一个收发器上面接了2路can，每一路can都有一个很重要的引脚，STB引脚，这个引脚决定着can能不能正常工作，当can正常工作时,STB引脚为低电平，当STB引脚为高电平的时候，CAN总线闲置，关于更多STB的内容可以自行百度。

接下来去看设备树，看一下引脚定义，使用有没有冲突
以main_mcan0为例，在k3-j721e-eaik.dts中

在设备树中是有定义每个can使用的stb引脚的，而且经过检查引脚的定义是正确的，也并没有使用冲突，这个是和原理图做了验证的，那么就根据compatible寻找收发器对应的驱动是怎么样的

2.2驱动

在Linux内核drivers目录下grep “ti,tcan1042”，发现没有结果，所以，上面的can总线异常是因为没有驱动操作stb引脚，没有把它拉低是能can总线，导致的问题。
后来原因也找到了，我们目录使用的SDK是7.3版本的，在这个版本的SDK中是没有tcan1042这个收发器的驱动的，8.0版本的SDK中是有这个驱动的，于是切换版本到8.0的内核下，
重新编译内核和设备树，使用生成的文件启动，这个时候can总线是正常的，板子上引出来的4路can是可以做物理回环测试的。

为了验证我们的想法，在8.0版本的SDK下，正常使能CAN总线之后，查看系统的gpio情况

可以看到，在使能can总线之后，他们的stb引脚都是输出低电平的，再执行ip link set catX down之后，查看gpio，这些stb引脚又输出高电平了，这里就不在展示了。

2.3修改

通过对比两个版本的SDK代码，发现导致问题发生一共有两个原因
1、在我们目前使用的sdk 7.3的版本中没有can收发器的驱动，这就直接导致can的那些引脚没有在正常工作的时候去操作，所以can肯定是通不了的
2、移植了can收发器的代码到7.3版本上发现can还是不能正常工作，继续深究下去发现，虽然有个can的驱动，但是在通过网络操作Phy的时候，7.3版本的代码中没有去给phy使能，而phy的使能函数最终会调用到can收发器驱动中，才去操作stb引脚让can正常工作起来。

具体的修改方法这里就不展开说明了，对比两个版本的代码就行修改就行了

2.4测试

改完之后进行测试，板子上一共引出来了4路can接口，随便使用其中两路进行can的回环测试，使用杜邦线连接两个can接口，CAN-h接CAN-h，CAN-l接CAN-l

然后配置can接口，注意这次使用的不是软件的回环了，所以在配置的时候不要配置loopback

ip link set can0 type can bitrate 1000000 dbitrate 4000000 fd on
 ip link set can0 up

can up之后查看系统引脚，确实是输出低电平了，然后进行can的收发，回环功能正常

三、总结

通过这个问题进行思考，引出我们在平常工作中遇到其他问题的解决思路

1、首先，当我们调一个外设的时候，还是要进来熟悉这个外设的原理或者是特性，比如can的stb引脚就直接决定can总线能不能正常工作
2、寻找一些快速定位问题的方法，比如直接在串口上查看gpio cat /sys/kernel/debug/gpio，很方便直接的查看某个gpio是不是按照正常的工作
3、快速的定位到了问题，那接下来就是解决问题，这一步应该不会很难

这是我个人的总结，有不对的欢迎提出问题。