嵌入式开发：MCU的上、下电解读

工程中，休眠、唤醒的问题很多，整车的网络拓扑中，很多节点都有类似的问题。比如：复用SPI导致通信丢失、节点无法休眠、节点启动时间超过需求时间、节点偶发无法唤醒等等。这些工程问题，有人说是网络管理问题，有人说是通信问题，也有人说是电源管理问题...似乎，这类问题成了迷案，各个模块的工程师都不想过多掺和。我不能说上述观点错，确实，这种问题涉及电源管理、通信、网络管理等等，需要工程师对公司产品的电路原理、网络管理和通信（尤其驱动部分）等模块，有一定的认识才能很好地认识问题，并找到合适的解决方案。

本文，试着从电路原理入手，讨论一下MCU的上、下电。

1、MCU上电条件

关于uC（MCU）的唤醒条件，之前聊过，可以参考前文《​​嵌入式开发：如何理解ECU唤醒、休眠、Reset?​​》。MCU供电与电源管理芯片SBC（System Basic Chip）之间的关系，示意如下：

一般来说，节点（MCU）的唤醒会受控两方面作用：硬线和网络扰动。

（一）硬线唤醒MCU

所谓硬线，可以理解为IO操作，比如：KL15硬线。平时常说的ignition从off到on，本质就是KL15对应IO的闭合动作，进而使得蓄电池（KL30）的12V电使能SBC的ENA Pin，之后，SBC给对应器件输出工作电压，eg：Transceiver和uC。

注意：SBC给外围器件输出的电压，一般指这些外围器件所需要的工作电压。器件除了正常工作电压以外，还有一些监控电压，eg：CAN Trcv会常连KL30（Battery），用于自身电压和总线扰动的监控。如下图示意，VBAT属于常电（12V），而Trcv工作所用的Vcc（5V）和Vio（3.3V）则由SBC提供。即：Trcv在Sleep模式下，如果监控到唤醒事件（Wakeup Pattern或者指定的网络管理报文），拉高INH Pin，进而使能SBC给Trcv输出工作电压。

简化一下硬线使能SBC的场景，如下图：

在整车中，有的节点唤醒受KL15硬线控制，有的不受KL15硬线控制。如果节点受KL15硬件控制，KL15硬线一般作用到SBC，SBC控制uC的供电与否，进而才有节点唤醒的可能。也就是说：不同节点，唤醒源的个数和方式有区别。当然，有的SBC不仅仅受一个KL15硬线使能，还可能受其他硬线（Other Line）的使能。不管SBC受多少外部硬线作用，一般来说，这些硬线之间是或的关系，即：每个硬线可单独使能SBC，进而给MCU、Trcv等器件提供工作电压，进而唤醒对应的器件。

（二）网络扰动

所谓的网络扰动，本质：满足Transceiver的唤醒时序或者接收到指定的网络管理报文。整车中，各个节点使用的总线（Bus）个数和种类可能不同，也就意味着，各个节点被Bus使能的的情况不同。一般，节点的电路设计中，会将Trcv的INH Pin连接到SBC的WAK Pin，示意如下：

当Trcv收到特定的唤醒时序或者指定的报文时，Trcv将INH Pin拉高，进而拉高SBC的WAK Pin，使能SBC，之后，SBC给MCU、Trcv等器件输出工作电压，这样，MCU被唤醒。

如果一个节点使用多种或者多个同类型Trcv时，每个Trcv的INH与SBC WAK是并联关系，也就是说，任何一个Trcv的INH均可使能SBC，进而唤醒MCU。

对于Lin总线，工程中，可能不将其作为唤醒源，而是从属到CAN/Flexray/Ethernet的唤醒时序中。

注意：上述仅仅是唤醒MCU，还没有唤醒网络，网络的唤醒需要对唤醒源的有效性进行检查，避免电磁干扰之类的误唤醒。

MCU下电条件

MCU的下电流程（Shutdown）与MCU上电流程不同，MCU上电时，只要有一个唤醒源触发，即可唤醒MCU，但是，如果MCU想下电，则必须检查每一个唤醒源，当所有的唤醒源都不再请求通信时，MCU才能执行下电流程。

工程常见的下电检查有哪些呢？如下：

1. 所有触发唤醒的硬线状态，即：KL15等硬线是否拉低（Off状态）；

2. 是否还有诊断请求；

3. 是否还有网络管理报文；

4. 是否还有上层用户通信请求等。

当上述的所有请求都不满足时，程序开始执行MCU的下电流程。在Autosar的架构中，上述条件由BswM周期性检查，而BswM中的Rule，则需要开发者设计，当满足下电流程以后，BswM会通知EcuM，由EcuM控制节点的下电时序。

文章转载自公众号：开心果 Need Car