嵌入式开发：如何识别PowerOn唤醒和总线唤醒

Question

如题所述

Answer 1

嵌入式开发揭秘：PowerOn与总线唤醒的识别艺术

在嵌入式世界中，对MCU唤醒机制的深入理解至关重要。近日，一位开发者在群组中提出了一个富有挑战性的问题：如何在使用TJA 1043 CAN收发器时，精确区分是PowerOn唤醒还是由总线扰动唤醒的MCU。要解答这个问题，我们需要从硬件和软件两个维度进行分析。

硬件层面的线索

首先，我们需要掌握产品的硬件设计细节。在主芯片（uC）中，通常会设置特定的Pin，如Trcv INH和KL15状态监测点，它们就像是电路中的路标，指示着唤醒的源头。例如，当SBC（系统基本芯片）被启用时，可能通过ENA Pin或WAK Pin，分别对应PowerOn或总线唤醒。具体来说：

当KL15硬线拉高，表明MCU是由PowerOn触发，这时通过监测KL15 Pin的电平，我们就能识别出是PowerOn唤醒。
相反，如果总线有扰动或特定报文，如网络管理报文，会触发Trcv进入Standby Mode，INH Pin随之拉高，使能SBC，进一步唤醒MCU。此时，通过监测INH Pin的状态，我们可以判断是总线唤醒。

有人可能会问：“如果PowerOn唤醒，INH也会拉高，如何区分？”其实，PowerOn只会使MCU唤醒，而是否是总线唤醒还需软件来判断。INH Pin的状态变化取决于软件对Trcv状态的控制，因此，深入理解软件处理至关重要。

软件层面的解析

软件是解开这个谜团的关键。在TJA1043的状态机中，INH Pin在某些模式下会保持浮动。总线扰动时，Trcv会从Sleep Mode转到Standby Mode，此时INH Pin会被拉高。在初始化过程中，软件会检测INH Pin状态，如果INH拉高，表明是总线唤醒；如果仅KL15 Pin拉高，则为PowerOn唤醒。此外，软件还需注意区分Trcv状态的直接切换，如从Sleep Mode到Normal Mode，这可能源于软件行为而非总线唤醒。

工程实践的考量

在实际工程设计中，有的方案可能仅使用KL15唤醒MCU，然后等待网络管理报文触发通信。这样的设计是否合理，需要权衡供应商和客户需求，以及软件架构如Autosar的规定。例如，如果使用CP Autosar，PowerOn唤醒默认会激活网络通信。但这也可能导致第一帧报文发送时间的延长，开发时需对此进行优化。

关注我们的“开心果 Need Car”公众号，继续探索更多嵌入式开发中的技术挑战和解决方案！

往期精彩回顾

浏览我们以往的文章，深入了解嵌入式开发的更多细节：

Autosar入门系列
电源管理与上电/下电控制
Fast DDS安装与调试技巧
车载以太网技术解析
RCU学习笔记

嵌入式开发的每个环节都充满挑战，一起探索，提升技术实力！