梦想技术家

Core0 main 之前MCU干了什么？}BMD_HDR;通过链接文件指定到如下四个位置中的任意一个即可。BMI的指定结构如下具体代码如下} > BMI链接文件指定入口函数，mcu 启动的地址有很多方式，这里介绍链接文件指定启动位置。使用ENTRY 指定一个symbol程序中要执行的第一条指令称为入口点。您可以使用ENTRY链接器脚本命令来设置入口点。参数是一个符号名:有几种方法可以设置入口点。

实现工程的时候，有时候传递参数需要用户自己定义的数据类型，例如枚举、结构体之类的，方便于阅读的同时，增加代码的可维护性，文档记录一下如何增加一个枚举的数据类型。

SWC的全称为SoftWare Component 软件组件，怎么新建一个SWC呢，其实在ETAS工具里面是比较常见的一个问题，记录一下如何新建一个SWC。Inter-ECU示例框图。

NvM模块负责管理和从非易失性内存中读写数据。在系统启动和关闭阶段，同步应用程序RAM区的数据。此模块还提供其他服务，例如用于上层数据保护的冗余数据单元。同时，RTE提供了简单灵活和接口（NvData Interface）用于非易失内存的数据处理。AUTOSAR4.2.2配置指导如下：从AUTOSAR的描述可以看出总共牵涉三个模块，NvMBlockDescriptor、NvMCommon与NvmDemEventParameterRefs。配置思维导图如下。

看一个C语言的宏用法注意一下：LIST_ID_JOB(LIST_ENTRY_ID_JOB) 中NvM_Prv_idJob_ LIST_ENTRY_ID_JOB _e是不存在的，但是NvM_Prv_idJob_Read_e是存在的中LIST_ID_JOB(LIST_ENTRY_ID_JOB)只是表示枚举里面有Count的元素，注意一下NvM_Prv_idJob_Count_e声明在LIST_ID_JOB(LIST_ENTRY_ID_JOB)中。

几个概念如下描述，下图只是便于理解。

可变和持久是ECU内部数据的属性。实际上，在ECU运行时需要更改数据，并在整个电源周期中保持数据可用。这些数据需要存储在非易失性存储器中。非易失性存储器中的数据称为NV数据。NVRAM块是管理和存储NV数据块所需的整个结构。下图显示了AUTOSAR中的内存堆栈:从上图可以看出，存储栈的分层结构，FEE的含义是Flash模拟EEPROM，理论上实现虚拟理论上不限次数的擦写。在实际项目里面FEE一般用芯片自带的DFLASH，例如英飞凌、NXP的芯片。

DET:Default Error Tracer 默认错误追踪器.对代码进行上下文追踪的一种方式，例如：初始化失败、空指针等。DET模块是一个在软件开发阶段，支持其他BSW模块，来实现错误检测和错误追踪的支持模块，其接收来自其他模块的错误信息，然后由开发者自行定义对于这些错误信息的处理方式，可以存储在buffer里，或者通过通信接口发送给外部的调试工具，或者通知Dem模块记录故障码。在产品开发成熟后，进入量产阶段，此功能需要被关闭。所有在基本软件中检测到的开发和运行时错误都会报告给该模块。

Dem全称为Diagnostic Event Manager，负责故障事件的处理、故障数据的存储和管理。简单说其功能是故障事件确认前的故障debounce，故障事件确认时的故障数据存储，故障发生后的故障老化、故障替代（AUTOSAR的故障存储策略）。AUTOSAR标准中对Dem模块最上层分了两菜单栏，分别是DemConfigSet，DemGeneral。其中DemConfigSet负责不同DTC、event等的配置，DemGeneral负责DTC、event的共用部分，包括冻结帧、扩展帧、使能条件等。

诊断事件”定义了Dem模块可以处理的原子单元。“诊断事件”的状态表示监视器的结果。Dem通过RTE或其他BSW模块接收来自SW-C的监视器结果。Dem模块使用Eventld来管理系统的“诊断事件”的状态，并对单个测试结果执行所需的操作，例如存储冻结帧。Dem模块用Eventld和相关的EventName表示每个诊断事件。所有监视器和BSW模块都使用Eventld作为符号EventName。Dem配置工具将符号名称替换为数字。

标准故障码的表示字符所属系统000SO/SAE标准定义的故障码011制造商自定义的故障码102ISO/SAE预留113ISO/SAE预留。

ISOLAR-AB的配置大体上是符合AUTOSAR配置的，但是部分配置参数携带Rb字样，这样的个人认为均属于ETAS自己添加的配置，规范上确实也可以自己添加一定的配置来实现功能。话不多说字节进入主题----ISOLAR总体配置图如下：ISOLAR总体配置的思维导图如下：打散来逐步分析进行之前先引入时间参数的概念。

请求处理·将PduR模块的请求转发到DSD子模块。·并发的“testpresent”(“keep alive logic”)。响应处理·将DSD子模块的响应转发给PduR模块。·保证测试人员的响应时间。·支持周期传输。·支持ResponseOnEvent (ROE)传输。·支持分段响应。·支持由应用程序触发的ResponsePending响应。安全级别处理·管理安全级别。会话状态处理·管理会话状态。·跟踪活动的非默认会话。·允许修改时间。诊断协议处理·处理不同的诊断方案。·管理资源。

DCM：Diagnostic Communication Manager 诊断通信管理。Dcm模块负责诊断数据流的保障和诊断状态的管理，特别是诊断会话和安全状态的管理。此外，Dcm模块根据诊断状态检查是否支持诊断服务请求，以及是否可以在当前会话中执行该服务。Dcm模块为诊断服务提供通用API。Dcm模块的功能在开发、制造或服务期间由外部诊断工具使用。

文档记录一下在实现XCP的过程中，通过ETAS的ISOLAR-AB工具如何实现基本的XCP配置。，此处有个店，ETAS的XCP配置，更多的偏向于自己设定的配置，与规范出入点较多，但是整体没偏离AUTOSAR规范。在规范里面需要实现的XCP配置主要包含两个方面XcpConfig与XcpGeneral都是唯一存在的。在ISOLAR-AB工具里面包含了三个部分，多了一个A2L的配置，如下图，文档不在记录A2L的配置，记录AUTOSAR要求的两部分。配置的思维导图如下。

记录一下XCP使用时候的功能包含命令时序、错误码表、事件描述以及对规范的记录。XCP的图示如下从上图就可以看出数据流的流向CAN-CANIF-XCP，发送反之。XCP的状态机如下。

学习XCP的过程中，对XCP的基本概念要做一个全面的认知，因为里面有很多缩写以及难以理解的点，假设对此模模糊糊一知半解，那么对整个协议栈的认知会遇到极大的障碍。XCP的信号流传输图示如下XCP 标准主要分为 5 个部分：这部分提供了对于协议的一个概况介绍，包括 XCP 的功能和基础性内容。这部分内容对协议层进行了详细的规范和说明。

A2L文件是基于ASAP2标准制定的用来描述ECU内存的数据库文件，保存了标定系统与ECU通信的配置参数和ECU内部数据单元的详细信息。A2L文件组成1、A2L头文件：项目配置信息等，一般不随软件编译变化。2、标定变量描述：地址信息可能经常变化。3、观测变量描述：地址信息可能经常变化。4、辅助信息：例如转换公式，一般不随软件编译变化。ASAM汽车电子产品的MCD标准在3层系统中结构如下。

COM通信栈的ISOLAR-AB工具进行配置的介绍

在AUTOSAR架构里面COM位于RTE与PDUR之间，通俗点理解就是讲接收到的I-PDUs打包并提供给RTE，将RTE传下来的信号发给PDUR，经由PDUR路由出去。从应用层传下来数据首先就进入这里，应用层无需关心收发的数据是通过什么总线传输的，应用只需要将它传输给COM即可。

ISOLAR-AB工具配置及代码简单分析。根据各家配置工具以及规范总结 PDUR模块配置大的Container只有三个PduRBswModules可以有多个，此处包含了上层例如DCM\COM与下层模块CanTp\CanIf。

PDUR路由单元在整个AUTOSAR的位置如下图PDUR在整个通信里面的位置信息如下，从下面这张图可以看出PDUR能将I-PDU传递到不同的AUTOSAR组件。说白一点就是：PduR模块从CANIf模块/COM模块接收到了PDU ,然后根据PDU ID查找已定义好的静态路由表,获得其目标地址,定向并转发到COM模块/CANIf模块的操作。解释名词: 交互层协议数据单元，I-PDU由数据(缓冲区)、长度和I-PDU ID组成。pdu路由器主要是路由I-PDUs。

此配置依赖ETAS的配置工具ISOLAR-AB实现，各个容器符合AUTOSAR规范的同时匹配ISOLAR-AB工具。ISOLAR-AB总的配置如下思维导图规范里面显示与是唯一的。

CanTp位于CanIf与PDUR之间，主要目的是对大于8字节的CAN I-PDU，大于64字节的CANFD I-PDU进行分段与重组。对单帧、多帧的接收发送，从规范里面给出来了很详细的解读，每一个步骤需要干什么，需要执行什么功能函数，返回的E_OK状态有什么指示等都有明确的步骤。

CanTp位于CanIf与PDUR之间，主要目的是对大于8字节的CAN I-PDU，大于64字节的CANFD I-PDU进行分段与重组。

TP位于硬件抽象层的上层，在AUTOSAR的结构里面位置如下CanTp的协议着重需要查阅的ISO规范文档如下《ISO 15765[1].2（2004）道路车辆——控制局域网络诊断——第2部分：网络层服务.pdf》目前笔者使用的TP来讲CanTp与J1939TP居多一些，CanTp：ISO诊断(DCM)，标准CAN总线上的大型PDU传输，J1939Tp: J1939诊断，大型PDU传输J1939驱动的CAN总线。CanTp位于CanIf与PDUR之间，主要目的。

参考规范，少部分自己的总结。时序图怎么去看，请查看文章UML时序图浅析。

在CANIF_TX_OFFLINE_ACTIVE模式下，上层必须处理传输确认的执行。对于每个被分配到CANIF_TX_OFFLINE_ACTIVE模式信道的L-PDU, CanIf会立即调用上层模块的传输确认回调服务，而不是在调用CanIf_Transmit()时将L-PDU缓冲或转发到CanDrv。如果调用CanIf_SetControllerMode()或CanIf_ControllerBusOff()，则CanIf应将相应通道的PDU通道模式设置为CANIF_TX_OFFLINE。

根据AUTOSAR BSW架构，接收到的数据将在上层通信模块，即AUTOSAR COM、CanNm、CanTp和M中进行评估和处理。这意味着，上层模块既不能使用CanDrv的缓冲区，也不能访问CanIf的缓冲区。只有当CanIfPublicReRxPduDataApi设置为TRUE时，CanIf才会在接收路径中提供内部缓冲。解决了发送缓冲问题，并考虑动态I-PDU。如果接收到CanDrv L-PDU，则调用CanIf的CanIf_RxIndication ()。

规范基于《AUTOSAR_SWS_CANInterface.pdf》，配置工具基于ETAS的ISOLAR-AB规范里面的描述。

CanIf的发送请求函数CanIf_Transmit()是上层模块传输L-PDU的通用接口。上层通信层模块需要通过CanIf的服务启动传输，无法直接访问CanDrv。如果CanDrv能够将L-PDU数据写入CAN硬件传输对象中，则发起的传输请求成功完成。上层模块使用API服务CanIf_Transmit ()来发起一个传输请求。 CanIf在调用服务CanIf_Transmit()时对L-PDU传输执行以下操作:如果传输请求服务CanIf_Transmit()返回E_OK，则传输成功完成。

下面主要是规范方面的描述：参考文档《》接口模块（下文简“CanIf”）位于底层CAN驱动（CanDrv）、CAN（CanTrcv）和上层服务层（CanSm、CanNm）、CAN传输协议（CanTp）、PDU路由器（PduR）之间。它表示上层通信层的CAN驱动程序服务接口。CanIf提供了独特的接口来管理不同CAN，如CAN控制器和CAN收发器。同时，基于物理CAN通道相关的CAN状态管理器模块（CanSm）可以控制多个底层内部和外部的CAN控制器或CAN收发器。

有些信息是零碎抽象的，记录一下自己的理解以及在网上看到对自己有启发的句子。

由于项目里面没有使用到休眠唤醒这类操作，所以配置较为简单，基于项目的配置，仅作为参考。

ECU管理器模块（ECU Manager）是管理ECU状态的基础软件模块。具体来说，ECU管理器模块负责：·初始化和去初始化OS、SchM和BswM以及一些基础软件驱动模块。·将ECU配置为SLEEP和SHUTDOWN状态。·管理ECU上的所有唤醒事件（wakeup events）。ECU管理器模块提供唤醒验证协议（），以区分真实（real）和不稳定（erratic）唤醒事件。此外，ECUM还负责：·提供部分或快速启动（）机制。

EcuM的主要作用是初始化BSW的各个模块；协调芯片MCAL相关模块的初始化；开启OS；进行初运行、睡眠、唤醒等模式的状态切换；执行ECU的关机和复位；检验唤醒事件等。在EcuM中要定义系统的下电方式、唤醒源、多核上下电模式处理等。Flex EcuM下大多数ECU状态不再在EcuM模块本身中实现。通常EcuM模块接管控制早期STARTUP阶段和后期SHUTDOWN阶段。在EcuM的启动阶段后BswM负责进一步的操作,EcuM模块仲裁来自SWCs的Run和PostRun请求。

ComM的全程是Communication Manager 管理通信，是BSW里面的一个组件，位于AUTOSAR的系统服务层，组件位置如下图。作为一个资源管理者，ComM封装了下层的通信服务，ComM控制通信相关的BSW模块，但不会去控制SWC或Runnable，ComM与USER用户直接交互（USER：可以是直接下发指令给ComM的模块，也可以是BSWM、SWC、Runables），ComM对下而言主要通过xxxSM、Nm来实现通信控制，实现SM与NM的协同。

CAN总线的Bus Off是指当CAN节点发送错误次数超过规定的限制时，该节点将被自动禁用。在这种情况下，节点将停止发送消息，并进入“Bus Off”状态，直到节点被重置或重新启动。这是一种保护机制，以避免错误消息在网络中传播并导致其他节点出现问题。在CAN总线进入busoff状态后，通常需要尝试重新连接总线。这可以通过在CAN控制器中执行一系列的错误恢复步骤来实现，例如等待一段时间以允许其他节点发送消息，然后逐渐增加发送消息的速率，直到成功连接总线为止。

ETAS实现CanSM的配置

CanSM子状态机与时序图