嵌入式开发:如何识别PowerOn唤醒和总线唤醒
来源 | 开心果 Need Car
知圈 | 进车载摄像头社群,加微13501975564,备注视觉
本文要讨论的问题,如标题。这个问题源于群内小伙伴的提问,具体描述一下Ta的问题:“使用TJA 1043 CAN收发器,如何识别MCU是被PowerON唤醒还是被Bus(总线)扰动唤醒”。如果要想真正识别出MCU被PowerON唤醒还是被Bus唤醒,需要从软/硬件两个方向分析。
1、硬件
硬件层面,确切说,需要清楚自家产品的硬件原理图。一般来说,在产品硬件设计中,可以在主芯片(uC)中预留Trcv INH状态和KL15状态监控的Pin,以此判断MCU的唤醒源,示意如下:
如上图,SBC(System Basic Chip)被使能,分为两种情况:第一、类似KL15硬线,通过ENA Pin使能;第二、类似Trcv INH,通过WAK Pin使能。而这两种方式,是或的关系。所以,当KL15硬线拉高,也就是PowerOn方式使能SBC时,MCU可以通过监控KL15硬线的电平知道此次MCU的唤醒是否由KL15(PowerOn)触发。同理,当Bus有扰动或者特定报文(eg:网络管理报文)时,Trcv被唤醒,使得Trcv进入Standby Mode,进而拉高INH,INH Pin的拉高,会使能SBC,SBC再唤醒MCU,此时MCU可以通过监控INH的电平状态知道是否属于Bus唤醒。
有人说:“如果PowerOn(KL15)唤醒,INH也会拉高,INH Pin和KL15 Pin都拉高,还是区分不出。”这个表述可能不太准确,PowerOn以后,只能使得MCU唤醒,但是,网络唤醒与否,还需要软件的处理。此时,INH是否被拉高,要分情况讨论。具体说:切换Trcv状态,会改变INH Pin的状态,而Trcv状态的改变不仅受总线唤醒控制,还受到uC控制。所以,INH Pin的拉高是由于软件切换Trcv状态导致还是Trcv自身被Bus扰动导致的,还需进一步分析。所以,理清这个问题,我们就需要从另一个方面着手:软件处理。
2、软件
首先,我们要清楚,Trcv状态切换与INH Pin的关系。以TJA1043为例,状态机如下所示:
如上的状态机中,INH Pin仅在Sleep Mode模式下,处于floating状态,其余模式下均处于active状态,即:INH拉高(12V)。所以,当总线(Bus)有扰动以后,Trcv会由Sleep Mode进入Standby Mode,此时INH拉高,之后,在软件初始化的过程中,判断INH Pin的状态,如果INH拉高,说明是Bus唤醒,如果INH没有拉高,而KL15 Pin拉高,说明是PowerOn唤醒。总线扰动,Trcv状态进入Standby Mode,可以将INH Pin拉高,还有另外一种方式可以使得INH Pin拉高,即:Trcv由Sleep Mode,直接进入Normal Mode。Sleep Mode直接切换Normal Mode属于软件行为,即:软件的初始化过程中,一般会将Trcv状态切换到Normal Mode,以便于报文的接收。所以,需要在软件设置Trcv进入Normal Mode之前判断INH Pin的状态,否则,将不能区分是否Bus唤醒。
(一)思考延伸
既然,可以通过捕获INH的电平状态获取是否Bus唤醒,是否可以区分哪个Trcv唤醒的呢?答:可以。可以在MCU初始化的过程中,获取不同Trcv的INH状态获取唤醒源,如下所示:
提示:此方式,会消耗MCU的Pin资源。
3、工程思考
工程中,见过一种电路设计,如下所示:
如上的电路原理图,有什么特别的呢?就是Trcv INH Pin不使用,仅使用KL15方式唤醒MCU,之后,等待总线收到网络管理报文以后,再唤醒MCU的网络。
Q:这样的设计是否合理呢?
A:工程中,多数需求可实现(包括如上需求),能否落地实现,就是供应商和客户从各自角度要去battle的事情了。如果项目的软件架构使用CP Autosar,对于PowerOn的唤醒方式,EcuM默认Validation,也就是说:此方式,唤醒MCU时,可以唤醒网络,进而建立通信。Autosar解释如下:
Q:此方式会带来什么问题呢?
A:第一帧报文外发时间的延长,工程中,MCU第一帧报文外发时间是一个测试项,如果采样上述方式,即:PowerOn以后,软件判断是否收到NM Msg以后使能通信,会使得外发第一帧报文的时间延长,开发中,需要留意。
请先 登录 后再发表评论~