简介：面向高通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%"的反馈，第一件事不是抓log
1.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"的假平坦线。我的习惯是：电源分析仪采样率至少10kHz（1ms一个点），全程存下原始数据；要确认瞬时高峰时，再用示波器在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大于-80dBm | 1到3mA | 视DRX周期、TAU周期而定 |
| LTE空闲待机 | RSRP小于-100dBm | 5到15mA | 弱信号时测量和重选更频繁 |
| LTE小流量连接态 | RSRP大于-80dBm | 15到60mA | 取决于调度和TX功率 |
| VoLTE通话 | RSRP大于-80dBm | 100到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做了一串事"，真正的根因是A，B只是后续动作。
另外，有条件的话，把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项就行。
另外，很多和射频相关的参数在MCFG（modem 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和基线背景，问题的答案其实已经出来了一大半。
本文还有配套的精品资源，点击获取
