做电池供电的物联网终端最怕的不是功能跑不通而是功能全通了一量整机休眠电流心态直接炸裂。我手上这台设备用的是移远EC21和EC200系列4G模组云平台统计出来的整机休眠电流稳在13mA项目指标却卡在7mA以内。13mA是什么概念一块10000mAh锂电池光待机理论时间只有一个月出头放在户外再碰上一周连续阴雨没有太阳能补充整个终端就是一块废砖。前后折腾了四天最后把休眠功耗从13mA压到了6.1mA中间踩的坑说多不多说少不少核心问题全集中在“引脚处理”和“AT指令配置顺序”上。这篇就把完整的排查过程和AT指令流程整理出来给正在调移远EC21、EC200系列低功耗的朋友做个参考。1. 先说清楚13mA这个数是怎么量出来的1.1 项目背景和为什么13mA不可接受设备是一个太阳能供电的野外资产监测终端主控用的STM324G模组分批次用过EC21和EC200S两个型号业务逻辑很简单每天定时唤醒上报一次传感器数据然后立刻回到休眠状态。因为设备安装在铁塔和野外管道井里没有市电整机供电靠3.7V锂电池加太阳能板所以休眠电流几乎决定了产品能不能用。当时云平台后台统计的“离线平均电流”是13mA左右我按10000mAh电池粗算了一下10000mAh / 13mA ≈ 769小时也就是32天一个多月就没电了。换成6mA的话理论待机能拉到69天接近两个月。如果再考虑太阳能充电差距就更明显。所以这个13mA不是“差不多能用”的问题而是产品逻辑上根本不成立。还有一个容易被忽略的点这类设备的平台侧会配置心跳保活模组也有周期性TAU网络附着更新机制这些都会产生周期性电流尖峰。如果只拿万用表掐个秒表看平均值很容易被迷惑。1.2 想测准休眠电流万用表是真的不行先别急着调AT指令测量工具不对后面全是白忙活。我在项目刚开始的时候犯过一个错误直接把万用表串进电源线看到13mA就开始调配置。后来换了测量方式才发现这个13mA里面藏了不少“瞬时尖峰”和“周期性波形”万用表显示的只是一个粗糙的积分结果根本看不出来模组到底有没有进入休眠。万用表吃力的原因很简单蜂窝模组在射频发射瞬间电流可以冲到2A级别而休眠时只有几毫安动态范围差了上千倍。普通万用表的采样率通常只有每秒几次遇到这种“平时安静、一叫就炸”的负载读数会严重失真。我的做法是串一个0.1Ω采样电阻用示波器长时间录制电流波形。注意采样电阻不能选太大我曾经图方便直接拿1Ω电阻顶上结果模组在射频发射的时候1A多的电流在电阻上压降超过1V直接把模组电压拉到复位门槛附近设备反复重启功耗曲线乱成一团。如果你手上没有专业功耗分析仪比如Joulescope、Otii那类用0.1Ω采样电阻加示波器至少能把趋势看清楚。1.3 测量环境与基线排查低功耗问题第一步一定不是改代码而是把系统拆开量基线。我先把模组从主控板上断开单独给模组供电让模组自己完成开机、注册网络、附着然后保持静止状态量它的“裸待机电流”。当时单独模组的裸待机电流大约11mA左右加上主控板整机13mA。这一下就把范围缩小了主控板本身的贡献大概2mA左右大头在模组但11mA对EC21来说明显偏高正常CSI休眠模式下电流应该在6mA附近。也就是说问题主要出在模组侧。拿到这个基线之后我才开始大规模调AT指令。下面这三个坑就是按时间顺序踩出来的。2. 坑一USB检测引脚把模组“吊”在半睡状态2.1 现象AT都配完了电流纹丝不动最先试的当然是经典流程ATQSCLK1开启睡眠模式。配置下去之后我用ATQSCLK?查过返回值确实是1配置没毛病。但电流一动不动还是11mA。我又试了ATCPSMS1开启PSM省电模式结果电流不仅没降反而在某些时段冲到12mA以上。当时甚至怀疑模组硬件有问题差一点就要申请售后换模组。还好忍住没换先在硬件设计手册上翻了一圈注意到一个不起眼的地方——USB接口检测引脚。移远模组虽然在我们产品里完全不使用USB但PCB上把USB的DP、DM、VBUS检测引脚都引出来做了测试点而且这些引脚全部是悬空状态。问题就出在这里。2.2 根因VUSB_DET悬空USB检测逻辑一直在“假忙”移远的EC21和EC200系列内部USB PHY有一个检测机制它会定期检查USB插入状态以此判断是否需要枚举出一个USB设备给电脑。这个检测机制在USB_VBUS_DET引脚悬空的时候会一直处于待命状态模组内部的某些电源域和时钟就没法彻底关掉。打个比方一个人本来已经躺下准备睡了但他总担心有人敲门所以每隔一会儿就爬起来看一眼猫眼。USB检测就是这个“爬起来看猫眼”的动作虽然每次动作耗电不大但架不住频繁而且它会导致某个关键电源域一直不关睡眠电流自然降不下来。我在硬件设计指南里看到明确要求如果不使用USB功能USB_VBUS_DET这个引脚不能悬空通常建议直接接地或者通过0欧电阻接到地。USB_DP和USB_DM这对差分线即使不用也尽量按照参考设计保留ESD器件并走线短接处理不要让它们像天线一样悬空拾取噪声。2.3 处理与实测结果当时PCB已经打样回来了没法改版我从模组底部的测试点飞了一根线把USB_VBUS_DET直接拉到地。上电重新量电流单独模组待机从11mA降到了8.5mA左右效果立竿见影。如果你还在原理图设计阶段记得把不用的USB相关引脚直接按手册要求处理掉。特别是VBUS检测脚不要因为“反正不焊USB座子”就任由它悬空这种隐性功耗最坑人数据手册翻不仔细根本发现不了。提示这里说的引脚名称在不同批次、不同型号的模组上可能叫VBUS_DET、USB_VBUS_DET或者VUSB_DET具体以自己手里那颗模组的Pin定义为准别照着我这个缩写去猜。3. 坑二ATQSCLK和ATCPSMS之间的关系没捋清3.1 两种省电模式的区别处理完USB引脚电流到了8.5mA离6mA还差一截。于是我开始仔细研究模组的两种省电模式发现之前乱开指令确实不对。移远EC21/EC200系列主要有两种省电机制CSI睡眠模式Modem Sleep对应ATQSCLK1模组射频仍然和网络保持连接会定期监听寻呼信道所以功耗在毫安级别实测大概6mA左右。优点是响应快主控随时可以通过DTR拉低或串口数据唤醒模组平台下行指令基本没有太大延迟。PSM省电模式Power Saving Mode对应ATCPSMS1模组会深度睡眠电流可以压到几十微安级别。代价是模组不监听网络寻呼平台想主动下发数据基本没门必须等终端自己醒来发起TAU或业务请求。我们的业务目标是整机休眠电流压到7mA以内本来CSI模式就够用了。但我一开始图省事把两个模式都开了而且PSM的定时器参数没有按项目实际场景配置结果适得其反。3.2 定时器配置错误导致周期性唤醒PSM模式下有两个核心定时器很多项目都栽在这里T3412周期性TAU定时器模组在PSM深度睡眠期间每隔多久醒来一次向网络做一次TAU更新。为了省电这个时间要尽量拉长比如几十分钟甚至几小时。T3324网络激活定时器网络释放RRC连接之后模组继续保持醒着状态的时间。只有T3324超时后模组才会真正进入PSM深度睡眠。要想快速入睡这个值必须调短常规做法是30秒到2分钟。我当时犯的错就是把T3324配置得太长模组每次上报完数据按照网络激活定时器一直保持醒着状态电流长时间停留在10mA以上根本没有进入PSM。而且我一开始根本没意识到ATCPSMS里那个字符串不是随便填的它的编码规则是3GPP的GPRS定时器编码高3位是单位低5位是数值。我最后实际使用的是这组参数ATCPSMS1,,,00000101,00011100简单解释一下00000101T3412单位取10分钟数值为5也就是50分钟左右做一次周期性TAU。00011100T3324单位取2秒数值为28也就是56秒后进入PSM。如果想更快进入PSM可以把T3324再调短一些比如30秒左右。但要注意运营商网络收到请求后不一定完全按你的值来网络侧有权修改最终值所以配置完一定要用ATCPSMS?读回来确认。3.3 网络侧不支持PSM怎么验证还有一个很现实的问题PSM不是“开了就一定生效”它需要网络侧配合。不同运营商、不同SIM卡套餐、不同频段下网络可能压根不接受PSM协商请求。排查方法很简单配置完PSM后执行ATCPSMS?如果返回的第一段mode不是1或者后面协商出来的定时器值和你给的对不上大概率是网络侧没兜住。还有一种情况模组虽然返回PSM启用但在一个周期内实际并没有进入深度睡眠这时候看电流波形最直观——如果电流每隔几十秒就出现一次脉冲那基本就是T3324超时设置太长或者网络侧强制把模组拽回IDLE状态。我当时也测试过把SIM卡换到另一家运营商网络同样的模组和固件PSM的进入情况确实不一样。所以如果你的产品要大规模铺开最好在目标运营商网络环境下做一次长期功耗验证别只看实验室里的SIM卡表现。4. 坑三主控UART引脚高阻和URC把模组反复唤醒4.1 排查过程单独模组电流正常一插主控就升到这一步单独模组的电流已经压到6mA了我很开心结果把主控板一连整机电流又弹回13mA。这说明问题不在模组配置而在主控和模组之间的交互。于是我用示波器同时抓模组的UART_RX引脚和电源电流波形发现一个非常典型的现场模组每隔几十毫秒就会从睡眠里被唤醒一下每次唤醒都会跑一段很小的“活动脉冲”然后电流回落到低位再被唤醒周而复始。平均下来整机电流自然就好不了。看UART_RX引脚的波形发现上面有大量高阻态下的电平漂移和毛刺。说白了就是模组误以为主控在向它发数据。4.2 UART电平与唤醒源问题根源在于主控MCU进入低功耗模式之前把UART_TX引脚配置成了高阻输入。UART协议里空闲状态是高电平而起始位是低电平。主控的TX一旦变成高阻线上只要有一点噪声就能把电平拉到低模组侧的UART_RX就会认为收到了一个“起始位”于是开始接收一个字节。哪怕这个字节是无效数据也会打断模组CPU的深度休眠让它爬起来做AT解析。这个坑特别隐蔽因为你在正常调试时根本不会把MCU置为高阻只有进入低功耗前的那一刻才会触发。我后来用示波器看毛刺的触发位置抓到确实是从主控休眠钩子函数执行之后开始的。处理办法有两条最好同时做主控在休眠前把UART_TX配置为推挽输出并强制输出高电平模拟UART空闲电平。硬件上在模组的UART_RX引脚加上拉电阻比如100kΩ到1.8V/3.3V电源防止电平漂移。DTR引脚也一样。移远的CSI睡眠模式DTR必须保持在高电平状态模组才允许进入休眠很多MCU的GPIO复位或休眠后默认是浮空输入等于DTR状态不确定模组会被卡在“不敢睡”的状态。4.3 完整的唤醒事件抑制方案处理好主控串口引脚整机电流降到了6.3mA左右。但还没完稳定观察了一段时间后发现电流曲线里偶尔还是会出现一些脉冲虽然不影响平均电流太多但我决定把唤醒源也捋一遍。蜂窝模组的唤醒源不只是UART数据还有URC主动上报消息。比如网络注册状态变化、SIM卡热插拔、TCP连接断开模组都会通过URC上报给主控这个上报动作本身就会唤醒CPU。如果你的设备保持TCP长连接服务器端一断开连接模组立刻产生URC电流就会跳一下。解决方案是尽量让业务层不要保持不必要的长连接。对于周期上报类设备数据传完就主动关闭连接不要一直挂着一个TCP链路。如果确实需要长连接也要把心跳间隔拉长并确认服务器端不会频繁断开连接。另外移远模组URC上报端口可以用AT指令配置有些固件支持ATQURCCFGurcport,uart有些支持其他参数视固件版本而定。业务上可以屏蔽掉那些不需要的URC。但注意像“模组已注册网络成功”这类关键通知还是要保留不然主控可能以为模组还醒着。这三个坑踩完之后整机休眠电流最终稳定在6.1mA左右示波器上的波形也干净了不少只有蜂窝网络配置好的周期性寻呼脉冲其他高频毛刺基本消失。5. 可以直接抄的AT指令流程和主控时序5.1 模块侧配置脚本下面这套流程是我在EC21和EC200S上实际跑过的模组状态为已注册LTE网络、已附着。建议每次开机都由主控主动下发一遍不要依赖模组内部保存NV配置因为不同固件对ATW的保存行为不一致容易出现“在实验室保存好的配置到现场启动就丢了”的情况。AT ATE0 ATI QSCLK1 ATQSCLK? QSCLK: 1 ATCPSMS1,,,00000101,00011100 ATCPSMS? CPSMS: 1,,,00000101,00011100 ATIFC0,0几个点说明一下ATQSCLK1是开启CSI睡眠模式这是整机6mA的主要来源必须配。ATCPSMS1,,,00000101,00011100是可选配置。如果你只需要CSI模式不追求PSM可以不配。但既然配了一定要用ATCPSMS?读回确认网络侧是否接受。ATIFC0,0是关闭硬件流控。如果我们主控代码里没有用RTS/CTS一定要关掉否则模组在睡眠状态下CTS状态的变化也可能引起主控中断两边配合不好就会反复唤醒。不要用ATCFUN0来做省电这个命令会关闭射频模组直接离开网络平台侧看到的是掉线数据链路断掉等你想唤醒的时候还得重新注册网络反而更耗电。这个脚本里没有加ATW我的建议是低功耗产品学习一下“启动时主动配置”的方式。模组开机到能正常拨号联网本身就需要几秒钟这段时间主控下发一串AT指令成本很低比依赖模组NV存储要稳得多。5.2 主控侧进入休眠与唤醒的时序AT指令配置只是模组侧的一半主控侧时序同样关键。下面是我的主控逻辑不同MCU平台大同小异。进入休眠的步骤业务上报完成主控关闭TCP/UDP连接如果业务允许。发送最后一条AT指令比如AT等待模组返回OK确保没有待处理的命令。主控把DTR引脚拉高UART_TX配置成推挽输出高电平关闭UART接收中断。主控执行自身低功耗进入流程等待外部定时器唤醒。模组进入CSI睡眠是需要条件的DTR保持高、UART无数据、无待上报URC。这几个条件不满足它就不会睡。从休眠中唤醒的步骤主控定时器到点先把DTR拉低。等待模组串口稳定通常延时50ms左右或者轮询直到模组能响应AT。恢复UART接收中断发送AT确认返回OK后再开始业务。这套时序里的一个关键点主控唤醒后不要马上发长命令模组从睡眠到完全清醒需要一点时间发太急会丢字节。有些模组固件可以用URC来提示主控“模组已唤醒”但我实测下来还是固定延时最省心。5.3 固件版本差异与兼容性建议EC21和EC200系列虽然AT指令大体一致但EC21是Cat.4模组EC200S是Cat.1模组固件版本不同省电相关的行为细节会有差异。最典型的就是ATCPSMS的参数解析和ATQSCLK的进入条件在新旧固件上表现出的细节稍有不同。不同固件在ATCPSMS上返回格式可能有差异比如有的版本只返回CPSMS: 1有的会把定时器都吐出来。这都不算异常关键看第一位的mode字段是不是1以及实际功耗是否符合预期。量产前最好锁定固件版本别让工厂刷写时随意升级。模组固件升级是好事但低功耗这种和网络协议强相关的行为升级后必须做一轮完整的功耗回归测试否则可能一个“修复”把休眠电流拉高几个毫安。6. 降下来的不只是6mA排查经验复盘6.1 能照抄的排查步骤清单如果你手头的模组也在“疑似休眠”状态下功耗偏高可以按下面这个顺序排查把模组单独拆出来只供电不开主控量模组自身的裸待机电流确认基线和异常程度。对照硬件设计手册把所有“不用就接地”的引脚过一遍特别是USB检测、SIM卡检测、GPIO控制这类容易漏的脚。用示波器电流探头或0.1Ω采样电阻录制完整的电流波形看是“高频毛刺”还是“周期性脉冲”从而区分是芯片内部检测、网络TAU还是外部唤醒源导致的问题。配置完AT指令后一定要读回查询确认模组真的按预期工作。ATCPSMS?不是摆设网络协商结果可能和你写的值完全不一样。最后才去怀疑固件和硬件不要上来就刷固件。我这次排查最大的教训就是前期不要一上来就调AT命令先解决“模组本身能不能睡”的问题再考虑“睡了之后有没有人打扰它”。6.2 设计阶段就能避掉这三个坑的原则这几个坑其实在设计阶段都能避开不一定非要等PCB打样回来再飞线解决。一个是原理图评审时把模组所有“不使用也必须定义电平”的引脚列出来。哪种引脚接死、哪种引脚通过上拉电阻接电平、哪种引脚悬空也没有影响一条条核对。第二个是主控和模组之间的每一根连线在低功耗状态下的电平都要有明确规划。UART_TX是高电平、DTR是高电平、如果不用RTS/CTS那就不要占用引脚或者统一拉到一个固定电平别让它们浮空。第三个是电源设计上模组VBAT脚的储能电容不能省。我调试过程中遇到过几次“模组休眠电流测量异常高”最后发现是采样电阻过大导致射频脉冲时电压跌落模组在反复重启不是休眠配置的问题。VBAT端的大电容不仅保证射频时电压不跌落对低功耗测量也是友好的。6.3 关于“降到6mA之后”的几点体会最后再聊点掏心窝的话。很多人以为低功耗就是“往模组发一条ATQSCLK1就完事了”实际做下来根本不是这么回事。模组能不能睡是模组和网络协商的结果模组睡了之后会不会被吵醒是主控和硬件设计决定的而电流能不能测准又是测量设备决定的。这中间任何一环出问题最后表现到电池寿命上可能都是几倍甚至几十倍的差距。我的设备现在稳定运行在两个月的周期上休眠电流6.1mA整机正常工作。如果你也在调移远EC21或者EC200系列的低功耗别急着怀疑模组先把引脚和测量工具搞定再回头看看AT指令流程是不是真的配对了。这一套走下来你大概率也能拿到那个“看起来有点低”的数字。