Android 功耗（4）---MTK平臺待機功耗分析流程-有解無憂

MTK平臺待機功耗分析流程

1.目的

2.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卡是否有同樣問題

電流例外需要提供mobile log

雙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.功耗問題分析流程

目前我們分析的功耗問題主要是待機低電流或者待機平均電流問題，

造成待機底電流偏大原因基本可以分為3類: 各個外設模塊休眠漏電或未休眠，GPIO/subsys/pll/clock口漏電，wakelock導致無法休眠，modem無法休眠

關閉飛行模式測驗待機底電流，排除是否modem未休眠，首先確定是AP 還是modem，

modem暫無系統的分析方法，

下面是AP的分析流程

3.1 外設模塊分析方法

外設模塊分析主要還是靠硬體上一一移除，然后查看移除哪個模塊后底電流有降下來，然后確定到時哪個模塊漏電 .如休眠時將TP camera LCD 逐一移除來確定排查，

找到模塊后再取分析代碼來解決，

3.2 GPIO/SUBSYS/PLL/CLOCK分析方法

AP suspend狀態下，會因為GPIO配置不當，subsys/pll/clock沒關，或者其他的原因造成26M沒關，而導致底電流升高；

這種情況，可以從kernel log中找到一些端倪，以確定進一步分析的方向

【3.2.1】查找沒有關閉的SUBSYS/CLOCK/PLL

[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)

【3.2.2】查看GPIO的狀態

默認是關閉的，需要用下面的命令打開

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可以找到相關代碼

【3.2.3】查看26M CLOCK是否關閉

搜索關鍵字“debug_flag”，跟wake up by在同一行，
bit[3:2]可以顯示26M有沒有關閉過，

如果bit[3:2]=0b’11，說明sleep時26M正常關閉；

如果bit[3:2]=0b’00，說明sleep時26M一直沒關；

如果發生這種case，需要case by case去看
另外，如果前面是wake up by GPU，請忽略這行log資訊（deepdile狀態，不是suspend狀態）

3.3 WAKELOCK 分析

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

4.FAQ

[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]

現象：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”，如果不知道怎么做，請聯系儀器廠商

轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/213.html

標籤：嵌入式

上一篇：《痞子衡嵌入式半月刊》第 15 期

下一篇：MRAM與常用計算機記憶體的性能比較