Vector-AUTOSAR使用中的问题总结

配置工具：DaVinci（达芬奇）

一、如何导入DBC和CDD文件

1、导入DBC文件

2、导入CDD文件

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

​

二、诊断服务28 03 03静止网络管理报文发送配置

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 宏的配置方法：

这样就可以将 CANNM_COM_CONTROL_ENABLED 宏打开（STD_ON），然后可以直接调用 

CanNm _DisableCommunication/ CanNm _EnableCommunication 接口了。

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

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

三、连续发送2帧报文才跳转到Appl_GenericPrecopy（）接口。

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

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

四、模块上电后，先发送诊断报文，模块没有响应。

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

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

五、模块上电，接收到 15 帧快速唤醒网络管理报文（10ms发送一次快速帧）时，模块首帧发出比较慢。

问题描述：模块上电，模块发出的第一帧（模块的网络管理报文周期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，这个是什么情况？见下图描述：

配置如下，解决该问题：

七、模块上电，网络管理报文只发出 2 帧，同时休眠时间比较快（AUTOSAR规范：被动节点，网络管理报文发送 3 帧；总线上没有报文后，模块到预休眠4S,从预休眠到休眠4S，共8秒休眠）

问题描述：​模块上电发送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进行检测的配置

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

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

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

配置1

配置2

​配置3

九、总线高负载情况下，会导致AutoSAR的CAN接口函数报错，导致看门狗作用，软件处于不断的复位过程中。

问题描述：在总线高负载下，调试后发现会进入到如下接口，文件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 快慢恢复问题

问题描述：

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

测试方法：

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

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

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

调试方法：

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

BusOff回调函数配置

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

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

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

十一、通信停止后就不会进休眠接口（EcuM_McuSetMode）的配置

方法：

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

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

十二、 debug发现模块不管是出现BUS OFF 休眠还是正常休眠，都会跳到EcuM_McuSetMode(Mcu_ModeType  McuMode)接口中，并且 McuMode总是为1（怀疑是配置工具中配死了），需要确认一下McuMode的值是否可配，如何配。

​

十三、DID配置

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

十四、DTC配置

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

十五、接收信号超时处理