AUTOSAR EcuM休眠阶段的具体实现详解

在AUTOSAR EcuM SWS里对于Sleep阶段做出了一个宏观的流程设计，如下：

从BswM过渡到EcuM的规则仲裁这里暂时不讲，有兴趣可以看之前我遇到的工程问题分析，特别是BswM状态迁移图：

https://blog.csdn.net/djkeyzx/article/details/131652713

今天主要聊AUTOSAR规定的sleep两种模式：Halt和Poll，以及这两种模式下，MCU到底是如何工作的。

1.Halt和Poll的概念

在规范中，如果休眠模式选用Halt，需要先调用API EcuM_GenerateRamHash，然后将MCU halt住，后续EcuM模块不会再执行任何代码。生成的RamHash会在核从Halt醒来后用API EcuM_CheckRamHash进行校验。

这里就出现了今天的问题一：既然生成了RAM Hash，那么意味着Halt住后至少对应计算的RAM是保持供电的（想一下英飞凌的standby ram和RH850的retention ram）；这种模式下对应CPU具体应该选择什么休眠模式呢?

如果休眠模式选用Poll，则意味着EcuM要在一个循环里不停去检查是否有唤醒。

而上述两种模式具体到MCU，是否真的就支持呢？

下面我基于RH850 F1KM系列进行分析。

2.F1KM Stand-By Mode

首先我们来了解F1Kx系列的电源域分配，如下图：

AWO(Always-On Area)，ISO(Isolated Area)。

其中，AWO的STBC、Reset Controller用于控制整个电源域；ISO可以单独关闭或者打开。这里我们就需要进一步了解和思考不同standby模式下的功耗。

那么RH850/F1KM 具有有哪些运行模式，结合手册，得到如下：

• 在系统层级的低功耗状态，该芯片支持STOP/DeepSTOP
• 有限功能的低功耗操作，该芯片支持Cyclic RUN/ Cyclic STOP

进一步的，这些模式的迁移如下：

很明显，CPU从RUN状态，只能切换至STOP/DeepSTOP/HALT模式，而要进入Cyclic RUN只能通过HALT、DEEPSTOP。Cyclic STOP只能由Cyclic RUN进入。

结合之前EcuM的GoHalt和GoPoll，这里就出现了一个疑问，什么时候进入除了HALT之外的其他四种模式？而这四种模式对功耗的影响究竟有多大？下面分析各种模式下的CPU、外设的运行状态。

2.1 HALT模式

HALT模式由指令HALT进入，该模式既不影响电源域也不影响时钟域，除了CPU以及CPU的时钟停止外，所有的外设均处于正常供电状态下运行；异常或者任意中断都可以从HALT模式恢复到RUN模式。

这种模式几乎就不存在低功耗，因此EcuM的GoHalt，我个人认为与这颗芯片的HALT模式完全是两回事。

2.2 STOP模式

STOP模式相较于HALT模式要睡得更香一点，首先是CPU子系统的时钟关闭，PLL关闭（其他时钟源继续运行），然后是在进入该模式之前，所有外设功能都停止，仅有Local RAM、Retention RAM以及IO buffer状态保持内容，注意，这里仅是时钟，所有的供电都还存在。

从STOP返回到RUN，需要WUF(Wake-up Factor)寄存器中的唤醒事件产生（具体可查对应User Mannul STBC章节）。

2.3 DeepSTOP模式

相比STOP，这种模式最香；看模式迁移那张图，在DeepSTOP模式下，ISO这块区域是灰色的，也即不仅要停掉大部分时钟，还要关掉电源。

但是AWO里还需要继续运行的外设将会选择合适的时钟继续运行。

在该模式下继续运行的有Osc、HS IntOSC、LS IntOSC、WDTA0、RTCA、TAUJ0\2、POC、LVI等。

值得注意的是，结合状态迁移图，当有唤醒事件产生时，DeepSTOP就可以返回RUN模式，也可以进入Cyclic RUN模式。这是依据WUF寄存器里定义的不同唤醒事件来决定的，例如WUF0\WUF_ISO0标志位会返回到RUN状态，WUF20会进入Cyclic RUN。

这里还有一点，在DeepSTOP模式下，如有唤醒事件的产生，CPU则会从复位向量首地址开始运行代码，可以从RESF检查标志位从而判断是否是从DeepSTOP返回的，唤醒事情也可从寄存器WUF0/ISO0读取；这里又与我理解的EcuM的GoPoll有很大差异。

2.4 Cyclic RUN和STOP模式

Cyclic RUN与RUN模式类似，但CPU是在retention RAM里获取指令，同时只有AWO外设、RLIN3、CSIG0可以使用。

这种模式字面意思很好解，就是系统周期性唤醒来检查某些事件。所以要使用这种模式，首先是要进DeepSTOP模式，然后配置后几个Wake up factor2的唤醒事件--例如TAUJ0/2的周期唤醒，将要运行的代码放置在Retention RAM里。

当从这种模式唤醒时，CPU是从Retention RAM首地址开始取指运行。

Cyclic STOP也可以参考STOP模式，但是除AWO外设和RLIN3其余全部会停止。

3.EcuM的Sleep目标与MCUStand by模式对应关系

在系统设计时，我们考虑到ECU有两种休眠模式，一种是正常休眠，这种情况个人认为是要进到最低功耗，也即DeepSTOP。还有一种是电压不稳导致的休眠，这我是在座舱里遇到的，电压低于6V，导致中控、仪表屏电供不上了，但是MCU还是可以在较低电压做一些动作，这种情况就使用Sleep或者Halt，等待电压回复，然后做具体分析。

那么结合AUTOSAR代码，我们来具体分析。

    首先是正常下电流程，在BswM完成NvM的写和验证后，选择进入Sleep，此时将控制权让渡给EcuM，假设现在EcuM的SleepMode配置里正常休眠模式配置为Poll，Standby模式选择Stop，则进入函数:

EcuM_InternalEnterPollingMode -> EcuM_McuSetMode ->Mcu_SetMode

对应芯片的StandBy模式宏定义如下：

根据所选择的Standby模式，在Mcu_SetMode里做处理：

    如果选择GoHalt，则如下：

可以看到，代码是按照AUTOSAR规范来走的，但在实际使用中，为了降低功耗，通常都会选择进入DeepSTOP模式，这时候根据该模式的描述，只要唤醒都会从reset handle开始处理；或者为了快速启动，选择进入STOP，这两种情况CPU时钟都是停掉的；因此EcuM的GoPoll中要求的一直轮询唤醒事件代码，Halt中要求的生成RAM Hash其实都很难实现。所以，AUTOSAR虽然定义非常理想，但在实际开发中，还是要根据芯片本身的低功耗控制来做具体处理。

题外话：既然选择DeepStop，那么返回至RUN模式后，在启动阶段通常还会做一件事，那就是从WUK1\2去获取唤醒事件。