CanTrcv_30_Sbc收发器驱动详解：SBC模式控制与总线唤醒机制

CanTrcv_30_Sbc是面向 SBC 集成式 CAN 收发器的 AUTOSAR CAN Transceiver Driver 实现。它把上层模块看到的接口稳定在 CanTrcv 语义上，而把实际硬件访问交给 SBC Driver 完成。这样一来，CanIf、CanSM、EcuM 不需要关心收发器位于独立芯片、SBC 外设还是某个受 SBC 同步保护的内部组件，只需要按 CanTrcv API 管理工作模式、唤醒检测和局部网络能力。本文围绕三个集成主线展开：NORMAL与STANDBY的模式控制，总线唤醒的上报路径，以及 SBC 访问、ICU 唤醒和跨分区调用带来的约束。

模块定位

CanTrcv_30_Sbc位于 CAN Interface 与 SBC Driver 之间。它不是直接通过 SPI 或 DIO 操作收发器，而是调用 SBC Driver 提供的收发器访问服务，由 SBC Driver 负责底层硬件访问与同步。

这个定位决定了模块的关键边界：CanTrcv 负责 AUTOSAR CanTrcv 行为，SBC Driver 负责硬件访问，ICU 在特定唤醒方案中负责输入捕获，EcuM 负责系统唤醒事件的生命周期。

初始化与模式控制

上电或复位后，先调用CanTrcv_30_Sbc_InitMemory()初始化模块内部变量，再调用CanTrcv_30_Sbc_Init()初始化配置的收发器通道。Init()完成后，每个已配置通道被切到NORMAL。如果初始化前已经存在未上报的唤醒事件，模块会保存该事件，并在初始化路径中通过EcuM_SetWakeupEvent()通知 EcuM。

CanTrcv_30_Sbc_SetOpMode()只支持NORMAL与STANDBY，不支持SLEEP。如果请求的模式与当前模式一致，函数返回E_OK，但不会触发实际硬件切换。模式切换完成且函数返回E_OK时，模块在SetOpMode()的调用上下文中调用CanIf_30_Sbc_TrcvModeIndication()。

GetOpMode()有一个容易被忽略的边界：如果上层刚发起模式切换，而模式变化还没有完成，在模式指示回调发生前读取到的模式可能仍不是最终模式。上层状态机应以模式指示和后续读取共同确认状态，而不是把一次立即读取当成唯一依据。

总线唤醒路径

总线唤醒围绕CheckWakeup()、GetBusWuReason()、SetWakeupMode()、CheckWakeFlag()和MainFunction()组织。典型路径是：硬件检测到总线活动，CanTrcv 检查收发器状态与唤醒标志，随后通过 EcuM 上报唤醒源。

CheckWakeup()的返回值不能单独作为系统唤醒成立的判据。对于 ECU 唤醒状态机而言，有效动作是对应唤醒源被EcuM_SetWakeupEvent()上报。返回E_OK表示检测请求在当前条件下识别到总线唤醒，但系统层仍应以 EcuM 唤醒事件为准。

如果在DISABLE到ENABLE的间隙发生唤醒，SetWakeupMode(ENABLE)不会主动补发该事件。集成时需要在重新开启后调用GetBusWuReason()，确认关闭上报期间是否已经发生过唤醒。

ICU 唤醒配置

当 CAN Controller 本身不支持 “wakeup by CAN bus”，但 ECU 又需要因为 CAN 总线活动醒来或开始通信时，可以使用 MCU 额外 I/O 输入配合 ICU。该输入通常并联到 CAN Rx，或者连接到收发器的 ERR 引脚，具体取决于收发器硬件。

通知函数通常只做一件事：把硬件输入边沿转给 EcuM。

void Icu_TrcvWakeUpNotification_0(void)
{
  EcuM_CheckWakeup(ECUM_WKSOURCE_CAN0);
}

如果系统不需要对该唤醒源进行验证，也可以在通知函数中调用EcuM_SetWakeupEvent()。两种写法的差别在于：前者触发 EcuM 的唤醒验证路径，后者直接声明唤醒事件成立。

SBC 依赖与跨分区调用

CanTrcv_30_Sbc的硬件访问依赖 SBC Driver。SBC Driver 暴露的服务名和 CanTrcv 可使用的回调名之间存在固定映射；当CANTRCV_30_SBC_CALLBACK_FUNCTIONS == STD_ON时，应用侧需要实现这些回调，以便跨 OS Application 或安全分区时通过受控入口访问 SBC 功能。

跨分区设计的核心问题不是函数名，而是执行上下文：CanTrcv API 可能由任务或中断触发，SBC Driver 又可能要求特定 OS Application 或安全上下文。把访问汇聚到CanTrcv_30_Sbc_Hw_*回调后，可以在应用层统一放置 trusted function、non-trusted function 或直接调用策略。

数据一致性与 Exclusive Area

模式切换、唤醒检查和硬件状态读取都会访问同一组 SBC 收发器服务。模块使用CANTRCV_EXCLUSIVE_AREA_0保护这些调用，避免上层服务在关键硬件访问期间相互打断。

集成时应避免这些 API 相互抢占。尤其是SetOpMode()、CheckWakeup()和MainFunction()，它们都可能触发 SBC 访问和上层回调；如果系统中断锁粒度不清晰，容易造成上层状态机读到短暂不一致的收发器状态。

API 矩阵

下面按用途归类CanTrcv 提供的服务。所有服务都要求模块已初始化，除非服务本身就是InitMemory()或Init()。

SetPNActivationState()的约束比普通模式 API 更强。PN_ENABLED表示硬件配置为只被配置帧唤醒，也就是 WUF；PN_DISABLED表示硬件配置为任何总线活动都能唤醒，也就是 WUP。要让 selective wakeup 生效，生成配置中也必须启用对应能力。

服务 ID 与错误码

当CANTRCV_30_SBC_DEV_ERROR_DETECT == STD_ON时，模块通过 DET 报告开发错误。错误报告使用模块 ID、实例 ID、服务 ID 和错误码定位调用问题。

返回值的含义要结合 API 使用。例如GetBusWuReason()返回E_NOT_OK可能只是没有有效唤醒原因，而SetOpMode()返回E_NOT_OK则意味着请求的状态变化没有被接受。

配置、文件与内存映射

模块交付文件分为静态文件和生成文件。静态文件提供 API 与实现，生成文件携带配置、类型和外部数据声明。

版本也可以通过头文件中的宏读取：

AUTOSAR 符合性与偏差

CanTrcv_30_Sbc保留 AUTOSAR CanTrcv 的主要接口语义，但由于收发器硬件挂在 SBC 上，部分能力和回调命名存在实现差异。

CanIf_CheckTrcvWakeFlagIndication()的行为尤其重要：即使没有检测到唤醒，驱动也会调用该通知。否则 CanSM 在发起 wake flag 检查后可能一直等待完成通知。如果确实检测到唤醒，则另行通过EcuM_SetWakeupEvent()上报唤醒源。

集成关注点

对这个模块而言，最容易出问题的不是 API 名称，而是上下文关系：初始化先后顺序、CanTrcv 与 SBC 的分区边界、ICU 唤醒输入的电气连接、以及 EcuM 唤醒源是否与通道配置一致。只要这几处边界明确，CanTrcv_30_Sbc可以把 SBC 内部收发器稳定地接入 AUTOSAR CAN 通信栈。