AUTOSAR_SWS_CANTransceiverDriver 阅读

一、简介

该规范描述了CAN收发器驱动程序模块的功能，API和配置。 CAN收发器驱动程序模块负责处理ECU上的CAN收发器硬件芯片。

CAN收发器是一种硬件设备，可将CAN总线上使用的信号电平调整为微控制器识别的逻辑（数字）信号电平。此外，收发器还能够

检测电气故障，例如布线问题，接地偏移或长主导信号的传输。 根据与微控制器的接口，它们会标记检测到的错误，该错误由单个端口引脚汇总，或者由SPI非常详细。

一些收发器支持电源控制并通过CAN总线唤醒。 不同的唤醒/睡眠和电源概念在市场上很普遍。
在汽车环境中，主要使用三种不同的CAN总线物理方法。 它们是用于高速CAN（最高1Mbits / s）的ISO11898，用于低速CAN（最高125Kbits / s）的ISO11519和用于单线CAN的SAE J2411。
最新发展包括系统基础芯片（SBC），其中除了CAN之外还实现了电源控制和高级看门狗。 它们被封闭在一个壳体中并且通过单个接口（例如，通过SPI）进行控制。

介绍操作模式跳转状态图，几种模式POWER_ON, NOT_ACTIVE, ACTIVE, SLEEP,NORMAL, STANBY mode ，根据收发器的不同可以多几个模式状态。

通过CanTrcv_SetOpMode(CANTRCV_TRCVMODE_NORMAL) 调用切换模式。

 

 

1.1 三种唤醒类型：

1.1.1

MCU未上电。
包括CAN收发器硬件在内的ECU部件均已通电。
所考虑的CAN收发器处于休眠模式。
CAN收发器硬件检测到CAN总线上的唤醒事件。
CAN收发器硬件导致MCU上电。
就AUTOSAR而言，这是冷启动，而不是唤醒。

1.1.2

MCU处于低功耗模式。
ECU的部分（包括CAN收发器硬件）已通电。
所考虑的CAN收发器处于STANDBY模式。
CAN收发器硬件检测到CAN总线上的唤醒事件。
CAN收发器硬件导致SW中断唤醒。

就AUTOSAR而言，这是作为CAN通道和MCU的唤醒而保持的。

1.1.3

MCU处于全功率模式。
至少包括ECU收发器硬件在内的ECU部件已通电。

所考虑的CAN收发器处于待机模式。
CAN收发器硬件检测到CAN上的唤醒事件。
CAN收发器硬件或者导致SW中断唤醒，或者被周期性地轮询唤醒事件。

就AUTOSAR而言，这被保留为CAN通道的唤醒

1.2启用/禁用唤醒通知

CanTrcv驱动程序应使用ICU驱动程序提供的以下API来启用和禁用唤醒事件通知：
-Icu_EnableNotification
-Icu_DisableNotification

CanTrcv驱动程序应确保以下几点以避免丢失唤醒事件：

当收发器转换到待机模式时，它将启用ICU通道

当收发器转换到正常模式时，它将禁用ICU通道

 

CAN收发器驱动程序提供两种唤醒模式：

在NOT_SUPPORTED模式下，CAN收发器驱动程序不产生任何唤醒。 所有CAN收发器硬件类型均支持此模式。

在轮询模式下，CAN收发器驱动程序产生的唤醒可能会导致CAN通道唤醒。 在这种模式下，无法唤醒MCU。

该模式假定使用的CAN收发器硬件类型支持。 唤醒模式POLLING需要源代码中包含函数CanTrcv_CheckWakeup和主函数CanTrcv_MainFunction。

主要功能CanTrcv_MainFunction将由BSW调度程序调用，而CanTrcv_CheckWakeup将由CanIf调用。

 

唤醒模式的选择由配置参数CanTrcvWakeUpSupport完成。 可以通过配置参数CanTrcvWakeup-ByBusUsed为每个CAN收发器单独打开和关闭唤醒支持。

注意：在两种模式下，均应存在功能CanTrcv_CheckWakeup，但该功能应基于配置的唤醒模式（NOT_SUPPORTED或POLLING）。
实施提示：
如果在检测到唤醒后CAN收发器需要由软件启动的特定状态转换（例如，睡眠->正常），则可以在执行CanTrcv_CheckWakeup期间由CanTrcv模块完成。 此行为是特定于实现的。
必须通过模块的配置来保证，当收发器需要特定的状态转换时，涉及唤醒过程（EcuM，CanIf，ICU等）的模块将调用CanTrcv_CheckWakeup。

1.3驱动程序初始化的前提条件

CanTrcv模块的环境应确保在调用CanTrcv_Init之前，所有必需的BSW驱动程序（由CanTrcv模块使用）已初始化且可用。 ⌋（SRS_BSW_00172）
CAN总线收发器驱动程序使用Spi和Dio驱动程序来控制CAN总线收发器硬件。 因此，在初始化CAN总线收发器驱动程序之前，这些驱动程序必须可用并且可以运行。
CAN收发器驱动程序可能对初始化序列和对收发器设备的访问有时序要求，这些使用的底层驱动程序必须满足这些要求。

1）CAN总线收发器驱动程序初始化的调用必须在加电后非常早地执行，以便能够为ECU中的所有其他用户及时从收发器硬件中读取所有必要的信息。

2） 所使用的基础服务的运行时间非常短且同步，以使驱动程序能够使其自身的时序要求受到所使用的硬件设备的限制。

3）由于某些硬件设备将端口引脚级别配置，因此驱动程序的运行时间可能会延长。 在再次将其更改为特定状态（例如睡眠）之前需要50μs。

 

1.4实例概念

等待状态

为了更改操作模式，CAN收发器硬件可能必须执行等待状态。
[SWS_CanTrcv_00230] CANCAN收发器驱动程序应使用时间服务Tm_BusyWait1us16bit来实现收发器状态更改的等待时间。

 

1.5具有选择性唤醒功能的收发器

例如TJA1131 

本节介绍了具有选择性唤醒功能的CAN收发器的要求。
部分联网是CAN系统中的一种状态，其中某些节点处于低功耗模式，而其他节点正在通信。 这减少了整个网络的功耗。 低功耗模式下的节点被预定义的唤醒帧唤醒。
除了普通收发器提供的唤醒模式唤醒（WUP）之外，还可以通过唤醒帧/帧（WUF）唤醒支持选择性唤醒的收发器。

如果收发器硬件支持选择性唤醒，则应使用配置参数CanTrcvHwPnSupport进行指示

用于选择性唤醒功能（CanTrcvPartialNetwork）和以下API的配置容器：
-8.4.7 CanTrcv_GetTrcvSystemData，
-8.4.8 CanTrcv_ClearTrcvWufFlag，
-8.4.9 CanTrcv_ReadTrcvTimeoutFlag，
-8.4.10 CanTrcv_ClearTrcvTimeoutFlag和
-8.4.11 CanTrcv_ReadTrcvSilenceFlag
仅在CanTrcvHwPnSupport = TRUE时存在

如果支持选择性唤醒，则必须将CAN收发器配置为使用参数CanTrcvPnFrameCanId，CanTrcvPnFrameCanIdMask和CanTrcvPnFrameDataMask在特定的CAN帧或一组CAN帧上唤醒。

如果收发器具有识别总线故障的能力（并区分总线故障和其他硬件故障），则应使用配置参数CanTrcvBusErrFlag指示该收发器以用于总线诊断目的

对于支持选择性唤醒功能的CAN收发器，在正常模式（CANTRCV_TRCVMODE_NORMAL）期间可以检测唤醒帧。 收发器WUF标志用信号通知检测到的唤醒帧。 这样可确保在过渡到待机模式期间不会丢失唤醒帧
（CANTRCV_TRCVMODE_STANDBY

 

二、函数定义

2.1 CanTrcv_Init

void CanTrcv_Init( const CanTrcv_ConfigType* ConfigPtr )

初始化CanTrcv模块。

CanTrcv_Init函数将根据所有连接的CAN收发器的初始化顺序和配置（由参数ConfigPtr提供）对它们进行初始化。 同时，它还应支持AUTOSAR堆栈的配置顺序

CanTrcv_Init函数应将CAN收发器硬件设置为由配置参数CanTrcvInitState配置的状态。

请注意，在加电和调用CanTrcv_Init之间的时间间隔内，CAN收发器硬件可能处于不同的状态。 这取决于硬件和SPAL驱动程序配置。
复位（例如加电）后的初始化顺序是CAN收发器驱动器的关键阶段。
此API应在初始化期间存储唤醒事件（如果有）。

如果得到硬件支持，CanTrcv_Init将验证是否由于收发器活动而唤醒，如果为TRUE，则应通过API EcuM_SetWakeupEvent向EcuM进行报告，并在CanTrcvWakeupSourceRef中引用唤醒源

如果启用了选择性唤醒并由硬件支持，则必须通过CanTrcv_Init API检查收发器状态的POR和SYSERR标志。

 

如果设置了SYSERR标志，则应通过API EcuM_SetWakeupEvent将唤醒报告给EcuM，该唤醒源的值根据CanTrcvSyserrWakeupSourceRef引用的符号名称值在位位置的位置为“ 1”，其他位置为“ 0”。

如果与收发器的通信不存在/通信不正确，则CanTrcv_Init函数应将运行时错误代码CANTRCV_E_NO_TRCV_CONTROL报告给默认错误跟踪器，并返回E_NOT_OK。
例如，存在不同的收发器类型和不同的访问方式（端口连接，SPI）。 如果您发现与硬件的任何通讯错误，则应发出此开发错误的信号。 根据连接类型和收发器硬件的不同，您可能无法在必须用信号通知错误的情况下运行。

为了实现AUTOSAR局部网络机制，CAN收发器必须支持唤醒帧的数据掩码的定义（CanTrcvPnFrameDataMask的配置结构是强制性的）

2.2 CanTrcv_SetOpMode

Std_ReturnType CanTrcv_SetOpMode( uint8 Transceiver, CanTrcv_TrcvModeType OpMode )

将收发器的模式设置为值OpMode

如果收发器处于CANTRCV_TRCVMODE_NORMAL模式，则CanTrcv模块的用户应调用OpMode = CANTRCV_TRCVMODE_STANDBY或CANTRCV_TRCVMODE_NORMAL的函数CanTrcv_SetOpMode。

如果收发器处于CANTRCV_TRCVMODE_STANDBY模式，则CanTrcv模块的用户应调用OpMode = CANTRCV_TRCVMODE_SLEEP或CANTRCV_TRCVMODE_STANDBY的函数CanTrcv_SetOpMode。

此API适用于每个收发器，其参数CanTrcv_SetOpMode的每个值均与收发器硬件是否支持这些模式无关。 这是为了简化CanIf到分配的总线的视图。

如果底层收发器硬件不支持请求的模式，则函数CanTrcv_SetOpMode将返回E_NOT_OK

如果硬件支持选择性唤醒：收发器状态的标志POR和SYSERR将由CanTrcv_SetOpMode API检查。

如果设置了POR标志，则收发器应重新初始化以运行收发器的配置序列

如果未设置SYSERR标志且请求的模式为CANTRCV_NORMAL，则收发器应为相应的抽象CanIf Trans-ceiverId调用API CanIf_ConfirmPnAvailability（）。

CanIf_ConfirmPnAvailability通知CanNm（通过CanIf和CanSm）启用了选择性唤醒。

如果与收发器的通信不正确/不正确，则函数CanTrcv_SetOpMode将向默认错误跟踪器报告运行时错误代码CANTRCV_E_NO_TRCV_CONTROL并返回E_NOT_OK。 

如果为模块CanTrcv启用了开发错误检测：
如果使用OpMode = CANTRCV_TRCVMODE_STANDBY调用函数CanTrcv_SetOpMode，并且收发器不在CANTRCV_TRCVMODE_NORMAL或CANTRCV_TRCVMODE_STANDBY模式下，则CanTrcv_SetOpMode函数将产生开发错误E_NOT_OK

如果为模块CanTrcv启用了开发错误检测：
如果以OpMode = CANTRCV_TRCVMODE_SLEEP调用函数CanTrcv_SetOpMode，并且收发器不在CANTRCV_TRCVMODE_STANDBY或CANTRCV_TRCVMODE_SLEEP模式下，则CanTrcv_SetOpMode函数将引发开发错误E_NOT_OK

.

如果为模块CanTrcv启用了开发错误检测：
如果在CanTrcv模块初始化之前调用，函数CanTrcv_SetOpMode将向其他方向引发开发错误CANTRCV_E_UNINIT（如果禁用了DET），返回E_NOT_OK

如果启用了模块CanTrcv的开发错误检测：如果使用无效的收发器编号调用，则函数CanTrcv_SetOpMode将引发开发错误CANTRCV_E_INVALID_TRANSCEIVER，否则（如果禁用了DET）则返回E_NOT_OK。

如果启用了针对模块CanTrcv的开发错误检测：如果使用无效的OpMode调用，则函数CanTrcv_SetOpMode将引发开发错误CANTRCV_E_PARAM_TRCV_OPMODE，否则（如果禁用了DET）则返回E_NOT_OK。

2.3 CanTrcv_GetOpMode

获取收发器的模式并以OpMode返回

2.4CanTrcv_GetBusWuReason

获取收发器的唤醒原因，并在参数Reason中返回它

功能CanTrcv_GetBusWuReason将在参数Reason中收集CAN收发器检测到的唤醒原因。 ⌋（）
检测和区分可能的唤醒原因的能力在很大程度上取决于CAN收发器硬件。
请注意，如果有多个总线可用，则每条总线可能会报告不同的唤醒原因。 例如。 如果ECU具有CAN，则可能会发生CAN唤醒，并且传入的数据可能会引起另一CAN总线的内部唤醒。
CAN收发器驱动程序具有“每条总线”视图，并且在内部不投票更重要的原因或顺序。 如果例如 一个收发器控制电源，另一个收发器仅通电或不通电。
在配置阶段静态设置了受支持的总线数

 

如果与收发器的通信不正确/不正确，则函数CanTrcv_GetBusWuReason必须将运行时错误代码CANTRCV_E_NO_TRCV_CONTROL报告给默认错误跟踪器，并返回E_OK。

2.5CanTrcv_ SetWakeupMode

根据TrcvWakeupMode启用，禁用或清除收发器的唤醒事件。

启用：如果使用TrcvWakupMode = CANTRCV_ WUMODE_ENABLE调用功能CanTrcv_SetWakeupMode，并且如果CanTrcv模块具有针对所寻址总线的暂挂存储唤醒事件，

则CanTrcv模块应将其唤醒事件更新为“ present”。 ⌋

禁用：如果使用TrcvWakeupMode = CANTRCV_ WUMODE_DISABLE调用功能CanTrcv_SetWakeupMode，则在所寻址的收发器上禁用唤醒事件。

收发器设备和收发器驱动程序需要检测唤醒事件并将其存储在内部，以便在再次启用唤醒模式时引发唤醒事件。

清除：如果使用TrcvWakeupMode = CANTRCV_ WUMODE_CLEAR调用功能CanTrcv_SetWakeupMode，则在寻址的收发器上清除存储的唤醒事件

当禁用唤醒通知时，必须使用唤醒事件清除功能，以清除所有在高层控制下存储的唤醒事件。

2.6 CanTrcv_GetTrcvSystemData

读取收发器配置/状态数据，并通过参数TrcvSysData返回。 仅当CanTrcvHwPnSupport = TRUE时，此API才存在。

功能CanTrcv_GetTrcvSystemData将读取CAN收发器的配置/状态，并将读取的数据存储在外部参数TrcvSysData中。 如果成功，则应返回E_OK。

 

2.7 CanTrcv_ClearTrcvWufFlag

清除收发器硬件中的WUF标志。 仅当CanTrcvHwPnSupport = TRUE时，此API才存在。

CanTrcv_ClearTrcvWufFlag函数应清除CAN收发器中的唤醒标志。 如果成功，则应返回E_OK。
实施提示：
CanSM模块将使用此API来确保在进入低功耗模式期间不会丢失任何帧唤醒事件。 该API清除WUF标志。
清除WUF标志后，应将CAN收发器置于待机模式（CANTRCV_STANDBY）。
如果在启用选择性唤醒功能时发生系统错误（SYSERR，例如配置错误），则收发器将禁用该功能。 收发器将在下一个CAN唤醒模式（WUP）下唤醒。
如果发生其他任何硬件错误（例如帧检测错误），如果收发器内部的错误计数器溢出，则收发器将唤醒

 

CanTrcv应通过回调通知CanIf_ClearTrcvWufFlagIndication来通知CanIf已为请求的收发器清除了唤醒标志，该回调通知引用了具有抽象CanIf TransceiverId的相应CAN收发器

2.8 CanTrcv_ReadTrcvTimeoutFlag

从收发器硬件读取超时标志的状态。 仅当CanTrcvHwPnSupport = TRUE时，此API才存在。

 

2.8 CanTrcv_ClearTrcvTimeoutFlag

 

2.9 CanTrcv_ReadTrcvSilenceFlag

从收发器硬件读取静音标志的状态。 仅当CanTrcvHwPnSupport = TRUE时，此API才存在。

 

3.10 CanTrcv_CheckWakeup

如果检测到唤醒中断，基础CANIF将调用服务

3.11 CanTrcv_SetPNActivationState

API将收发器的唤醒配置为待机和睡眠模式：通过远程唤醒模式（标准CAN唤醒）或配置的远程唤醒帧唤醒CAN收发器

3.12 CanTrcv_CheckWakeFlag

请求从收发器硬件检查唤醒标志的状态

CanTrcv应通过回调通知CanIf_CheckTrcvWakeFlagIndication通知CanIf已检查具有相应TransceiverId的CAN收发器的唤醒标志。

3.13 CanTrcv_DeInit

取消初始化CanTrcv模块。

 

功能CanTrcv_DeInit必须将CAN收发器硬件设置为NOT_ACTIVE状态。⌋（SRS_Can_01108）
在状态NOT_ACTIVE中，CAN收发器硬件允许以新的配置顺序进行重新配置

 

3.14 CanTrcv_MainFunction

 

CanTrcv_MainFunction必须扫描STANDBY和SLEEP中的所有总线以了解唤醒事件。
该功能应设置唤醒事件标志以执行这些事件

 

3.15 CanTrcv_MainFunctionDiagnostics

定期读取收发器的诊断状态，并相应地设置产品/开发。

 

循环功能CanTrcv_MainFunctionDiagnostics应定期读取收发器状态，并相应地报告生产/开发错误。

仅当CanTrcvBusErrFlag = TRUE时，循环函数CanTrcv_MainFunctionDiagnostics才存在。

 

由于CanTrcv是驱动程序模块，因此它不为底层模块提供任何回调函数。

 

3.2 强制性接口

CanIf_TrcvModeIndication

该服务指示收发器状态转换，该状态参考具有抽象CanIf TransceiverId的对应的CAN收发器

Det_ReportRuntimeError

报告运行时错误的服务。 如果已经配置了标注，则应调用该标注