配置工具：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 这项配置，具体以调试结果为准。
九、总线高负载情况下，会导致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。
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文件），导入之后，打开配置工具，如下：