简介面向高通Modem 9xxx平台功耗调试工程师的资源包系统总结APSS、MPSS、LPASS等主要子系统及外设休眠状态检测方法围绕RPM软件休眠信号的发送、PMIC供电外设等角度定位整机休眠电流偏高问题。内容详细说明查看nap-dump.txt确认子系统是否休眠、通过飞行模式与QXDM排查MPSS未休眠、结合fmc_spm_srv.log判断APSS休眠状态、查看休眠后GPIO配置等关键手段并给出拉低PS_HOLD获取RPM Dump、用Trace32 Simulator仿真F3 LOG的可操作路径可直接用于实际功耗问题的复现、分析与调优。资源为单个docx文档压缩包大小266KB文本结构清晰涵盖总体概述、分模块调试步骤及附录工具操作便于现场查阅。目前已获12775人浏览学习是一份在高通平台功耗问题定位中值得参考的总结性资料。1. 接到待机一晚掉电20%的反馈第一件事不是抓log1.1 modem功耗为什么讨厌它不是一个外设而是一整套状态机拿到故障单的时候客户通常只说一句话功耗高。再不济加一句modem是9xxx平台的你们查查。表面看是modem待机电流高但实际上高的往往不是芯片本身而是modem所处的状态没有落到最低功耗档。拿高通modem_9xxx系列来说比如MDM9x07、MDM9x40芯片在深睡power collapse状态下自己耗的电非常少。主要功耗来自几个方向射频前端PA的静态偏置、transceiver的接收通路是否在工作、基带任务有没有被频繁唤醒以及协议栈在射频调度和协议处理上的开销。换句话说modem是一台状态机不是一个简单的开关负载。你把它放在空闲态它可能平均1mA都不到一旦某个定时器或网络事件每几十秒把它拉起来一次平均电流轻松到几十mA。所以我在处理这类问题时习惯用一个类比modem像一台对讲机平时待机收到寻呼才应答。低功耗路径在设计上是通的DRX寻呼周期、系统测量、TAU定位更新都按部就班。但如果有人每隔几秒敲一次门对讲机就一直处于开机应答的半睡状态功耗自然上不去。1.2 分流排查四步法从整机电流里把modem的份额摘出来接到反馈我第一件事从来不是开QXDM抓log而是先分流定位。终端里的耗电大户太多了屏幕背光、AP CPU、Wi-Fi/BT/GNSS、传感器、音频功放、充电芯片漏电哪个都能甩锅给modem。先做四步分流非常关键第一步开飞行模式测底电流。飞行模式同时关了蜂窝射频和modem的协议功能记下这个值A再关掉飞行模式但保持熄屏、无业务测出电流B。B减A才是蜂窝部分的大致净贡献。这一步能很快判断出蜂窝侧的功耗占比是不是真的异常。第二步把Wi-Fi、BT、传感器从系统里逐一关掉或禁用对比电流变化排除外围器件抢电。很多外设漏电会被算进整机电流高实际和modem没关系。第三步如果条件允许用QXDM把modem的空中接口关闭或者直接进FTM工厂测试模式把modem置于固定频段的IDLE态单独评估modem加RF链路本身的电流。这样能剥离AP侧的影响。第四步全程记录电流曲线保持设备熄屏静置过几分钟后拿起曲线数一下电流平台出现的周期、高度和宽度。这一步是为下一步排查做铺垫。这四步走完基本能判断问题到底在modem、RF、AP还是外设。我见过大量案例最后定位到AP侧一个wakelock每小时把modem从sleep里拖起来一次做网络请求真正的锅不在modem而在上层应用的行为。若不做分流直接一头扎进modem log里大概率白忙一天。2. 功耗调试前的三件套电流采样、QXDM log和基线数据2.1 电流采集的硬件接法和采样率设置功耗调试的第一原则电流曲线必须和log时间轴对齐。一个稳定、可复现的电流采集系统比什么都重要。我在9xxx平台上常用的方案是高精度电源分析仪比如Keysight N6705B配N6781A模块或者Keithley 2306直接用稳压源代替电池、串联在电池座正极回路里测动态电流。如果条件有限也可以用0.1欧姆高精度采样电阻加差分探头接示波器但要注意电阻上的压降会抬高最低工作电压采样率也要看示波器性能。采样率这件事必须较真。DRX寻呼周期常见的是1.28s、2.56s每次唤醒做一次寻呼解码的时间在几毫秒到几十毫秒。如果采样率只有1Hz这些尖峰全部被平均掉你只能看到一条1.5mA的假平坦线。我的习惯是电源分析仪采样率至少10kHz1ms一个点全程存下原始数据要确认瞬时高峰时再用示波器在PA供电处做单次触发。接线也要注意如果设备本身带充电IC从USB口供电时电流会走充电路径测到的根本不是电池侧电流。必须直接从电池连接器处串入电流表或者用稳压源代替电池。我踩过好几次坑差距就出现在这条供电回路上。2.2 打开诊断端口抓一份干净的QXDM log电流有了还需要modem内部日志。高通平台常规做法是用QXDM连接诊断口把modem的Message Log和Event Log完整抓下来。前提是设备要解锁诊断功能一般通过ADB开启adb root adb shell setprop persist.vendor.usb.config diag,adb adb reboot重启后电脑设备管理器里应该出现Qualcomm HS-USB Diagnostics端口记下端口号在QXDM里选它。连接成功后能看到modem版本信息和NV Browser说明诊断链路已通。这里说的干净有两层含义。第一log内容要够但不过度。每次抓log前我先把不需要的通道过滤掉只保留和睡眠唤醒、协议状态、射频测量、NAS/RRC信令相关的message全量抓的话文件大得吓人分析时反而翻不过来。第二抓log期间不要用UART线或任何额外调试线缆连接目标板。很多modem检测到外部调试连接后会主动保持唤醒或者diag实时上报本身就会阻止power collapse结果就是电流曲线被莫名抬高你会把抓log导致的高电流误判成设备实际待机电流高。抓log过程中的标记动作也很重要。我的习惯是开启log和电流记录后先做亮屏-熄屏、再做关闭再打开移动数据两个台阶性操作。这两个动作在电流曲线上会形成明显台阶在log里也能找到对应信令后面时间轴对齐全靠它们。2.3 基线数据从哪来先知道正常长什么样没有基线一切异常都无从谈起。我每到一个新项目第一周不会去查bug而是把所有常见场景的电流基线测出来存成模板。对modem_9xxx平台至少要有这么几组测试场景网络条件参考电流范围经验值备注飞行模式无小于1mA主要是AP和器件漏电LTE空闲待机RSRP大于-80dBm1到3mA视DRX周期、TAU周期而定LTE空闲待机RSRP小于-100dBm5到15mA弱信号时测量和重选更频繁LTE小流量连接态RSRP大于-80dBm15到60mA取决于调度和TX功率VoLTE通话RSRP大于-80dBm100到300mA与编码速率、C-DRX/SPS相关表格里的数字只是经验范围不同网络配置差异很大不能拿别人的基线硬套。但如果实测电流明显脱离范围至少说明有事情在发生可以进入下一步逐段排查。基线还有一个作用修改完参数之后拿同场景数据对比验证改动是否真的有效而不是凭感觉说好了很多。3. 空闲态功耗异常从电流波形到唤醒源的完整排查3.1 先把电流曲线分区段别急着看细节拿到一条实测电流曲线第一件事不是盯着毫米级的一段看而是全图缩放把曲线分成几类片段稳定的低电流平台这是理想待机态说明modem大部分时间在sleep规律性出现的窄尖峰间隔基本固定通常是DRX寻呼唤醒宽度一般在几十毫秒内不规则的较宽脉冲或小平台持续几十毫秒到几百毫秒多半是小区测量、系统信息读取、TAU、小区重选整段抬升且带噪声的长平台说明modem一直醒着可能卡在RRC连接态或者内部任务忙循环。先用尺子在屏幕上量出这些段的周期和宽度很多时候问题就藏在周期对不上里。比如DRX周期明明配的是2.56s曲线却是每1.28s就出一个尖峰那就该想是不是哪里把IDRX周期又覆盖了一遍又比如本该规律的窄尖峰却有随机大尖峰混进来那就优先追这个大尖峰发生在哪个时间点。3.2 唤醒源定位log里的SLEEP/WAKEUP线索在哪看把电流曲线上异常段的时间点标注出来后就到QXDM log里找同一时刻附近发生了什么。modem睡眠穿越的关键线索通常在Event Log通道的sleep/wakeup事件里比较稳定的字段包括进入sleep的时间、唤醒的时间、wakeup reason、对应的中断源或事件源。具体操作上我一般直接对Event Log窗口做关键字过滤像sleep、wakeup、power collapse、paging、TAU、measurement这类词先用时间戳锁定区间再逐个展开。不要只在同一时间点附近抓事件还要往后延1到2秒因为很多异常唤醒是先被A唤醒然后因为B做了一串事真正的根因是AB只是后续动作。另外有条件的话把modem侧的CPU占用也拉出来看一眼。高通平台有些调试版系统里带Perf Analyzer或类似性能工具能看modem内部各任务的运行时间和唤醒次数。假如某个协议任务持续忙循环即使没有任何网络事件modem也会一直醒着这类问题光看信令log是看不出来的。3.3 四个高频空闲态根因及修改方向空闲态高功耗的根因我在这几年的9xxx项目里反复遇到的主要是下面几类现象可能的根因排查/修改方向规律窄尖峰但幅度高、间隔短DRX寻呼周期配置过短检查网络下发的Paging周期和UE偏好的DRX参数必要时调整modem侧UE偏好NV周期性出现200ms级脉冲间隔分钟级周期TAU定时器T3412过短查看TAU请求里协商的周期在NV或AP配置里调整合适的TAU周期偏好电流长期在中等平台有明显噪声modem未进入power collapse或RRC未释放查RRC释放信令、AP侧QMI连接是否长时间挂起、有无外部wakelock不规则大尖峰连成片频繁小区重选、搜网、测量查SIB里的测量配置、重选优先级、邻区列表弱信号下尤其明显修改方向里有一句必须说清楚modem侧能改的是UE偏好和本地定时器但网络侧下发的paging周期、T3412最终由网络决定。所以很多功耗优化并不是改个NV就完事而是要和运营商侧协调参数。测试时也建议锁定同一个小区对比避免把网络侧变了误归因成参数生效了。4. 连接态和数据业务的高耗电RF与协议开销怎么分开算4.1 连接态功耗的基本盘TX功率、RF链路、基带处理如果问题出在业务态比如看视频时模块发烫或者开通数据连接后电流下不来光盯着sleep看没意义因为连接态本来就比空闲态高一个量级。这时候要先拆解连接态里的功耗构成。第一块是RF前端。PA是耗电大头尤其上行发射功率大的时候。一个LTE频段的PA在最大发射功率23dBm附近工作时瞬时电流能到几百毫安甚至更大。所以TX功率曲线是首要指标QXDM或FTM里都能读到每时隙的TX power、PA bias等信息。弱信号下UE会被网络调度抬高发射功率功耗自然上涨这是物理规律不是bug。第二块是基带和DSP处理。数据量越大、处理的RB数越多、调制阶数越高功耗越高。如果开了载波聚合或MIMO接收链路成倍增加功耗也几乎成比例上升。我见过不少连接态功耗高得离谱的反馈一查总速率并不大但UE一直被网络调度占用大量RB持续高速收发发烫是应得的。第三块是外围RF器件的静态功耗比如射频开关、LNA的偏置。只要RX/TX通路没被正确关断它们就会一直耗电。这类问题在log里不容易直接看出来要靠对比不同频段、不同收发状态的电流差异来定位。4.2 数据业务一定要确认C-DRX和eDRX有没有真正生效数据业务场景里最容易出现配置了省电参数但实际没生效的情况。LTE连接态无数据时C-DRX连接态非连续接收如果正常配置modem会在不监控PDCCH的子帧进入微睡眠电流能降一个档次但如果网络没有下发DRX-Config或者modem侧实现有问题连接态就一直是全时监听状态电流掉不下来。检查方法分两步。先看log里RRC重配置消息中的DRX配置是否存在确认周期、onDurationTimer、inactivityTimer这些参数再看电流曲线上有没有与DRX周期对应的规律起伏。如果配置有但电流没有周期性起伏多半是modem内部某个功能阻止了微睡需要逐个排查哪个功能模块在占用射频或基带。物联网场景还要看eDRX和PSM。9xxx系列里支持NB-IoT或Cat-M的型号eDRX周期可以拉到几十秒甚至数分钟PSM更能让设备失联大半天。客户既要低功耗又要服务器秒级下发这个矛盾只能从eDRX窗口大小和可达性上权衡。改这些参数往往不只是NV层面还要看SIM卡签约和网络侧支持否则设备再想省电网络不配合也白搭。4.3 语音通话的SPS与AMR节能策略VoLTE通话的功耗很多人以为主要是发射造成的其实调度开销也占不少。VoIP包小、周期固定20ms一包如果每个包都要通过PDCCH动态调度来分配资源modem就得一直监听PDCCH功耗高且浪费资源。协议上专门有SPS半持续调度来解决这个问题网络把资源按周期提前配置好UE在固定时频资源上收发不用每个TTI都监听调度信令。所以遇到VoLTE通话功耗偏高我会先确认SPS有没有被网络激活。SPS需要网络决定并下发配置UE侧能做的更多是通过上报和IMS参数间接影响。如果SPS生效电流曲线通常呈规则的周期性小起伏否则是一条相对平直较高的平台。语音编码速率也值得对比。AMR-NB从12.2kbps降到7.95kbps发射功率不一定有本质差异但对DSP计算量、传输时长是有影响的。有些项目为了压功耗会在保证语音质量的前提下选择更低速率。但编码速率不是modem单方决定是终端和网络协商的结果测试时要在协议允许范围内评估。5. 改参、验证、回归以及我掉过几次的坑5.1 NV/EFS参数怎么落地改完要不要全擦功耗参数最终有一多半要落到NV或EFS文件里。比如T3412周期的UE偏好值、UE偏好的DRX周期、eDRX/PSM相关参数在NV里通常能找到对应项。修改的标准化流程是先用QPST或EFS工具把当前NV导出来备份再定位到具体NV项修改、写入最后重启modem重新注册网络抓log确认新参数真的被使用。关于改完要不要全擦我要特别提醒不要动不动做modem侧的factory reset或全分区擦除。NV里除了功耗参数还有IMEI、RF校准、天线校准、厂商特殊配置全擦之后如果备份不全终端可能直接失联或收发校准异常排查起来更痛苦。正常流程只改目标NV项就行。另外很多和射频相关的参数在MCFGmodem configuration里而不是NV里。改MCFG的方式通常是改代码重新编译modem整包这种改动和平台版本强绑定不能用QPST直接改。动手之前先确认目标参数到底在NV、MCFG还是代码宏里能省掉大量无效操作。5.2 功耗回归实验设计场景、时长、统计口径参数改了验证不能只在一个场景下测一个平均电流就收工。我的回归清单大致是这样的信号强度至少分三档强信号RSRP大于-80dBm、中信号-90到-100dBm、弱信号小于-105dBm每个档位都跑一遍空闲态和连接态状态覆盖静止待机、步行移动、进出电梯或地下室移动场景里小区重选和测量更频繁最容易暴露功耗劣化时间长度待机场景至少连续测2小时。很多TAU周期是几十分钟一趟只测30分钟可能根本没覆盖到周期性TAU平均电流没有说服力统计口径分三列记录平均电流、峰值电流、高功耗段占比。平均电流决定续航峰值电流影响电池和发热改完之后拿这三列和基线对比才知道是真优化还是只是换了波形。有一次我改完DRX偏好平均电流从3mA降到1.2mA看似成功。但看了峰值记录发现弱信号下每隔几分钟就有一次500mA级别的大尖峰后来定位到是高优先级小区重选频繁失败触发的RRC重建风暴。只盯平均值这类问题很容易漏掉。5.3 调试中容易踩的坑最后把我这些年掉进去过的坑集中列一下每一条都是概率很高的坑抓log时开着diag实时上报或者插着UART线modem被调试链路持续唤醒测出来的电流整体偏高容易得出modem功耗有bug的错误结论。正确做法是抓完状态log后先拔掉调试线单独测正常使用状态下的电流。用USB口供电时电流经过充电IC读到的不是真实的电池侧电流。测功耗前一定确认供电回路要不直接用稳压源代替电池要不从电池连接器处串电流表。无卡待机和高频搜网状态和正常插卡注册网络的电流完全是两码事。客户报待机电流高先确认是否插了卡、是否注册上网络否则数据没有参考价值。同一片模组室外35度和空调房22度测出来的电流不一样。PA静态功耗和漏电随温度漂移做前后对比必须统一温度环境。NV备份不全就改参数改了重启起不来又手忙脚乱恢复。改之前EFS、NV、MCFG三样备份一个都不能少。只看平均电流不看波形分布。两个方案平均电流一样但一个峰值在200mA一个峰值在600mA对电池寿命和压降的影响完全不同。这些坑单独拎出来都很小但串在一起足以让一次功耗调试白费一整周。最后再说一点我自己的习惯性做法做功耗调试真正值钱的东西不是哪个NV项而是你的基线库和判断框架。每完成一个9xxx项目我会把基线和典型异常曲线整理成一个文档新项目来了直接套用排查效率能提高一大截。以后再遇到待机一晚掉电20%这种反馈先让对方提供电流曲线、log和基线背景问题的答案其实已经出来了一大半。本文还有配套的精品资源点击获取 Modem待机功耗高？从电流分流到NV调参的完整排查思路
简介面向高通Modem 9xxx平台功耗调试工程师的资源包系统总结APSS、MPSS、LPASS等主要子系统及外设休眠状态检测方法围绕RPM软件休眠信号的发送、PMIC供电外设等角度定位整机休眠电流偏高问题。内容详细说明查看nap-dump.txt确认子系统是否休眠、通过飞行模式与QXDM排查MPSS未休眠、结合fmc_spm_srv.log判断APSS休眠状态、查看休眠后GPIO配置等关键手段并给出拉低PS_HOLD获取RPM Dump、用Trace32 Simulator仿真F3 LOG的可操作路径可直接用于实际功耗问题的复现、分析与调优。资源为单个docx文档压缩包大小266KB文本结构清晰涵盖总体概述、分模块调试步骤及附录工具操作便于现场查阅。目前已获12775人浏览学习是一份在高通平台功耗问题定位中值得参考的总结性资料。1. 接到待机一晚掉电20%的反馈第一件事不是抓log1.1 modem功耗为什么讨厌它不是一个外设而是一整套状态机拿到故障单的时候客户通常只说一句话功耗高。再不济加一句modem是9xxx平台的你们查查。表面看是modem待机电流高但实际上高的往往不是芯片本身而是modem所处的状态没有落到最低功耗档。拿高通modem_9xxx系列来说比如MDM9x07、MDM9x40芯片在深睡power collapse状态下自己耗的电非常少。主要功耗来自几个方向射频前端PA的静态偏置、transceiver的接收通路是否在工作、基带任务有没有被频繁唤醒以及协议栈在射频调度和协议处理上的开销。换句话说modem是一台状态机不是一个简单的开关负载。你把它放在空闲态它可能平均1mA都不到一旦某个定时器或网络事件每几十秒把它拉起来一次平均电流轻松到几十mA。所以我在处理这类问题时习惯用一个类比modem像一台对讲机平时待机收到寻呼才应答。低功耗路径在设计上是通的DRX寻呼周期、系统测量、TAU定位更新都按部就班。但如果有人每隔几秒敲一次门对讲机就一直处于开机应答的半睡状态功耗自然上不去。1.2 分流排查四步法从整机电流里把modem的份额摘出来接到反馈我第一件事从来不是开QXDM抓log而是先分流定位。终端里的耗电大户太多了屏幕背光、AP CPU、Wi-Fi/BT/GNSS、传感器、音频功放、充电芯片漏电哪个都能甩锅给modem。先做四步分流非常关键第一步开飞行模式测底电流。飞行模式同时关了蜂窝射频和modem的协议功能记下这个值A再关掉飞行模式但保持熄屏、无业务测出电流B。B减A才是蜂窝部分的大致净贡献。这一步能很快判断出蜂窝侧的功耗占比是不是真的异常。第二步把Wi-Fi、BT、传感器从系统里逐一关掉或禁用对比电流变化排除外围器件抢电。很多外设漏电会被算进整机电流高实际和modem没关系。第三步如果条件允许用QXDM把modem的空中接口关闭或者直接进FTM工厂测试模式把modem置于固定频段的IDLE态单独评估modem加RF链路本身的电流。这样能剥离AP侧的影响。第四步全程记录电流曲线保持设备熄屏静置过几分钟后拿起曲线数一下电流平台出现的周期、高度和宽度。这一步是为下一步排查做铺垫。这四步走完基本能判断问题到底在modem、RF、AP还是外设。我见过大量案例最后定位到AP侧一个wakelock每小时把modem从sleep里拖起来一次做网络请求真正的锅不在modem而在上层应用的行为。若不做分流直接一头扎进modem log里大概率白忙一天。2. 功耗调试前的三件套电流采样、QXDM log和基线数据2.1 电流采集的硬件接法和采样率设置功耗调试的第一原则电流曲线必须和log时间轴对齐。一个稳定、可复现的电流采集系统比什么都重要。我在9xxx平台上常用的方案是高精度电源分析仪比如Keysight N6705B配N6781A模块或者Keithley 2306直接用稳压源代替电池、串联在电池座正极回路里测动态电流。如果条件有限也可以用0.1欧姆高精度采样电阻加差分探头接示波器但要注意电阻上的压降会抬高最低工作电压采样率也要看示波器性能。采样率这件事必须较真。DRX寻呼周期常见的是1.28s、2.56s每次唤醒做一次寻呼解码的时间在几毫秒到几十毫秒。如果采样率只有1Hz这些尖峰全部被平均掉你只能看到一条1.5mA的假平坦线。我的习惯是电源分析仪采样率至少10kHz1ms一个点全程存下原始数据要确认瞬时高峰时再用示波器在PA供电处做单次触发。接线也要注意如果设备本身带充电IC从USB口供电时电流会走充电路径测到的根本不是电池侧电流。必须直接从电池连接器处串入电流表或者用稳压源代替电池。我踩过好几次坑差距就出现在这条供电回路上。2.2 打开诊断端口抓一份干净的QXDM log电流有了还需要modem内部日志。高通平台常规做法是用QXDM连接诊断口把modem的Message Log和Event Log完整抓下来。前提是设备要解锁诊断功能一般通过ADB开启adb root adb shell setprop persist.vendor.usb.config diag,adb adb reboot重启后电脑设备管理器里应该出现Qualcomm HS-USB Diagnostics端口记下端口号在QXDM里选它。连接成功后能看到modem版本信息和NV Browser说明诊断链路已通。这里说的干净有两层含义。第一log内容要够但不过度。每次抓log前我先把不需要的通道过滤掉只保留和睡眠唤醒、协议状态、射频测量、NAS/RRC信令相关的message全量抓的话文件大得吓人分析时反而翻不过来。第二抓log期间不要用UART线或任何额外调试线缆连接目标板。很多modem检测到外部调试连接后会主动保持唤醒或者diag实时上报本身就会阻止power collapse结果就是电流曲线被莫名抬高你会把抓log导致的高电流误判成设备实际待机电流高。抓log过程中的标记动作也很重要。我的习惯是开启log和电流记录后先做亮屏-熄屏、再做关闭再打开移动数据两个台阶性操作。这两个动作在电流曲线上会形成明显台阶在log里也能找到对应信令后面时间轴对齐全靠它们。2.3 基线数据从哪来先知道正常长什么样没有基线一切异常都无从谈起。我每到一个新项目第一周不会去查bug而是把所有常见场景的电流基线测出来存成模板。对modem_9xxx平台至少要有这么几组测试场景网络条件参考电流范围经验值备注飞行模式无小于1mA主要是AP和器件漏电LTE空闲待机RSRP大于-80dBm1到3mA视DRX周期、TAU周期而定LTE空闲待机RSRP小于-100dBm5到15mA弱信号时测量和重选更频繁LTE小流量连接态RSRP大于-80dBm15到60mA取决于调度和TX功率VoLTE通话RSRP大于-80dBm100到300mA与编码速率、C-DRX/SPS相关表格里的数字只是经验范围不同网络配置差异很大不能拿别人的基线硬套。但如果实测电流明显脱离范围至少说明有事情在发生可以进入下一步逐段排查。基线还有一个作用修改完参数之后拿同场景数据对比验证改动是否真的有效而不是凭感觉说好了很多。3. 空闲态功耗异常从电流波形到唤醒源的完整排查3.1 先把电流曲线分区段别急着看细节拿到一条实测电流曲线第一件事不是盯着毫米级的一段看而是全图缩放把曲线分成几类片段稳定的低电流平台这是理想待机态说明modem大部分时间在sleep规律性出现的窄尖峰间隔基本固定通常是DRX寻呼唤醒宽度一般在几十毫秒内不规则的较宽脉冲或小平台持续几十毫秒到几百毫秒多半是小区测量、系统信息读取、TAU、小区重选整段抬升且带噪声的长平台说明modem一直醒着可能卡在RRC连接态或者内部任务忙循环。先用尺子在屏幕上量出这些段的周期和宽度很多时候问题就藏在周期对不上里。比如DRX周期明明配的是2.56s曲线却是每1.28s就出一个尖峰那就该想是不是哪里把IDRX周期又覆盖了一遍又比如本该规律的窄尖峰却有随机大尖峰混进来那就优先追这个大尖峰发生在哪个时间点。3.2 唤醒源定位log里的SLEEP/WAKEUP线索在哪看把电流曲线上异常段的时间点标注出来后就到QXDM log里找同一时刻附近发生了什么。modem睡眠穿越的关键线索通常在Event Log通道的sleep/wakeup事件里比较稳定的字段包括进入sleep的时间、唤醒的时间、wakeup reason、对应的中断源或事件源。具体操作上我一般直接对Event Log窗口做关键字过滤像sleep、wakeup、power collapse、paging、TAU、measurement这类词先用时间戳锁定区间再逐个展开。不要只在同一时间点附近抓事件还要往后延1到2秒因为很多异常唤醒是先被A唤醒然后因为B做了一串事真正的根因是AB只是后续动作。另外有条件的话把modem侧的CPU占用也拉出来看一眼。高通平台有些调试版系统里带Perf Analyzer或类似性能工具能看modem内部各任务的运行时间和唤醒次数。假如某个协议任务持续忙循环即使没有任何网络事件modem也会一直醒着这类问题光看信令log是看不出来的。3.3 四个高频空闲态根因及修改方向空闲态高功耗的根因我在这几年的9xxx项目里反复遇到的主要是下面几类现象可能的根因排查/修改方向规律窄尖峰但幅度高、间隔短DRX寻呼周期配置过短检查网络下发的Paging周期和UE偏好的DRX参数必要时调整modem侧UE偏好NV周期性出现200ms级脉冲间隔分钟级周期TAU定时器T3412过短查看TAU请求里协商的周期在NV或AP配置里调整合适的TAU周期偏好电流长期在中等平台有明显噪声modem未进入power collapse或RRC未释放查RRC释放信令、AP侧QMI连接是否长时间挂起、有无外部wakelock不规则大尖峰连成片频繁小区重选、搜网、测量查SIB里的测量配置、重选优先级、邻区列表弱信号下尤其明显修改方向里有一句必须说清楚modem侧能改的是UE偏好和本地定时器但网络侧下发的paging周期、T3412最终由网络决定。所以很多功耗优化并不是改个NV就完事而是要和运营商侧协调参数。测试时也建议锁定同一个小区对比避免把网络侧变了误归因成参数生效了。4. 连接态和数据业务的高耗电RF与协议开销怎么分开算4.1 连接态功耗的基本盘TX功率、RF链路、基带处理如果问题出在业务态比如看视频时模块发烫或者开通数据连接后电流下不来光盯着sleep看没意义因为连接态本来就比空闲态高一个量级。这时候要先拆解连接态里的功耗构成。第一块是RF前端。PA是耗电大头尤其上行发射功率大的时候。一个LTE频段的PA在最大发射功率23dBm附近工作时瞬时电流能到几百毫安甚至更大。所以TX功率曲线是首要指标QXDM或FTM里都能读到每时隙的TX power、PA bias等信息。弱信号下UE会被网络调度抬高发射功率功耗自然上涨这是物理规律不是bug。第二块是基带和DSP处理。数据量越大、处理的RB数越多、调制阶数越高功耗越高。如果开了载波聚合或MIMO接收链路成倍增加功耗也几乎成比例上升。我见过不少连接态功耗高得离谱的反馈一查总速率并不大但UE一直被网络调度占用大量RB持续高速收发发烫是应得的。第三块是外围RF器件的静态功耗比如射频开关、LNA的偏置。只要RX/TX通路没被正确关断它们就会一直耗电。这类问题在log里不容易直接看出来要靠对比不同频段、不同收发状态的电流差异来定位。4.2 数据业务一定要确认C-DRX和eDRX有没有真正生效数据业务场景里最容易出现配置了省电参数但实际没生效的情况。LTE连接态无数据时C-DRX连接态非连续接收如果正常配置modem会在不监控PDCCH的子帧进入微睡眠电流能降一个档次但如果网络没有下发DRX-Config或者modem侧实现有问题连接态就一直是全时监听状态电流掉不下来。检查方法分两步。先看log里RRC重配置消息中的DRX配置是否存在确认周期、onDurationTimer、inactivityTimer这些参数再看电流曲线上有没有与DRX周期对应的规律起伏。如果配置有但电流没有周期性起伏多半是modem内部某个功能阻止了微睡需要逐个排查哪个功能模块在占用射频或基带。物联网场景还要看eDRX和PSM。9xxx系列里支持NB-IoT或Cat-M的型号eDRX周期可以拉到几十秒甚至数分钟PSM更能让设备失联大半天。客户既要低功耗又要服务器秒级下发这个矛盾只能从eDRX窗口大小和可达性上权衡。改这些参数往往不只是NV层面还要看SIM卡签约和网络侧支持否则设备再想省电网络不配合也白搭。4.3 语音通话的SPS与AMR节能策略VoLTE通话的功耗很多人以为主要是发射造成的其实调度开销也占不少。VoIP包小、周期固定20ms一包如果每个包都要通过PDCCH动态调度来分配资源modem就得一直监听PDCCH功耗高且浪费资源。协议上专门有SPS半持续调度来解决这个问题网络把资源按周期提前配置好UE在固定时频资源上收发不用每个TTI都监听调度信令。所以遇到VoLTE通话功耗偏高我会先确认SPS有没有被网络激活。SPS需要网络决定并下发配置UE侧能做的更多是通过上报和IMS参数间接影响。如果SPS生效电流曲线通常呈规则的周期性小起伏否则是一条相对平直较高的平台。语音编码速率也值得对比。AMR-NB从12.2kbps降到7.95kbps发射功率不一定有本质差异但对DSP计算量、传输时长是有影响的。有些项目为了压功耗会在保证语音质量的前提下选择更低速率。但编码速率不是modem单方决定是终端和网络协商的结果测试时要在协议允许范围内评估。5. 改参、验证、回归以及我掉过几次的坑5.1 NV/EFS参数怎么落地改完要不要全擦功耗参数最终有一多半要落到NV或EFS文件里。比如T3412周期的UE偏好值、UE偏好的DRX周期、eDRX/PSM相关参数在NV里通常能找到对应项。修改的标准化流程是先用QPST或EFS工具把当前NV导出来备份再定位到具体NV项修改、写入最后重启modem重新注册网络抓log确认新参数真的被使用。关于改完要不要全擦我要特别提醒不要动不动做modem侧的factory reset或全分区擦除。NV里除了功耗参数还有IMEI、RF校准、天线校准、厂商特殊配置全擦之后如果备份不全终端可能直接失联或收发校准异常排查起来更痛苦。正常流程只改目标NV项就行。另外很多和射频相关的参数在MCFGmodem configuration里而不是NV里。改MCFG的方式通常是改代码重新编译modem整包这种改动和平台版本强绑定不能用QPST直接改。动手之前先确认目标参数到底在NV、MCFG还是代码宏里能省掉大量无效操作。5.2 功耗回归实验设计场景、时长、统计口径参数改了验证不能只在一个场景下测一个平均电流就收工。我的回归清单大致是这样的信号强度至少分三档强信号RSRP大于-80dBm、中信号-90到-100dBm、弱信号小于-105dBm每个档位都跑一遍空闲态和连接态状态覆盖静止待机、步行移动、进出电梯或地下室移动场景里小区重选和测量更频繁最容易暴露功耗劣化时间长度待机场景至少连续测2小时。很多TAU周期是几十分钟一趟只测30分钟可能根本没覆盖到周期性TAU平均电流没有说服力统计口径分三列记录平均电流、峰值电流、高功耗段占比。平均电流决定续航峰值电流影响电池和发热改完之后拿这三列和基线对比才知道是真优化还是只是换了波形。有一次我改完DRX偏好平均电流从3mA降到1.2mA看似成功。但看了峰值记录发现弱信号下每隔几分钟就有一次500mA级别的大尖峰后来定位到是高优先级小区重选频繁失败触发的RRC重建风暴。只盯平均值这类问题很容易漏掉。5.3 调试中容易踩的坑最后把我这些年掉进去过的坑集中列一下每一条都是概率很高的坑抓log时开着diag实时上报或者插着UART线modem被调试链路持续唤醒测出来的电流整体偏高容易得出modem功耗有bug的错误结论。正确做法是抓完状态log后先拔掉调试线单独测正常使用状态下的电流。用USB口供电时电流经过充电IC读到的不是真实的电池侧电流。测功耗前一定确认供电回路要不直接用稳压源代替电池要不从电池连接器处串电流表。无卡待机和高频搜网状态和正常插卡注册网络的电流完全是两码事。客户报待机电流高先确认是否插了卡、是否注册上网络否则数据没有参考价值。同一片模组室外35度和空调房22度测出来的电流不一样。PA静态功耗和漏电随温度漂移做前后对比必须统一温度环境。NV备份不全就改参数改了重启起不来又手忙脚乱恢复。改之前EFS、NV、MCFG三样备份一个都不能少。只看平均电流不看波形分布。两个方案平均电流一样但一个峰值在200mA一个峰值在600mA对电池寿命和压降的影响完全不同。这些坑单独拎出来都很小但串在一起足以让一次功耗调试白费一整周。最后再说一点我自己的习惯性做法做功耗调试真正值钱的东西不是哪个NV项而是你的基线库和判断框架。每完成一个9xxx项目我会把基线和典型异常曲线整理成一个文档新项目来了直接套用排查效率能提高一大截。以后再遇到待机一晚掉电20%这种反馈先让对方提供电流曲线、log和基线背景问题的答案其实已经出来了一大半。本文还有配套的精品资源点击获取