把座舱屏幕熄灭整车却在一夜之间漏电到无法启动——这种事情在座舱项目开发阶段几乎每个工程师都会遇到。客户抱怨得很直接你们这个高通座舱芯片到底睡没睡着是在深度睡眠还是只是把屏幕关了、SoC还在那里空转这篇文章就是围绕这个问题展开聊聊在高通座舱平台QA架构Android R上如何一步步验证STR/S2R模式是否真正生效从原理、工具准备、命令配置到实测电流数据和唤醒链路排查一次性讲清楚。这套验证方法适合座舱域控工程师、BSP/内核驱动开发、功耗测试人员和项目质量管理参考。不管你是刚接触车机功耗的新手还是被S2R进不去电流降不下来折腾过几轮的老人这里面的排查思路和实操命令应该都能直接用上。1. STR/S2R是什么先搞懂它和手机休眠的差别1.1 从一次前装项目的亏电投诉说起去年做一个前装座舱项目时客户在整车上做了静态电流测试车辆熄火锁车整车进入休眠状态按理说蓄电池静态放电电流应该压到几十毫安以内。结果实测整车电流一直在200mA以上放了一个周末电瓶直接亏到无法启动。客户拿着数据来找我们一口咬定是座舱芯片没休眠。当时我第一反应也是去查系统有没有进入suspend。结果一看日志系统确实执行了echo mem /sys/power/state也打印了PM: suspend entry看起来一切都正常。但用电流钳夹在主电源线上一测SoC侧电流是降下来了整车静态电流却还是高得离谱。最后排查出来问题根本不在SoC本身而是板上一颗USB Hub的供电没有被关掉它持续在常电上耗电流。这个案例很典型也是我写这篇文章的初衷验证STR/S2R不能只看内核日志不能只看SoC本身是否进入低功耗必须从系统级、整板级的电流路径去判断。1.2 STR和S2R的区别不要混为一谈在嵌入式Linux领域STR全称是Suspend to RAM意思是挂起到内存CPU停止执行指令进入WFIWait For Interrupt状态内存进入自刷新模式SoC内部大部分电源域被关闭或降频只保留维持内存数据和唤醒源所需的电源。这是x86和ARM平台上通用的低功耗状态。但在高通座舱平台上大家更常听到的是S2R。S2R全称是Sleep to RAM本质上是高通对挂起这一行为在自家SoC上的实现封装由RPM或RPMhResource Power Manager硬件来接管整个休眠序列。APSSApplication Processor Subsystem侧执行完最后的cache flush之后把系统状态交给RPMhRPMh再按照预先配置的电源树把APPS的各个power rail切换为低功耗模式或直接关闭同时保留DDR自刷新和唤醒源电源。两者的关系可以这么理解STR是通用术语描述的是内存保持、CPU挂起这一行为S2R是高通硬件平台上该行为的具体落地方案。验证系统是否进入STR/S2R其实就是在验证高通这套电源管理序列有没有正确执行。1.3 为什么座舱场景不能照搬手机休眠思路手机上的休眠相对简单屏幕灭、系统挂起、有电话或消息时通过modem唤醒。座舱就不一样了它面对的是整车电气环境几个关键差异决定了验证方法完全不同。座舱休眠后仍要响应多种唤醒源ACC上电、CAN总线报文、RTC定时比如预约充电提醒、甚至语音唤醒。每一种唤醒源都要在休眠状态下保持供电这意味着power tree不能一刀切全部断掉。其次座舱有时间敏感要求比如倒车影像要求唤醒后1秒内出画面这就要求不仅仅是能唤醒还要保证唤醒路径上外设的恢复时间可控。和手机不同车机还有个常电和ACC电的区分整车下电后座舱可能从正常运行切换到ACC off但常电仍在的待机状态这时候软件要主动决定多久之后进入深度睡眠。市面上多数方案的策略是ACC off之后延迟几分钟进入S2R这个延迟时间本身也是功耗优化的关键参数。所以验证S2R不只是验证按一下电源键系统挂起而是验证一整条电源和唤醒链路在整车各种上下电序列下都能可靠工作。这也是本文标题里手把手这三个字的真正含义。2. 验证环境搭建硬件、工具与测量点选择2.1 硬件准备清单验证STR/S2R最核心的硬件是电流测量工具。我自己的标准配置如下高精度电流探头配合示波器使用推荐带宽DC~50MHz以上的型号比如是德N2783B或泰克TCP0030A。测休眠电流不需要太高带宽但必须支持DC耦合因为你要看的是直流静态电流。数据采集记录仪如Keysight 34970A/34972A配数据采集模块或者直接用高精度数字万用表加记录功能。这个用来长时间记录电流曲线比如记录整夜12小时的电流变化。可编程直流电源带电流读出功能精度至少1mA级别用于给板卡供电并监控动态电流。示波器至少2通道带宽100MHz以上配合电流探头抓取休眠进入瞬间和唤醒瞬间的动态波形。如果你手头没有电流探头也可以用采样电阻法在主电源回路上串联一个10毫欧或50毫欧的高精度采样电阻用示波器差分探头或万用表测电阻两端电压I U / R换算电流。采样电阻的功率要留足余量亮屏瞬间的电流峰值很容易超过2A10毫欧电阻上就是20mV压降这个量级用万用表是测得到的但示波器要看动态波形还是建议上电流探头。2.2 电流测量点怎么选不同位置的数字含义完全不同这是整个验证过程中最容易踩坑的地方。同样一块板子在不同位置测电流测出来的数值可能差一个数量级。整车厂通常关心的是整车静态电流也就是蓄电池正极出来、经过保险丝盒到各个控制器的总电流。这个数值一般要求整车在30mA以下不同车厂标准不同。但这是整车总电流座舱控制器只是其中一个负载。板级验证时通常会区分三个测量点主电源输入即12V/5V常电进入控制器的入口。这个值包含了SoC、DDR、外设、电源转换损耗、常电域泄漏等所有功耗。S2R是否生效最直观就看这个位置的电流是否出现断崖式下降。SoC核心电源即PMIC输出给APPS的rail比如0.8V的VDD_APC。这个位置的电流反映的是SoC本身的休眠深度。进入S2R后这里的电流应该降到几毫安甚至更低。外设供电轨比如给显示屏、触摸IC、USB Hub、以太网PHY供电的LDO/DC-DC输出。很多时候系统没睡深问题都出在这些外设在休眠时依然保持供电或半供电状态。如果你只测了SoC核心电源肯定看不到外设漏电的问题反过来如果只测整板输入SoC自身的异常电流也可能被外设大电流掩盖。所以正确的做法是多点同时测量主电源输入一路SoC核心电压一路重点外设供电轨再分几路用多通道示波器或数据采集仪同步记录这样后面定位问题才方便。我实际测过的项目里主电源在S2R后降到20mA其中SoC只占3mA剩下一大半全是外设供电没关干净的这种情况不在少数。2.3 QA平台的软件准备内核开关和调试接口硬件环境搭好之后软件侧的准备工作容易被人忽略。高通平台的电源管理依赖内核的PM框架但不是默认配置就能直接支持S2R验证的。我一般会先确认以下开关CONFIG_PMy CONFIG_PM_SLEEPy CONFIG_SUSPENDy CONFIG_PM_WAKELOCKSy CONFIG_PM_DEBUGy CONFIG_PM_ADVANCED_DEBUGy CONFIG_SERIAL_MSMy CONFIG_MSM_PMy其中CONFIG_PM_ADVANCED_DEBUG特别重要它决定了/sys/kernel/debug/wakeup_sources这个节点是否可以读取。没有这个节点你排查为什么进不了休眠会非常被动。调试接口方面QA平台常见的几个节点/sys/power/state查看和触发系统休眠状态。/sys/power/wake_lock、/sys/power/wake_unlockAndroid的wake lock机制休眠前必须确认没有其他进程持有锁。/sys/power/wakeup_count配合libsuspend使用避免休眠与唤醒事件竞态。/sys/kernel/debug/wakeup_sources查看当前有哪些wakeup source处于active状态。/sys/module/msm_pm/parameters/sleep_mode高通平台特有配置睡眠模式可以看当前系统配置的sleep级别。另外QA平台的串口日志至关重要。强烈建议在验证期间把内核串口调试打开并确保休眠时串口不被断电。串口日志是整个休眠过程的黑匣子一旦电流异常第一件事永远是去抓串口日志看系统走到了哪一步。3. 手把手配置让系统真正进入STR/S2R3.1 内核与设备树配置休眠的前提条件进入S2R前提是内核能把系统中的设备逐个挂起。每个设备驱动都要注册dev_pm_ops实现suspend和resume回调。设备树中则要为那些需要在休眠时保持唤醒能力的外设配置wakeup-source属性。举个例子RTC实时时钟在S2R中承担RTC定时唤醒功能。QA平台上RTC驱动通常是rtc-pm8xxx或者rtc-pl031在设备树节点上需要加上wakeup-source否则系统即使设置了alarm也无法唤醒pm8150_rtc { status okay; wakeup-source; };对于GPIO唤醒脚比如接入CAN收发器的中断引脚需要在引脚控制器中配置为唤醒源tlmm { can_wake_pin: can-wake-pin { mux { pins gpio42; function gpio; }; config { pins gpio42; drive-strength 2; bias-pull-up; input-enable; }; }; };对应的GPIO驱动在request_irq时需要设置IRQF_NO_SUSPEND或者使用enable_irq_wake()这样在系统挂起后该中断才能把SoC唤醒。很多项目配置设备树的时候只关注了功能忽略了唤醒属性结果休眠一切正常但外部信号把系统叫不醒这种问题往往要到实车联调阶段才暴露出来排查成本很高。3.2 Android休眠策略调整QA不掉链子的关键在高通Andriod平台上系统是否允许挂起不完全是内核说了算。Android的PowerManagerService会通过/sys/power/wakeup_count和/sys/power/state与内核交互只有所有wake lock被释放屏幕关闭且没有其他活跃的wakeup source时系统才会向内核发起suspend请求。验证S2R之前需要先调整Android的display sleep超时时间一般可以在设置里把屏幕超时改成15秒或30秒方便快速触发休眠流程。同时在开发阶段直接通过命令行关闭stay onadb shell svc power stayon false adb shell input keyevent KEYCODE_SLEEP如果系统没有进入休眠先检查是否被wake lock挡住adb shell dumpsys power | grep -Ei wake lock|sleep|mWakefulness输出中如果看到mWakefulnessAwake说明系统还处于苏醒状态如果是Asleep说明Android层已经让系统进入睡眠流程接下来就轮到内核的PM框架接管了。还有一种情况是系统进入了suspend但马上又醒了来回抖动。此时看dumpsys power里的mIsPowered和mStayOn充电状态下很多板子默认不允许深度睡眠需要拔掉USB充电线或者设置adb shell svc power stayon true配合外接电源工作。3.3 手动触发休眠命令级验证配置完成之后不要急着直接测整夜先用命令行手动触发一次休眠确认基本链路是通的。最直接的触发方式就是标准Linux的suspend接口adb shell su echo mem /sys/power/state或者加上wakeup_count的防竞态操作cat /sys/power/wakeup_count # 记下当前值 echo mem /sys/power/state高通平台的开发者还可以通过msm_pm模块查看当前睡眠模式配置cat /sys/module/msm_pm/parameters/sleep_mode如果输出是PC或者S2R说明平台配置的就是power collapse电源折叠模式即我们说的S2R路径。如果输出是s2idle等则说明走的是浅层睡眠功耗不会达到最佳状态。手动触发后串口日志中应该能看到以下特征序列[ 123.456789] PM: suspend entry (deep) [ 123.460123] PM: suspend exit或者高通的日志[ 123.456789] msm_pm: system suspend called [ 123.460123] msm_pm: power collapse in progress看到这些日志再配合电流探头观察主电源电流是否下降基本就可以判定S2R路径已经通了一半。3.4 验证是否真正进入日志和电流曲线双重判定日志只能证明CPU走到了suspend流程不代表SoC所有电源域都关闭了。真正的判定标准是电流主电源输入电流必须出现断崖式下降。用一个实际案例来说明某座舱平台正常工作亮屏时12V主电源电流在600mA左右关闭屏幕、系统进入空闲后约200mA执行echo mem后电流在几百毫秒内从200mA跌到25mA这个25mA就是S2R下的稳态电流。如果只跌到80mA或者100mA就挂着不动说明有一批外设或者电源域没有被关掉。我见过最典型的误判情况是工程师看着内核日志里打印了PM: suspend entry就直接下结论说进入深度睡眠了结果测电流发现只降到了150mA。原因很简单日志里suspend entry只是说开始了但后续的suspend exit如果来得很快比如几十毫秒之后系统就又起来了日志被刷屏冲掉很难察觉。所以我的习惯是日志和电流曲线必须同步看缺一不可。建议用示波器电流探头加数据记录仪连续记录至少10分钟的电流曲线同时用串口日志打时间戳这样后续分析是第几步耗电或系统什么时候被唤醒都有据可查。4. 实测功耗数据怎么看数值才算合格4.1 测量一次完整的休眠-唤醒电流曲线手动触发休眠成功后下一步就是采集一条完整的休眠-唤醒电流曲线。我建议的操作步骤如下用数据记录仪或示波器设置好长时间采集模式采样间隔100ms记录时长至少覆盖完整的一次休眠周期和唤醒周期。在12V主电源输入端串入电流探头确保探头方向正确。系统正常运行亮屏状态记录至少30秒基线电流。关闭屏幕等待Android进入待机状态记录待机电流。等待或触发系统进入suspend记录整个挂起过程的电流波形。触发唤醒源如RTC alarm或GPIO记录从唤醒到系统完全恢复的电流波形。实测数据通常是这样的阶段电流值说明亮屏运行600~800mA屏幕背光、SoC满载、外设供电灭屏空闲150~250mA背光关闭SoC仍处于active状态suspend过程中瞬态尖峰DDR进入自刷新前的最后一次访问S2R稳态15~30mA主电源整体静态电流唤醒瞬间瞬态尖峰可达1A以上电源域重新上电、DDR恢复这个表格只是一个参考范围具体数值和平台、外设数量、屏幕尺寸关系很大。但有一条判断标准是通用的S2R稳态电流必须比灭屏空闲电流低一个数量级以上否则说明有设备没睡。4.2 数据解读与目标值对照拿到电流曲线后最重要的是判断这个数据合不合格。整车厂给的指标一般落在两个维度一是静态电流绝对值二是静态电流持续时间通常要求能撑过整车静置周期。从我的经验看一个主流的高通座舱平台比如SA8155级别在S2R状态下的主电源静态电流做到20~40mA是比较常见的优秀的调优可以压到15mA以下。如果板子上有以太网PHY、功放、USB Hub等外设每个外设正常休眠时的功耗大概是几毫安到十几毫安几个叠加起来就是很大的量。这里有个容易误解的地方SoC的S2R电流和整板静态电流是两个概念。SoC部分可能只有几毫安但整板可能因为你没有关闭某个LDO或者某个外设的使能脚而多出几十毫安。整车厂拿到的永远是从蓄电池端量到的总电流所以板级的优化目标必须放在整板输入电流上而不是只盯着SoC。判断数据是否合格我习惯用三个问题自查S2R稳态电流和灭屏空闲电流的差距是否超过10倍电流曲线在进入S2R后是否存在周期性波动如果有多半是某个唤醒源在反复试探。唤醒电流冲击结束后系统是否稳定回到工作电流还是出现异常飙升这三个问题能快速过滤掉大部分假休眠和睡眠不稳的问题。4.3 数据采集中容易忽略的坑实测数据采集过程中有几个细节非常坑单独拿出来说一下。第一个是测量设备的量程问题。示波器电流探头通常有小量程和大量程之分比如TCP0030A就有5A和30A两档。测S2R稳态电流时一定要切换到小量程档大量程档下的噪声和分辨率不足以分辨毫安级的电流变化。反过来测唤醒瞬间的尖峰电流时小量程档可能会饱和削波所以要么用不同量程各测一次要么选用动态范围大的探头。第二个是电源线的压降问题。如果用了长导线连接到板卡供电S2R稳态电流虽然小但唤醒瞬间的大电流会在导线上产生压降可能导致板卡瞬间欠压复位。我的做法是供电导线尽量短、尽量粗必要时用电子负载的远程感应Remote Sense功能补偿压降。第三个是温度漂移。S2R稳态电流往往只有几十毫安测量设备长时间工作后的温漂可能影响读数精度。如果条件允许让板卡和测量设备先预热30分钟再开始正式记录同时记录环境温度方便后续数据回溯。5. 唤醒链路验证RTC、CAN、GPIO一个都不能少5.1 RTC唤醒验证最常用的定时唤醒手段RTC唤醒是座舱S2R验证中最基础的一项。车辆长时间停放后系统可能需要在某个时间点自动起来执行任务比如OTA预下载、远程诊断预连接这时候就需要RTC Alarm在深睡状态下把SoC叫醒。RTC Alarm的设置方式在Linux下非常标准# 先清除旧的alarm echo 0 /sys/class/rtc/rtc0/wakealarm # 设置30秒后唤醒 echo 30 /sys/class/rtc/rtc0/wakealarm # 查看当前设置的alarm值 cat /sys/class/rtc/rtc0/wakealarm设置完成后让系统进入S2R等待alarm触发。如果一切正常系统应该在设定的时间点唤醒串口日志会打印wakeup source信息PM: Wakeup source: rtc0如果到了时间点系统没有醒来首先确认/sys/class/rtc/rtc0/wakealarm这个节点是否存在。如果节点不存在说明RTC驱动没有正确注册唤醒功能回到设备树检查wakeup-source属性。有个容易被忽视的细节设置alarm之后要立刻cat /sys/class/rtc/rtc0/wakealarm确认写入成功。有的驱动在alarm时间已经过期时会静默失败只打印一行内核错误日志不熟悉的话很难发现。5.2 CAN/GPIO唤醒验证整车环境的主角座舱在整车上最常见的唤醒方式其实是CAN总线唤醒。车辆解锁、开门、上电BCM车身控制器会发出CAN报文唤醒域控。这一条链路如果不通实车体验就是车都解锁了中控屏还是黑的要等十几秒才有反应。CAN唤醒验证需要模拟整车环境。简单的方式是用CAN盒如PCAN、CANoe或国产CAN卡给座舱的CAN收发器发一帧报文。CAN收发器在总线活动时会把INHInhibit引脚拉高从而给座舱的唤醒电源轨上电进而触发SoC的唤醒中断。具体验证步骤如下确认CAN收发器的INH引脚连接到座舱板卡的唤醒电源使能端。在系统休眠后用CAN工具周期发送任意一帧报文比如ID为0x100的标准帧。观察系统是否被唤醒以及唤醒后CAN通信是否正常。观察电源电流曲线确认唤醒后的电流能回到正常工作水平。GPIO唤醒的验证相对简单。找一个被配置为唤醒源的GPIO引脚比如车门状态检测脚用跳线给它一个高电平或低电平跳变确认系统能从中断中唤醒。这里要注意检查中断是否用了enable_irq_wake()这决定了该中断在系统挂起时是否仍然有效。5.3 唤醒时序与异常处理唤醒验证中比能不能唤醒更重要的一个指标是唤醒速度。座舱的倒车影像、360环视等功能要求在唤醒后极短时间内可用所以唤醒时间是一个硬指标。普遍接受的基线是从唤醒源触发到Android系统完全恢复冷启动路径在1.5秒以内是可接受的范围热睡眠唤醒S2R一般要求在500ms以内。如果发现唤醒时间超标需要拆分时间片去定位瓶颈。根据我的经验S2R唤醒时间的大头通常在三个地方DDR从自刷新恢复所需的时间这个由硬件特性决定软件能优化的空间不大但可以通过预先设置DDR的频率和时序降低延迟。关键外设驱动在resume阶段的初始化耗时。很多驱动在resume时会把整个硬件重新初始化一遍这会浪费大量时间。正确做法是在suspend时保存必要的寄存器上下文resume时快速恢复。Android的SurfaceFlinger和显示栈重建耗时。如果唤醒后屏幕迟迟不出画面问题多半在显示链路而不是SoC本身。唤醒异常方面我遇到的典型案例是系统能被RTC唤醒但唤醒后出现花屏。最终定位是DDR在自刷新期间某个bank的数据因为温度变化丢失恢复时ECC校验失败。这种情况基本无解只能是加强内存供电稳定性或者缩短自刷新时间。6. 常见问题与排查技巧实录6.1 无法进入睡眠模式症状执行echo mem /sys/power/state后系统没有反应或者马上弹回唤醒状态。排查第一步永远是查看wakeup sourcecat /sys/kernel/debug/wakeup_sources这个文件会列出所有注册了唤醒能力的设备以及它们的active count和time count。如果某个设备的active count一直在增长说明它在不断地产生唤醒事件把系统从sleep中拉出来。常见问题之一是某个外设的中断没有正确屏蔽比如触摸屏在休眠后仍会检测到虚假触摸事件不断产生中断请求。解决办法是在驱动的suspend回调中disable_irq并在resume时重新enable。如果wakeup_sources里看不到明显问题再看wake lockcat /sys/power/wake_lockAndroid框架层有时候会持有wake lock不放尤其是在音频播放或网络下载场景下。测试前用adb shell dumpsys power | grep -i wake确认没有应用持有wake lock。再补充一个高通平台的隐藏坑msm_pm模块的sleep depth配置。有些平台默认把sleep mode配置为浅层的s2idle这种模式下SoC并没有进入真正的power collapse电流自然下不去。这时候需要检查/sys/module/msm_pm/parameters/sleep_mode如果是s2idle需要在内核启动参数或sysfs中把它切换为PC/S2R。6.2 功耗降不下来症状系统确实进入了suspend状态串口日志显示PM: suspend entry但主电源电流只从几百毫安降到了100mA左右远没有达到S2R应有的水平。这种情况八成不是SoC的问题而是外设供电没有关干净。排查思路可以按从大到小的原则来先看大功率器件显示屏背光是否关闭、功放是否静音、电源指示灯是否还在亮。然后用热成像仪或者用手摸板卡找到明显发热的区域。发热就说明有电流在消耗这是最直观的定位方式。再查使能脚很多外设的供电由一颗LDO或负载开关控制这些电源芯片的使能引脚由GPIO控制。在suspend回调中驱动应该把这些GPIO拉低以切断供电。常见问题是GPIO复用配置错误导致拉低了之后又被其他外设拉回来。解决方法是检查/sys/kernel/debug/gpio看休眠后GPIO的实际电平状态。最后用二分法排查在确保系统处于S2R状态的前提下人为断开某一路外设供电比如拔掉显示屏排线、断开USB设备观察电流变化。每断开一路电流如果下降一个台阶说明问题就在那一路。这个方法虽然笨但在硬件和软件状态错综复杂的时候是最高效的手段。6.3 唤醒后系统异常症状系统能正常唤醒但唤醒后出现死机、花屏、USB设备无法识别、触摸失灵等异常。这类问题通常发生在resume路径上排查思路和suspend路径略有不同。首先看内核日志中的resume顺序。Linux在恢复阶段会按照设备在device tree中的顺序依次调用resume回调。如果某个驱动的resume回调执行时间过长或者返回错误会阻塞整个恢复流程。比较常见的情况是外设的复位时序问题。比如USB Hub在suspend时被断电resume时上电后Hub内部的固件需要重新加载这个时间如果超过了USB控制器的超时时间就会导致USB设备枚举失败。解决办法是在resume回调中增加适当延时让外设充分ready之后再进行下一步操作。另一个常被忽略的坑是时钟和PLL状态。SoC在S2R时部分时钟域被关闭resume后如果某个驱动没有等待PLL重新锁定就开始操作外设就会出现间歇性的数据错误。这种问题在日志上不会直接报错但表现为唤醒后第一次操作失败第二次就正常。6.4 常见问题速查表为了日常排查方便把上面提到的问题整理成一个速查表后续遇到类似现象可以直接对照少走很多弯路。现象可能原因排查方向进不了suspendwakeup source持续置位查看/sys/kernel/debug/wakeup_sources进不了suspendAndroid持有wake lockadb shell dumpsys power查看锁持有者进不了suspendsleep mode是s2idle而非PC检查/sys/module/msm_pm/parameters/sleep_mode电流只降一半外设供电未关断热成像定位发热点检查GPIO使能脚电流有周期性波动某唤醒源反复触发用示波器长记录查看波动周期对应的唤醒源RTC定时不唤醒RTC未注册为wakeup source检查设备树wakeup-source属性CAN不能唤醒CAN收发器INH引脚未控制电源轨查看硬件原理图确认INH连接唤醒后花屏DDR自刷新数据异常检查内存供电纹波缩短自刷新周期唤醒后USB设备不识别USB Hub恢复时间不够增大Hub reset后的延时唤醒后触摸失灵触摸IC未重新初始化查看触摸驱动的resume回调最后聊一个很多人忽略的经验验证S2R一定要尽早开始最好在硬件改版之前就做第一轮完整的功耗摸底。原因很简单如果等到硬件定型之后发现某个外设功耗超标只能从软件侧尽量去关供电但硬件的常电设计已经决定了某些模块无论如何都会耗电那时候想改板卡已经来不及了。我自己的习惯是第一版硬件贴片回来之后先不看别的功能直接先把S2R路径跑通测一遍各模块的休眠功耗基线后面再逐步加功能随时回归对比。这样到了项目后期功耗问题基本不会成为拦路虎。