Vector-AUTOSAR使用中的问题总结

Posted 2023-03-04

参考技术A

配置工具：DaVinci（达芬奇）

DaVinci DaVinci

1、导入DBC文件

导入DBC文件——1 导入DBC文件——1 导入DBC文件——2 导入DBC文件——2

2、导入CDD文件

导入CDD文件——1 导入CDD文件——1 导入CDD文件——2 导入CDD文件——2

3、只要更改了DBC或CDD文件，都需要 Update

更新方式 更新方式 正在更新 正在更新

1、一般情况下直接调用  CanNm _DisableCommunication （CanNm 模块 ） 接口就一定可以关掉 NM 报文发送。

问：调用 CanNm _DisableCommunication 接口的话，是不是模块也接收不到总线上的网络管理报文了，自己也不能发送 NMF 了？

答：vecotor解释，“好像能接收，只是不发送”。（具体现象还需要debug调试）。

2、调用  CanNm _EnableCommunication （CanNm 模块） 接口是打开 NM 报文发送。

注意： 如果  CANNM_COM_CONTROL_ENABLED 宏没有打开，即 STD_OFF， 则直接在应用程序中调用  CanNm_DisableCommunication 接口，程序会报错：提示 function has no prototype ，即使包含  CanNm.h 头文件也没用。

打开  CANNM_COM_CONTROL_ENABLED  宏的配置方法：

配置1 配置1 配置2 配置2

这样就可以将  CANNM_COM_CONTROL_ENABLED  宏打开（ STD_ON ），然后可以直接调用  CanNm _DisableCommunication / CanNm _EnableCommunication 接口了。

以上是手动禁止 NMF 发送的方法，其实打开了   CANNM_COM_CONTROL_ENABLED  宏之后， 也可以用配置工具配置，更简单实现禁止 NMF 发送，如下：

通过配置关闭 NMF 发送 通过配置关闭 NMF 发送

注意： 特别是Nm Communication这个，必须勾选上。

问题描述： 产品上电，通过工具模拟总线报文发送，发送一帧报文（例如 0x621 ）， Appl_GenericPrecopy（） 接口没有接收到，发送第二帧的时候，ID报文跳才会转到 Appl_GenericPrecopy（） 接口。 Appl_GenericPrecopy（） 接口不是接收所有的ID报文吗？为什么刚开始上电连续发送2帧报文才会跳转到 Appl_GenericPrecopy（） 接口？

答：vector解释，“   第一帧作为唤醒帧的话，只是唤醒ECU，第二帧才能被接收到。 在实车环境下这种情况是比较常见的，如果ECU速度比较慢的话可能需要更多帧才能被接收到”。

问题描述：   模块上电的时候， 发送一帧诊断报文（例如：10 03），模块没有任何响应（肯定或否定） ，直到模块的 应用报文 和 网络管理报文 发出来后，再发诊断报文，模块是可以响应的，这个是不是在配置工具中配置了？

答： Vector： 这个是可以配置或者可以在回调函数里面做的， 一般泛亚都是要求只有网络管理报文才能唤醒ECU，诊断报文是唤不醒的 。所以会出现你说的这种情况。

问题描述： 模块上电，模块发出的第一帧（模块的网络管理报文周期640ms，应用报文周期1s）与接收到的第一帧网络管理报文时间相差的800多ms，第一帧发送出来比较慢，请问这个是什么引起的，AUTOSAR的模块调用比较慢吗？

答：Vector：模块调用的话都是你们自己的系统调度的，首先看看是否调度有延迟之类的。其次可以看看从上电到调用 CanNm_TriggerTransmission 需要多长时间，这个函数是发送 NM 报文的。

接着可以做以下测试：1、从上电到调用  Can_Write  的时间。2、在 CanHL_StartTransition  中会调用 CanIf_ControllerModeIndication ，从上电到调 CanIf_ControllerModeIndication  的时间。

根据泛亚要求首帧发出的时间100-200ms之间：

泛亚首帧发送时间要求 泛亚首帧发送时间要求

解决方法： 我感觉和 AUTOSAR 任务调度的顺序及次数等有关系，因为之前没有买 OS 模块，软件写了一个简单的操作系统，并且按照 RTE.C 文件中定义的 AUTOSAR的任务时间进行顺序执行。

将 CanSM_MainFunction() 和 CanNm_MainFunction() 放在 1ms 任务中，在该任务中便于调试控制时间调用CanNm_MainFunction()函数，通过在该任务内累加计时80ms后，调用CanNm_MainFunction()。

示例代码 示例代码

问题描述：  当读诊断长帧的时候，发送 30 之后，后面长帧的数据会显示出来，但是数据后面会自动填充一个 01，这个是什么情况？见下图描述：

图示问题描述 图示问题描述

配置如下，解决该问题：

配置1 配置1 配置2 配置2

问题描述： 模块上电发送2帧网络管理报文以及总线上没有报文后，模块到预休眠4S,从预休眠到休眠4S，共8秒休眠，和这些参数有关吗？

答：有些关系的，Repeat Message Time越长发的NM报文越多。 这些参数就配置了这个8秒的时间，就是两个4秒的配置。

按照 vector 说法，没有解决问题，故修改配置如下： Repeat Message Time: 1500-->2000；Timeout Time:4000-->8000；Wait Bus Sleep Time: 4000-->8000，以供参考。

修改配置 修改配置

问题描述： 模块对诊断报文不需要做DLC长度检查，即要求：当模块收到诊断报文时，即使诊断报文的实际数据长度<8，模块也应该接收此报文并按照诊断要求进行响应。

答：Vector： Rx Pdu Dlc 改成 0 当然不行了，还是要改回 8 ，其实只需要把 Rx Pdu Dlc Check 的勾去掉就行了。 Dlc Check 一般都可以不用改。

注意： 还有一个配置比较重要，见 配置3 ，之前打电话咨询过 vector ，应该是配置3 这项配置，具体以调试结果为准。

配置1 配置1 配置2 配置2 配置3 配置3

问题描述： 在总线高负载下，调试后发现会进入到如下接口，文件 Det.c ，其中 ModuleId = 0x3C，ErrorId = 0x46； 这里会进入 While 循环，超时后 WatchDog 导致产品 Reset 。

问题截图 问题截图

进一步分析，文件 CAN.c ；发现 CAN 控制器 Reset 后一直处于 kFlexCAN_DISABLE_MODE ，无法恢复正常通信；即使收到正确的网络管理报文也无法恢复。

原因分析： While 循环是导致  ECU Reset  的直接原因，根本原因在于高负载应用报文条件下，上电/ Reset 后 CAN 控制器初始化异常， FlexCAN 没有进入 Normal 模式，导致不断的进入 DET_reportError 中的死循环。

1、系统启动，在进行网络管理报文发送，调用  CANIF_TRANSMIT  的接口时控制器处于 STOP 状态，从而导致系统进入 DET 。

2、在新版本的代码中由于 DEM 接口的调用在 DEM 模块初始化之前，导致系统进入 DET 。

解决方法：

最简单的方法（但不是根本的方法） ：把while死循环去掉，或者把Det检测去掉，高负载的情况下确实应该增加过滤，DET模块仅在开发阶段使用，在最终产品中，一般都会把DET模块去掉。

vector提出的方法： 1、将CAN的过滤器和FULLCAN进行配置和使用。2、在具体的 Mainfunction 调度中，将 CANSM_Mainfunction 调度放至 CANNM_Mainfunction 之前调用，并且在初次启动的时候将 CANNM_Mainfunction 的调用做延迟处理，防止高负载的情况下 CAN 控制器处于 STOP 状态使系统进入 DET 。3、将对应的模块的初始化函数调用放至DEM接口使用之前，在初始化完成之后再进行接口的调用。

配置工程，有几个地方的配置可以优化一下：

由于该问题跟 CAN 总线负载相关，可以使用硬件过滤来降低 CPU 开销，由于该配置中报文不多，推荐使用 FULLCAN 的过滤配置：

每个模块的 DET 选项可以去掉，见下图，如果还在查问题，可以暂时打开：

CAN 模块的 Overrun Notification 可以设置为 None 或者 Application ：

问题描述： 当模块出现了 busoff ，通过示波器测量 MCU 的 TX 脚，发现没有进行快恢复和慢恢复的动作。

测试方法：

最简单的测试方法： 通过将 CAN_H 和 CAN_L 短接在一起产生busoff, 通过示波器测量MCU的TX脚，查看是否有快恢复慢恢复的动作。

有效测试方法： 使用 CANstress 工具，干扰模块发送的报文，测量模块快慢恢复时间。

打开已有的 cst 文件或打开工具新建 cst 文件：

配置1  配置1  配置2  配置2  配置3 配置3

调试方法：

vector ：发生 bus-off 上层要收到 bus-off 通知才会执行相应的操作。在 bus-off 上层回调打个断点看代码能否执行到。上层代码有相应的回调函数的配置见截图，回调函数的： Appl_CanSM_BusOffBegin ， Appl_CanSM_BusOffEnd 。

BusOff回调函数配置 BusOff回调函数配置

DEBUG调试： 产生  busoff   会进入 Appl_CanSM_BusOffBegin ， busoff 结束后会进入 Appl_CanSM_BusOffEnd  接口中。

vector ： CanSM_MainFunction 是处理 Bus-off 恢复的，那两个接口函数只是通知 app 的。根据项目填充所需要的内容。

目前解决方法： 我怀疑和没有购买 OS 有关系，调换了AUTOSAR 10ms任务的执行顺序；

方法： 应用层没有请求 Run 模式，所以通信停止以后系统就休眠，只有在应用层请求 Run 模式就可以。但在应用层请求 Run 模式需要有 Rte 和 Davinci Developer 工具的配合，如果没有的话只能通过修改代码。把 Request_ESH_RunRequest_0_requestedMode 这个变量或者类似名字的变量在系统启动后置成 1 ，要休眠时置成 0 ，这样通信停止后就不会进休眠了。由于这个变量是个静态变量，外部修改需要更改 BswM 模块生成的代码。

调试结果： 模块初始化的时候将 Request_ESH_RunRequest_0_requestedMode 设置为 1 ，然后停止发送报文，让通信停止，模块没有进入休眠，电流也正常，没有进入休眠。

数据ID（ID）需要在 cdd 文件中添加，配置完成 DID 后，需要导入配置工具（见 一、如何导入DBC和CDD文件 ），导入之后，打开配置工具，如下：

DTC 需要在 cdd 文件中添加，配置完成  DTC  后，需要导入配置工具（见 一、如何导入DBC和CDD文件 ），导入之后，打开配置工具，如下：