此文档适用于前毫米波雷达软件集成工程师岗位，其他人可借鉴

一、CAN/CANFD通信

1、雷达CAN未能正常发出数据

解决思路：
主要分为两个环境：工位和实车。
如果在工位上代码运行雷达中没有发出数据：
①排查代码设计中配置有没有问题，波特率和CANFD（CAN）由上而下是不是配置对了。另外应用层发送的代码有没有顺利执行，功能配置上CANID注册有没有冲突。

②雷达是不是正常启动了，物理连接有没有问题
如果在工位上无问题在车上无数据发出：
解决思路几乎和工位上一致，只不过在工位上是点对点直连，实车上CAN网络上可能有其他节点。
①物理连接线束有没有问题，供电和通信线路有没有虚接，反接
②CAN线上是不是有别的节点，直连雷达有没有问题。如果直连雷达没有问题，那可能是网关转发有问题，或者CAN网络的阻抗有问题，CANFD或CAN正常通信的CANH和CANL之间的阻抗为60Ω左右，当然只要不是太离谱一版不会影响通信。（量阻抗的方式是万用表在整车和雷达全部下电的情况下量CANH和CANL之间的阻值）。
③另外就是实车上的CAN网络的各个节点的波特率或采样点是不是配置不一样，需要确认，甚至可以通过CAN设备的指示灯判断。
总之实车上的通信主要受物理连接上的影响。

2、雷达在车上接收不到车身信息

如果在车上收不到报文信息，首先需要在断掉雷达的情况下，使用CAN设备以及ZCANPRO直连整车CAN线，查看有无数据。
如果无数据直接跟项目经理反馈那就有可能是客户车的问题。
如果有数据，那基本和上面排查思路一致，首先排查物理连接和阻抗，很多时候都是阻抗不对引起的。

3、程序下载失败

这里主要分析整车上程序不能更新的问题。
①、根据上位机的失败log，先分析到下载的哪一步失败的，如果是直接提示雷达不在线，那需要排查雷达是否正常上电，雷达当前运行的程序是否支持诊断刷写，如果当前程序都不支持诊断刷写的话，需要强制刷写，如果整车没有强刷条件的话需要将雷达从车上拆下来刷写。
②、如果是诊断是通的，但是提示预编程检查失败，需要跟诊断开发人员确认预编程都需要哪些条件，一般的可能是电压、车速报文等，然后再进行下一步分析，不行就强刷。
③、如果出现36服务错误或者接收流控帧失败，那需要查看雷达CAN线上是不是有其他节点也在发数，一般诊断刷写的CANID优先级比较低，是不是收到CAN线上其他报文影响了或者线虚接，除线虚接之外其他的需要跟BT开发人员确认怎么回事。
④、BT 和 driver的匹配

4、DV试验发送数据偶发断连

一般DV试验不会只接一台雷达，会接至少3台，出现这类问题，
①、当然也是先排除物理连接的影响。
②、另外就是阻抗，所有都断电的情况下用万用表量阻抗。
③、CAN驱动配置上是否打开了自动重发功能，DV试验需要打开CAN线的自动重发功能

5、发送感知信息丢帧或者丢报文

①、如果是每一帧数据里偶发丢某条报文的话。如果是协议栈做的发送，直接找协议栈同事排查。如果是集成人员做的发送，排查是不是CANID注册有问题。或者发的报文太多了，一个周期内发送不出去。或者CAN网络负载很高，优先级低的报文被总线仲裁掉了。
②、如果是整帧丢，或者帧里面有重复的目标，需要查看有没有数据并发使用的问题，要发送的数据区可能会被别的线程修改。整帧丢的话需要查看数据产生的线程和数据发送的线程在处理周期时间上有没有问题。比如数据产生的线程周期快，数据发送的线程周期慢，这样肯定会丢帧。如果是事件性报文，有没有可能发送的线程有阻塞，消耗的时间长，长到数据产生的线程已经更新了两次以上数据了，数据发送线程上一帧还没发完。这一块主要是线程间时间和空间上的处理时序问题。

6、上电发出第一帧的报文时间长

①、这一块首先需要跟硬件同事一起用示波器查下APP启动之前的时间是否过长。一般示波器会至少探测3个信号：POWER、CAN信号、QSPI数据引脚，这样很方便看出来雷达的启动过程，如果APP启动之前的耗时就非常长(比如说大于300ms，一般在200ms以内)，那不好优化，如果APP启动之前时间合理，那就是APP初始化的调整了。

上图为上电启动过程示波器截图，红色信号是flash数据，蓝色信号是看门狗CS片选，绿色信号是CAN报文，黄色信号是电源。
启动过程为：
1: 上电；
1-> 2 : 从上电至从flash读取boot及boot启动运行加载BT参数完成，1->2耗时为136ms。
1-> 3 ：从上电至boot从flash加载APP启动，1->3耗时为321ms。
1-> 4 ：从上电至APP从flash加载APP参数完成，1->4耗时为428ms。

②、初始化的调整一般有一个基础条件，发送CAN报文的线程越早初始化，报文发出的就越早，比如说协议栈，那就应该在各种外设中间组件初始化完成之后马上初始化协议栈，让其尽早跑起来，尽早发出第一帧报文，所以在这个前提下在保证功能正常的情况下调整初始化时序，一般调整的是初始化任务的优先级、初始化过程中的等待、操作flash耗时等，纯APP调整还是能调整出来的，尤其要比协议栈中NVM 的优先级要高。
③、但是如果遇到公CAN不发报文，私CAN发的事件性报文，那这个看能否跟客户提走偏差，毕竟射频启动时间较长，如果走不了偏差，那就只能APP启动后就来一个无效报文先发出去。

7、ZCANPRO有错误帧

检查物理连接虚接、阻抗、波特率配置等。

二、协议转换（以太网协议转换成CAN协议）

1、车速不正常

前提是在工位通过模拟报文已经测试通过。另外通信如果没问题，解析是不是根据实际的DBC协议解析的，大小端有没有搞错，位域有没有搞错、ID有没有搞错，录取报文离线分析实际的车速有没有问题。

2、车辆倒车无负速度

是不是没有根据DBC里的档位信号或者车辆行驶方向对车速取负，另外有个别协议车速信号直接是有符号的，这个需要注意。

3、车速更新不及时导致急加速急减速感知有问题

①车速适配线程运行的频次是不是很慢或者优先级很低，一般整车的车速报文周期为10ms，所以车身信息适配的时间最大不要超过10ms。
②另外车速给到感知的数据流是不是有问题，需要跟算法人员沟通车速的使用方法。

4、横摆角数值不对

DBC协议、角度？弧度？单位是不是搞错了，方向左正右负

5、横纵向加速度数值不对

DBC协议，单位，尤其是有些DBC里的单位是g/s²，不是我们常规的m/s²，需要*9.8 方向左正右负

6、方向盘转角数值不对

DBC协议、角度？弧度？单位是不是搞错了,方向左正右负

7、发出的目标属性与以太网对不上

协议反译问题，尤其是设计到位域、大小端问题，单位，如果是上位机的问题，要有充分的证据说明是上位机的问题。

8、发出的目标坐标系问题

当前一般发出的目标坐标系都是左正右负，坐标原点是车辆后轴中心，这里也涉及到跟上位机沟通显示的问题。

三、雷达启动

1、车上测试雷达无数据

雷达供电、CAN通信线路，甚至雷达是不是坏了，前提是程序在工位做过冒烟测试，不要出现不在工位进行冒烟测试就直接释放测试那边测试，内耗很大。

2、雷达电流不对，比平时正常工作时电流小很多在100ma~200ma左右，且可能伴随着不断重启

①、换一个确定没问题的APP测试是不是雷达坏了，如果连程序都强刷不进去的话，找硬件一起排查。
②、雷达没坏的话，APP是不是没有开启看门狗，程序是不是有bug，回滚排查，看是哪改出的问题。

3、电流几乎为0

物理连接没问题的话，找硬件人员协同排查，一般可能是休眠或者PMIC保护关机了，或者硬件坏了。

四、雷达标定

1、诊断指令不响应

①、APP是否正常开启了诊断？
②、如果其他诊断都响应，找协议栈人员咨询，标定例程是不是有什么条件限制
③、在车上的话，首先确认雷达是不是正常启动了，多种方式，比如说有没有应用报文，其他读服务是否响应。如果实在确认不了，只能拆雷达。如果能确认雷达上电了，需要协议栈人员介入一起排查，为什么不响应，集成这边也应该简单分析log，是在哪一条不响应的。

2、标定结果无目标

这个影响因素较多，标定环境、干扰、遮挡等都可能导致该问题，不过这是系统应该分析问题。
软件需要分析的主要有：
①、标靶距离是否根据需求设置了
②、有没有以太网数据供分析。
③、能配合系统端查问题，也有可能是幅相系数等问题导致的EOL没有筛选出来正常的点云。

3、标定误差过大

设计之初应该即使误差过大也要能例程执行完成，写入flash误差值（已标定标志不置位），这样可以通过诊断上位机读出的角度，分析是方位还是俯仰误差过大，这样才能引导客户去排查安装问题，不然没有举证。

4、带宽切换不成功

这里如果从软件分析主要是，带宽切换也涉及到通过SPI或者内部总线操作前端，所以带宽切换的时候不能有其他通过SPI或者内部总线操作前端，比如获取射频温度、开关射频，这一块要做到隔离，这个原因之外就是信号处理同事做的实际的带宽切换逻辑是不是有bug。

5、现场标定，但是无标定条件

①、尝试做售后标定
②、有没有自标定功能。
③、通报产品经理项目经理，看看如何做标定。

6、售后标定开启失败

售后标定31服务是不是有限制条件

五、雷达异常复位

1、雷达启动后不断复位

①、换一个确定没问题的APP测试是不是雷达坏了，如果连程序都强刷不进去的话，找硬件一起排查。
②、雷达没坏的话，APP是不是没有开启看门狗，程序是不是有bug，回滚排查，看是哪改出的问题。

2、雷达运行过程中复位

①、老生常谈，一般都是做复现，然后再去排查，当前一般都集中在算法那边导致的。
②、另外就是通过内部异常log日志，排查分析，所有项目都要添加上这个功能，有时候还是用的上的。

3、雷达二次复位后正常运行

初始化过程是不是添加了看门狗守护，是不是这里的问题，看看门狗时间是不是设计的短，或者确实是初始化哪里卡滞了。

六、雷达以太网发送

1、无数据发出

①、物理连接，电脑网卡配置，网口盒主从模式配置。
②、雷达硬件是否支持以太网
③、雷达APP是否正常启动

2、协议属性不对

排查协议挂接部分，写固定值排查。

3、发出的数据有耦合帧

线程间时间和空间上的是否存在时序耦合。

4、数据丢帧

①、数据处理是否超时
②、物理连接是否虚接
③、电脑是否卡顿，电脑重启试试

七、雷达仿真

1、debug launch失败

仿真器的USB线连接，换个仿真器试试

2、连不上雷达

①、转接板是不是有断裂
②、雷达硬件是不是没有去掉看门狗
③、雷达硬件是不是仿真状态（CCSDEBUG文件是不是未烧录，SOP状态是不是正确）

3、load不进去仿真文件

①、雷达硬件是不是仿真状态（CCSDEBUG文件是不是未烧录，SOP状态是不是正确）
②、重新关掉CCS，雷达断电上电再试试

4、断点打不上

①、load进去的仿真文件是不是不是要打断点的C文件编译出来的
②、打断点的地方是不是无效代码
③、打断点的C文件是不是开着优化，优化也可能会有这个问题

5、单步调试不按顺序执行

C文件是不是开着优化，开优化一定会有这个问题

八、诊断

1、通过诊断写参数写不进去（SN号、硬件版本号等）

①、咨询协议栈开发人员，是不是操作2E写服务有什么限制？
②、一般如果雷达存在相关的数据了，协议栈不会再让二次写了。

2、31例程服务开启不成功

咨询协议栈开发人员31服务的限制条件

3、实车上诊断不响应

①、APP是否正常开启了诊断？
②、在车上的话，首先确认雷达是不是正常启动了，多种方式，比如说有没有应用报文，其他读服务是否响应。如果实在确认不了，只能拆雷达。如果能确认雷达上电了，需要协议栈人员介入一起排查，为什么不响应，集成这边也应该简单分析log，是在哪一条不响应的。
③、一般这种情况就是排除雷达自身有没有问题，想尽一切办法能单独和雷达供电通信。

4、31服务的查询服务不响应

①、雷达是不是在31服务查询结果过程中重启了
②、31服务一般在开启后，应在一定时间内查询结果，超过一定时间后，31例程会自己退出。

5、非强制刷写预编程模式失败

咨询协议栈预编程条件都有啥，简单的可以自己排查，复杂的直接让项目经理安排协议栈人员排查

九、其他

1、ZCANPRO可以打开，但是刷写或者诊断上位机报打开设备失败

上位机目录下的DLL文件可能有问题，将能打开的上位机目录下的相关DLL文件拷到要使用的上位机目录下。

2、APP初始化启动慢

①、初始化是不是被其他已经起来的比它优先级高的任务抢占了？
②、初始化任务至少要比协议栈中NVM的优先级要高

3、从某一个线程处理出来的数据感觉不对，浮点数据

线程增加浮点保护

4、FreeRTOS某一个线程明明写上sleep（500），但是并没有释放CPU资源

在2944或者TPR12中，sleep的时间如果小于1000us的话，会死等

5、所有数据都正常但是上位机不显示目标信息

功能降级

十、物理连接损耗

1、稳压源明明供电12V，但是通过诊断读取电压为11V甚至更低

线束长了以后有线损

2、CAN 或者以太网数据有问题，有错误帧或者通信不良。

通信线路需要双绞