MTK平台待机功耗分析流程
很多功耗问题都是因为测试手法不对,列出一些常用场景功耗测试手法。
测试功耗数据之前,请先确认以下配置:
1、关闭 WIFI/BT/GPS,关闭数据连接,设置飞行模式。 (根据具体测试场景设置)
2、关闭 mobile log/modem log/net log,打开LOG会增加电流。注意:确认 /sdcard/mtklog (/data/mtklog) 中是否有 LOG 生成,确定关闭成功。
3、确认各个模块是否已经正常工作,各个模块都会影响功耗,需要在模块工作 OK 之后再测试功耗问题。
4、测试将所有第三方 APK 删除,排除第三方 APK 问题。
各场景测试手法:
测试场景 测试方法 备注
1、设置飞行模式,关闭WIFI/BT/GPS,关闭数据连接
2、关闭mobile log、modem log、net log
3、按power 键灭屏,灭屏5分钟后,开始测试电流,测试时间5 ~ 10分钟 电流异常需要提供mobile log
4、关闭mobile log、modem log、net log
5、按power 键灭屏,灭屏5分钟后,开始测试电流,测试时间5 ~ 10分钟 实网待机需要先确认网络问题及SIM卡问题:
6、用其他对比机是否有同样问题
7、同一手机在其他地点是否有问题
8、其他SIM卡是否有同样问题
双SIM卡实网待机
单SIM卡实网待机 + 数据连接
1、关闭WIFI/BT/GPS
2、关闭mobile log、modem log、net log
3、按power 键灭屏,灭屏5分钟后,开始测试电流,测试时间5 ~ 10分钟
单SIM卡待机 + WIFI/BT/GPS
1、关闭数据连接
2、关闭mobile log、modem log、net log
3、按power 键灭屏,灭屏5分钟后,开始测试电流,测试时间5 ~ 10分钟
通话电流
1、关闭WIFI/BT/GPS,关闭数据连接
2、关闭mobile log、modem log、net log
3、通话后灭屏,等待2分钟开始测试电流,测试时间5分钟 电流异常需要提供mobile log
home界面idle电流
1、关闭WIFI/BT/GPS,关闭数据连接
2、关闭mobile log、modem log、net log
3、拔掉SIM卡、SD卡
4、保持在home界面,不开任何应用,设置自动灭屏时间为30分钟
5、保持默认背光
6、等待5分钟后开始测试电流,测试时间5~10分钟 home界面电流和背光、TP、LCM有关,需要先确认去掉背光、TP、LCM电流,请看下一场景
home界面idle + 去掉背光和TP
1、关闭WIFI/BT/GPS,关闭数据连接
2、关闭mobile log、modem log、net log
3、拔掉SIM卡、SD卡
4、保持在home界面,不开任何应用,设置自动灭屏时间为30分钟
5、拔掉LCM和TP
6、等待5分钟后开始测试电流,测试时间5~10分钟 home界面电流异常需要抓CPU信息,请参考FAQ04008,需要同时提供mobile log
FM电流 (耳机模式)
1、关闭WIFI/BT/GPS,关闭数据连接
2、关闭mobile log、modem log、net log
3、打开FM后灭屏,等待2分钟后开始测试电流,测试时间5分钟 1、FM SPEAKER模式 以及 I2S 通道电流都会偏大,是正常的。
4、FM电流异常需要抓deepidle数据,请参考 FAQ04519,需要同时提供mobile log
BT传输数据
1、关闭WIFI/GPS,关闭数据连接
2、关闭mobile log、modem log、net log
3、传输5M大小文件,灭屏,测试电流
4、BT传输电流异常需要抓CPU信息,请参考FAQ04008,需要同时提供mobile log
Audio – MP3 Play back (headset)
1、设置飞行模式
2、关闭mobile log、modem log、net log
3、播放mp3,灭屏,灭屏后等待2分钟,开始测试电流,测试时间2分钟
4、播放MP3和SD卡及音频文件有关,需要换SD卡及音频文件测试
5、MP3电流异常需要抓deepidle数据,请参考 FAQ04519,需要同时提供mobile log
Video – MP4 (720P) HW mode
1、设置飞行模式
2、关闭mobile log、modem log、net log
3、播放video,播放后等待2分钟,开始测试电流,测试时间2分钟
4、播放video电流和背光、TP、LCM有关,需要先确认去掉背光、TP、LCM电流 5、播放video和播放器和视频文件有关,需要使用默认播放器及MTK提供的视频文件
6、播放video电流异常需要抓CPU信息,请参考FAQ04008,需要同时提供mobile log
Video – MP4 (1080P) HW mode
Video – H.264 (720P) HW mode
Video – H.264 (1080P) HW mode
Camera – Video Record H264 (720 P)
Camera – Preview (720 P)
1、设置飞行模式
2、关闭mobile log、modem log、net log
3、打开preview,等待2分钟,开始测试电流,测试时间2分钟
4、camera电流和拍摄场景及camera相关设置有关,对比测试时请尽量保持相同拍摄场景以及相同配置。
5、preview电流异常需要抓CPU信息,请参考FAQ04008,需要同时提供mobile log
目前我们分析的功耗问题主要是待机低电流或者待机平均电流问题。
造成待机底电流偏大原因基本可以分为3类: 各个外设模块休眠漏电或未休眠,GPIO/subsys/pll/clock口漏电,wakelock导致无法休眠,modem无法休眠
关闭飞行模式测试待机底电流,排除是否modem未休眠,首先确定是AP 还是modem。
modem暂无系统的分析方法。
下面是AP的分析流程
外设模块分析主要还是靠硬件上一一移除,然后查看移除哪个模块后底电流有降下来,然后确定到时哪个模块漏电 .如休眠时将TP camera LCD 逐一移除来确定排查。
找到模块后再取分析代码来解决。
AP suspend状态下,会因为GPIO配置不当,subsys/pll/clock没关,或者其他的原因造成26M没关,而导致底电流升高;
这种情况,可以从kernel log中找到一些端倪,以确定进一步分析的方向
[6589/6582/6592/6595/6795] 查找关键字“PWR_STATUS”,[7:0]对应每个bit对应一个subsys 如果bit为1,代表这个子系统没关
echo 1 > /sys/module/mt_sleep/parameters/slp_ck26m_on
echo 1 > /sys/module/mt_sleep/parameters/slp_dump_regs
每个bit的定义可以看mt_spm_mtcmos.c
比如:#define MD1_PWR_STA_MASK (0x1 << 0)
[6732/6752/6735/6753] 查找关键字“slp_check_pm_mtcmos_pll” 如果有子系统没关,下一行可以看到类似下面的信息: [Power/clkmgr] SYS_AUD: on
然后再往下看,就是各子系统的dump信息,以aud子系统为例,找到SYS_AUD对应的部分,详细解释如下: cnt不等于0表示这个clock没关 后面每一个括号内(可能有多个)是这个clock的其中一个user的信息 “audio”是使用clock的user的名字,代码里传入的参数 “15”表示open clock的次数, “14”表示close clock的次数,两者不一样的话说明“audio”这个user使用这个clock有问题
[06][CG_AUDIO]*
[02]state=1, cnt=1 (AUDIO,15,14)
[08]state=0, cnt=0 (AUDIO,8,8)
[09]state=0, cnt=0 (AUDIO,8,8)
[18]state=0, cnt=0 (AUDIO,8,8)
[19]state=0, cnt=0 (AUDIO,8,8)
默认是关闭的,需要用下面的命令打开
echo 1 > /sys/module/mt_sleep/parameters/slp_dump_gpio
然后在kernel log里就可以看到类似下面的信息: PIN: [MODE] [PULL_SEL] [DIN] [DOUT] [PULL EN] [DIR] [IES]
对一下正常更异常的情况就会有帮助
重点关注[mode][DIR][PULL_SEL],其他栏位的状态即使改变很多情况下也是正常的
有些平台本身这块代码是注释掉的,需要更改代码才可以,搜索slp_dump_gpio可以找到相关代码
搜索关键字“debug_flag”,跟wake up by在同一行, bit[3:2]可以显示26M有没有关闭过,
如果bit[3:2]=0b’11,说明sleep时26M正常关闭;
如果bit[3:2]=0b’00,说明sleep时26M一直没关;
Kernel或者system持有wakelock会导致系统无法进入深度休眠,直接导致待机底电流偏高
【STEP1-找KERNEL层和USER层的WAKELOCK】
使用命令,查看kernel或者上层的wakelock
cat /proc/wakelock
dumpsys power`
相关weaklock都会被打印出来
【STEP2-找USER层的WAKESOURCE】
中间层申请的weaklock不会再上面显示,必须使用命令去查看weaksource的脚本去抓取这两种信息,脚本源码如下:
#!/system/bin/sh
echo "Start monitor power..." > /sdcard/power.txt
while echo "====================================================================================" >> /sdcard/power.txt
do
date >> /sdcard/power.txt
echo "**********dumpsys power**********" >> /sdcard/power.txt
dumpsys power | cat >> /sdcard/power.txt
echo " >> /sdcard/power.txt
echo "**********cat /sys/kernel/debug/wakeup_sources**********" >> /sdcard/power.txt
cat /sys/kernel/debug/wakeup_sources >> /sdcard/power.txt
echo " >> /sdcard/power.txt
sleep 10
done
[FAQ09542][POWER]待机电流问题,如何查找WAKELOCK
【使用说明】
(1) 以下是列出的整个按键唤醒的log关键点,每条都有粗体字说明其含义以及该注意的关键字;
(2) 红色的是kernel log,其他都是main log;
(3) 一条一条依次检查,直到如果发现某条log找不到,那问题就出在这个地方;
(4) 仅限于JB2之后的Android版本,JB2之前流程相对比较简单;
kernel-Check Point【1】:按键中断
<5>[ 78.721504] 1)[Power/PMIC] [pwrkey_int_handler] Press pwrkey
——————————————————————————————————————————————————– Check Point【2】:上层收到按键事件 01-09 03:37:40.102 513 561 D
WindowManager: interceptKeyTq keycode=26
——————————————————————————————————————————————————– Check Point【3】:PMS的wakeUp被调用 01-09 03:37:40.171 513 531 D
PowerManager_performance: wakeUpNoUpdateLocked: eventTime=78826
——————————————————————————————————————————————————– Check Point【4】:发出MSG_BROADCAST 01-09 03:37:40.171 513 531 D
PowerManagerNotifier: onWakeUpStarted
——————————————————————————————————————————————————– Check Point【5】:发出第一个MSG_UPDATE_POWER_STATE 01-09 03:37:40.174 513
531 D PowerManagerDisplayController: sendMessage
——————————————————————————————————————————————————– Check Point【6】:收到并处理MSG_BROADCAST,并且状态是从2变到1 01-09 03:37:40.194 513
530 D PowerManagerNotifier: sendNextBroadcast,
mBroadcastedPowerState=2, mActualPowerState=1
——————————————————————————————————————————————————– Check Point【7】:开始绘制keyguard的流程,发出NOTIFY_SCREEN_ON,等windowToken 01-09
03:37:40.217 513 530 D KeyguardViewMediator: notifyScreenOnLocked
——————————————————————————————————————————————————– Check Point【8】:收到并处理NOTIFY_SCREEN_ON 01-09 03:37:40.224 513 531 D
KeyguardViewMediator: handleNotifyScreenOn
——————————————————————————————————————————————————– Check Point【9】:完成绘制keyguard,拿到windowToken 01-09 03:37:40.370 513
531 I WindowManager: Lock screen displayed
——————————————————————————————————————————————————– Check Point【10】:调用回调函数mSceenOnListener,解除Screen on
Blocker,mNestCount必须是0 01-09 03:37:40.371 513 531 D
PowerManagerService: Screen on unblocked: mNestCount=0
——————————————————————————————————————————————————– Check Point【11】:处理第一个MSG_UPDATE_POWER_STATE,这里会第一次scheduleScreenUpdate
01-09 03:37:40.254 513 546 D PowerManagerDisplayState:
setScreenOn: on=true
——————————————————————————————————————————————————– Check Point【12】:第一次执行scheduleScreenUpdate,进入setState 01-09
03:37:40.330 513 546 D PowerManagerDisplayState: Requesting new
screen state: on=true, backlight=0
Check Point【13】:发出第二个MSG_UPDATE_POWER_STATE 01-09 03:37:40.334 513 546 D PowerManagerDisplayController: sendMessage.
——————————————————————————————————————————————————– Check Point【14】:第一次执行mTask, on跟onChanged 必须都是true 01-09 03:37:40.334
513 546 D PowerManagerDisplayState: mTask: on = true, onChanged =
true, backlightChanged = false
——————————————————————————————————————————————————– kernel-Check Point【15】:进入unblankAllDisplays,开始底层late_resume流程 01-09
03:37:40.334 513 546 D PowerManagerService: unblankAllDisplays in
…
——————————————————————————————————————————————————– Check Point【16】:底层late_resume流程结束 01-09 03:37:40.673 513 546 D
PowerManagerService-JNI: Excessive delay in autosuspend_disable()
while turning screen on: 337ms
——————————————————————————————————————————————————– Check Point【17】:unblankAllDisplays流程结束 01-09 03:37:40.701 513 546
D PowerManager_performance: unblankAllDisplays out …
——————————————————————————————————————————————————– Check Point【18】:处理第二个MSG_UPDATE_POWER_STATE 01-09 03:37:40.702 513
546 D PowerManagerDisplayController: setScreenOn true
——————————————————————————————————————————————————– Check Point【19】:前面的Screen On Blocker被解除,才会调用这里 01-09 03:37:40.702
513 546 D PowerManagerDisplayController: Unblocked screen on after
447 ms
——————————————————————————————————————————————————– Check
Point【20】:设置ElectronBeamLevel,值不为0才能点亮背光,并且这里会第二次scheduleScreenUpdate
01-09 03:37:40.704 513 546 D PowerManagerDisplayState:
setElectronBeamLevel: level=1.0
——————————————————————————————————————————————————– Check Point【21】:第二次执行scheduleScreenUpdate,进入setState,注意backlight值不为0
01-09 03:37:40.718 513 546 D PowerManagerDisplayState: Requesting
new screen state: on=true, backlight=86,
——————————————————————————————————————————————————– Check Point【22】:第二次执行mTask,backlightChanged必须是true 01-09 03:37:40.721
513 546 D PowerManagerDisplayState: mTask: on = true, onChanged =
false, backlightChanged = true
——————————————————————————————————————————————————– Check Point【23】:调用light service,写backlight节点,light 0表示backlight 01-09
03:37:40.721 513 546 D LightsService: setLight_native: light=0,
colorARGB=0xff565656, flashMode=0,
——————————————————————————————————————————————————– kernel-Check Point【24】:驱动底层背光生效 <4>[ 79.447236]
(1)[546:PowerManagerSer]mt65xx_leds_set_cust: set brightness,
name:lcd-backlight, mode:6, level:86
[FAQ11906][LTE功耗]6582/92与6290连接的UART IO漏电
[DESCRIPTION]
<5>[ 78.721504] 1)[Power/PMIC] [pwrkey_int_handler] Press pwrkey
——————————————————————————————————————————————————– Check Point【2】:上层收到按键事件 01-09 03:37:40.102 513 561 D
WindowManager: interceptKeyTq keycode=26
——————————————————————————————————————————————————– Check Point【3】:PMS的wakeUp被调用 01-09 03:37:40.171 513 531 D
PowerManager_performance: wakeUpNoUpdateLocked: eventTime=78826
——————————————————————————————————————————————————– Check Point【4】:发出MSG_BROADCAST 01-09 03:37:40.171 513 531 D
PowerManagerNotifier: onWakeUpStarted
——————————————————————————————————————————————————– Check Point【5】:发出第一个MSG_UPDATE_POWER_STATE 01-09 03:37:40.174 513
531 D PowerManagerDisplayController: sendMessage
——————————————————————————————————————————————————– Check Point【6】:收到并处理MSG_BROADCAST,并且状态是从2变到1 01-09 03:37:40.194 513
530 D PowerManagerNotifier: sendNextBroadcast,
mBroadcastedPowerState=2, mActualPowerState=1
——————————————————————————————————————————————————– Check Point【7】:开始绘制keyguard的流程,发出NOTIFY_SCREEN_ON,等windowToken 01-09
03:37:40.217 513 530 D KeyguardViewMediator: notifyScreenOnLocked
——————————————————————————————————————————————————– Check Point【8】:收到并处理NOTIFY_SCREEN_ON 01-09 03:37:40.224 513 531 D
KeyguardViewMediator: handleNotifyScreenOn
——————————————————————————————————————————————————– Check Point【9】:完成绘制keyguard,拿到windowToken 01-09 03:37:40.370 513
531 I WindowManager: Lock screen displayed
——————————————————————————————————————————————————– Check Point【10】:调用回调函数mSceenOnListener,解除Screen on
Blocker,mNestCount必须是0 01-09 03:37:40.371 513 531 D
PowerManagerService: Screen on unblocked: mNestCount=0
——————————————————————————————————————————————————– Check Point【11】:处理第一个MSG_UPDATE_POWER_STATE,这里会第一次scheduleScreenUpdate
01-09 03:37:40.254 513 546 D PowerManagerDisplayState:
setScreenOn: on=true
——————————————————————————————————————————————————– Check Point【12】:第一次执行scheduleScreenUpdate,进入setState 01-09
03:37:40.330 513 546 D PowerManagerDisplayState: Requesting new
screen state: on=true, backlight=0
Check Point【13】:发出第二个MSG_UPDATE_POWER_STATE 01-09 03:37:40.334 513 546 D PowerManagerDisplayController: sendMessage.
——————————————————————————————————————————————————– Check Point【14】:第一次执行mTask, on跟onChanged 必须都是true 01-09 03:37:40.334
513 546 D PowerManagerDisplayState: mTask: on = true, onChanged =
true, backlightChanged = false
——————————————————————————————————————————————————– kernel-Check Point【15】:进入unblankAllDisplays,开始底层late_resume流程 01-09
03:37:40.334 513 546 D PowerManagerService: unblankAllDisplays in
…
——————————————————————————————————————————————————– Check Point【16】:底层late_resume流程结束 01-09 03:37:40.673 513 546 D
PowerManagerService-JNI: Excessive delay in autosuspend_disable()
while turning screen on: 337ms
——————————————————————————————————————————————————– Check Point【17】:unblankAllDisplays流程结束 01-09 03:37:40.701 513 546
D PowerManager_performance: unblankAllDisplays out …
——————————————————————————————————————————————————– Check Point【18】:处理第二个MSG_UPDATE_POWER_STATE 01-09 03:37:40.702 513
546 D PowerManagerDisplayController: setScreenOn true
——————————————————————————————————————————————————– Check Point【19】:前面的Screen On Blocker被解除,才会调用这里 01-09 03:37:40.702
513 546 D PowerManagerDisplayController: Unblocked screen on after
447 ms
——————————————————————————————————————————————————– Check
Point【20】:设置ElectronBeamLevel,值不为0才能点亮背光,并且这里会第二次scheduleScreenUpdate
01-09 03:37:40.704 513 546 D PowerManagerDisplayState:
setElectronBeamLevel: level=1.0
——————————————————————————————————————————————————– Check Point【21】:第二次执行scheduleScreenUpdate,进入setState,注意backlight值不为0
01-09 03:37:40.718 513 546 D PowerManagerDisplayState: Requesting
new screen state: on=true, backlight=86,
——————————————————————————————————————————————————– Check Point【22】:第二次执行mTask,backlightChanged必须是true 01-09 03:37:40.721
513 546 D PowerManagerDisplayState: mTask: on = true, onChanged =
false, backlightChanged = true
——————————————————————————————————————————————————– Check Point【23】:调用light service,写backlight节点,light 0表示backlight 01-09
03:37:40.721 513 546 D LightsService: setLight_native: light=0,
colorARGB=0xff565656, flashMode=0,
——————————————————————————————————————————————————– kernel-Check Point【24】:驱动底层背光生效 <4>[ 79.447236]
(1)[546:PowerManagerSer]mt65xx_leds_set_cust: set brightness,
name:lcd-backlight, mode:6, level:86
[FAQ11906][LTE功耗]6582/92与6290连接的UART IO漏电
[DESCRIPTION]
现象:fly mode下会有几mA的漏电,而且非常大的可能关闭fly mode底电流反而会降一些;如果能断开6290/65X2之间的UART连线,可以看到电流恢复正常
原因:fly mode模式下,正常的话,6339/6290是没有电的,因此6290上的UART电平状态就会是低电平;如果AP侧跟6290连接的UART 配置是高电平就会引起漏电。
注意:6582+6290跟6592+6290的情况有所不同,两种项目都可能产生这个问题,但是具体的错误点不一样,原因是6582 UART代码中在关闭modem时会去切换GPIO的pull状态为pull enable / pull low,而6592没有这段代码;因此6582+6290需要关注的是dws中UART pin的var Name一定要配,否则软件就不会有动作;而6592+6290要关注的不仅是var Name,还有前面的pull设定
[SOLUTION]
解决方案: Release出去的配置都是对的,只是客户有可能根据以往的经验把UART配置成pull enable / pull high,就可能产生问题,如果真的出现这个问题,那么请按照以下方式正确配置UART:
特别注意:硬件原理图上的UART2对应的是dws中的UART3,千万不要错位
[FAQ11917][LTE功耗] 实网待机功耗测试注意AUTO MODE的影响
【问题类型1】————————————————————————————-
现象:连CMU500,4G待机电流200mA+,一直下不来,4G实网下反而正常
原因:CMU500的仪器默认配置了 “keep RRC connection”,会导致modem一直处于工作状态 注意:8820C 默认没有开这个配置,所以没问题
解决方案: 去掉仪器上“keep RRC connection”的选项,如果不知道怎么做,请联系仪器厂商
【问题类型2】————————————————————————————-
现象:连仪器, 4G待机电流70mA+,一直下不来,4G实网下反而正常
Kernel log中可以很规律地看到固定每隔10s或者7s左右被EINT 7(LTE)唤醒 原因:没有勾选“DRX disconnect”
解决方案: 勾选“ RX disconnect”,如果不知道怎么做,请联系仪器厂商