当前位置：首页 > news >正文

【MCAL实战】CanTrcv模块配置实践

news 2025/10/27 6:43:24

前言

正文

1.硬件分析

2.CanTrcv模块配置

2.1. CanTrcv的RX和Tx引脚配置

2.2. CanTrcvGeneral

2.3.CanTrcvChannel

2.4. CanTrcvDioChannelAccess

3.CanTrcv模块的使用

3.1. 关键API的功能及使用场景

3.2. 状态变量

4.上板测试

4.1. 总体功能测试

4.2. 观测软件状态

4.3. 关键API的使用场景

5.总结

前言

汽车电子嵌入式开始更新全新的AUTOSAR项目实战专栏内容，从0到1搭建一个AUTOSAR工程，内容会覆盖AUTOSAR通信协议栈、存储协议栈、诊断协议栈、MCAL、系统服务、标定、Bootloader、复杂驱动、功能安全等所有常见功能和模块，全网同步更新开发设计文档（后期也会更新视频内容）。本文为MCAL系列配置-CanTrcv模块配置实践。

CanTrcv正常工作是CAN通信正常工作的必要条件，在以下文章中我们详细介绍过各类收发器的细节内容，其中最主要的就CanTrcv用于休眠唤醒时的功能作用，CanTrcv相关的参考文章：

本文作为CanTrcv的基础入门介绍，仅介绍从0到1如何配置一个CanTrcv模块并测试其基本功能。

AUTOSAR BSW Tool：Vector

AUTOSAR MCAL Tool：EB

Hardware Platform: Infineon Tricore TC387

Build Tool: Tasking

Debug Tool: UDE

正文

1.硬件分析

如上图所示，TC387的开发板使用了英飞凌公司自己的收发器TLE9251VSJ（一般常用NXP公司的TJA1044, TJA1043, TJA1145这几个收发器），Pin脚和NXP的TJA1044收发器类似。

VIO和VCC是给芯片供电的，硬件设计上常供电，不需要用户额外控制供电（一般车载量产控制器收发器的供电是可以通过MCU控制的，应该是考虑的ECU的低功耗）。

STB引脚是高有效（原理图上的STB上如果有一个“—”就是低有效，没有“—”就是高有效），开发板直接STB接地（GND），也就是收发器永远是Normal模式（STB有效就是Standby模式），也就是收发器硬件设计上就永远处于正常工作状态。

TXD和RXD和MCU的TXD（Pin20.8）RXD（Pin20.7）直连，CANH和CANL和CAN总线直连。

2.CanTrcv模块配置

2.1. CanTrcv的RX和Tx引脚配置

在《【MCAL实战】Port及Dio模块配置实践》一文中我们详细介绍了CanTrcv的Rx和Tx引脚的Port和Dio模块配置。

2.2. CanTrcvGeneral

CanTrcvGeneral里面没有特殊需求的时候保持默认配置就行，这里着重介绍几个比较重要（实际项目中会用到）的配置项：

Dev Error Detect: 是否是能Det, 这个参数在项目开发阶段建议勾上，方便我们测试时发现一些低级问题（比如模块没有初始化.e.g.）。

User Config File: 可以配置一个xxx.h文件，工具生成代码的时候会将xxx.h文件中的内容copy到CanTrcv_Cfg.h的最后。通过这个参数可以重映射一些宏定义或者一定函数，在功能安全的函数跨OsApplication中会使用到。可以参考《【经验总结】硬件设计导致Cantrcv静态代码不匹配问题分析及解决方案》一文。

Wake Up Support: 配置CanTrcv模块是否支持唤醒源检测，这个需要根据实际需求配置。CAN的被动唤醒是一个涉及多模块的联动过程，需要一个专题将各个模块串起来讲解才能理解，这里仅将要介绍，深入的相关分析介绍可以参考以下几篇文章：《【CAN通信】AUTOSAR架构下CanTrcv休眠唤醒问题再探》

2.3.CanTrcvChannel

CanTrcvChannel里面没有特殊需求的时候保持默认配置就行，这里着重介绍几个比较重要的配置项：

Icu Channel Ref: CanTrcv模块中的这个参考一般不会用到。但是关于Icu的Ref参数很多模块都会有（CanTrcv, Lin, Can .e.g.）详细的ICU唤醒可以参考《【MCAL】AUTOSAR架构下ICU唤醒详解》一文。

Por Wakeup Source Ref和Syserr Wakeup Source Ref这两个参数在使用IO控制的CanTrcv模块不会用到（引脚也没有这两个唤醒源，TJA1043.e.g.），但是SPI控制的CanTrcv硬件（TJA1145.e.g.）有这两个硬件唤醒事件，需要根据实际需求配置。关于TJA1145的相关功能可以参考《【经验总结】TJA1145异常设置唤醒源导致ECU休眠失败问题分析》。

Wakeup By Bus Used: 配置CAN总线唤醒是否使能。一个CAN阶段的ECU一般都会有一路CAN支持CAN唤醒，根据实际需求配置。

Wakeup Source Ref: 如果这路CAN支持CAN唤醒，这个参数引用一个EcuM模块的唤醒源。CanTrcv检测到唤醒事件收会调用EcuM_SetWakeupEvent通知到EcuM模块，EcuM模块开始唤醒源校验。详细内容可由参考《【Mode Management】AUTOSAR 架构下EcuM唤醒源事件详解》一文。

2.4. CanTrcvDioChannelAccess

引用我们在DIO模块里面配置的CanTrcv的STB和Rx的Dio Channel就行。CanTrcv模块会使用Dio_ReadChannel和Dio_WriteChannel来读写Cantrcv的Rx/STB硬件。

注意：由1章节可知我们的硬件的STB引脚是引脚直接接地的，实际是无法通过软件控制的。但是为了适配Vector的CanTrcv配置，这里引用的CAN00_STB实际不是CanTrcv的STB引脚引脚。

3.CanTrcv模块的使用

实际项目中User不会直接调用CanTrcv模块的API函数来控制CanTrcv, 都是Can Stack的上层模块调用使用。站在CanTrcv单个模块来看，我们只要知道：

1.CanTrcv模块的关键API的主要功能以及谁在什么场景下会调用即可。

2.CanTrcv在系统启动，运行中，下电过程中应该处于什么逻辑状态即可（关键状态变量）。

3.1. 关键API的功能及使用场景

CanTrcv_Init: 需要用户mapping到EcuM的start sequence中去，在ECU的启动阶段由EcuM调用。

CanTrcv_MainFunction: 需要用户mapping到Os的10ms/其他Task中，Os的10ms任务运行起来后周期调用。

CanTrcv_SetOpMode: ComM的状态切换会trigger CanSM的状态切换，CanSM状态切换后会调用CanIf_SetCanTrcvMode->CanTrcv_SetOpMode来控制CanTrcv切换到Standby, Normal模式。

CanTrcv_CheckWakeup: CanTrcv切换到Standby或者Sleep模式后会调用EcuM_CheckWakeup --> CanIf_CheckWakeup --> CanTrcv_CheckWakeup来检测CAN Bus唤醒事件。具体可以参考《【CAN通信】CanTrcv和EcuM的关系及不同类型的Can收发器主要使用场景》一文。

3.2. 状态变量

Vector的TJA1040 SIP包代码提供了CanTrcv_30_Tja1040_Prob全局变量来观测CanTrcv的内部状态。

/* ! The following type includes CAN transceiver channel specific settings. */
typedef struct
{/* ---- Common attributes ---- *//* ! Last detected wakeup reason */CanTrcv_30_Tja1040_TrcvWakeupReasonType wakeUpReason;/* ! Specifies whether or not to report wakeups */CanTrcv_30_Tja1040_TrcvWakeupModeType wakeUpReport;/* ! HW specific attributes */} CanTrcv_30_Tja1040_Prob_Type;

奇怪的是CanTrcv_30_Tja1040_Prob_Type中并没有变量可以观测CanTrcv的逻辑状态。有问题的时候需要我们Debug代码去分析当前CanTrcv软件处于什么逻辑状态。