关于MTK平台CC相关的Log查询

关于MTK平台CC相关的Log查询

在外场问题中,经常会出现通话相关的故障。这里简单总结一下通话相关log的分析点:

主叫方:主叫方,是指主动发起通话的一方。

  1. 初步定位问题,

用户发起通话时,AP端的拨号指令最终会通过AT到达modem,所以可以通过查看radio_log中相关的拨号AT指令来判断问题出现在AP还是BP。

11-04 11:06:06.397   484   487 D AT      : AT> ATD13711349140;

11-04 11:06:06.397   484   487 D AT      : ATD13711349140;

如果出现问题的时间点没有对应的ATD指令,可以推断AP端没有向Modem发送拨号指令,基本可以断定是AP的问题;如果ATD已经下发,可以将问题归属到modem端。

  • AP端,

定位AP端的问题主要根据main_log来跟踪代码的执行流程。

在MTK Androd平台上大致的执行流程如下:

OutgoingCallBroadcast.java

PhoneGlobals.getInstance().callController.placeCall(intent);

CallController.java

CallStatusCode status = placeCallInternal(intent);

PhoneUtils.placeCall (***);

PhoneUtils.java

Connection = app.mCM.dial(phone, numberToDial);

CallManager.java

Result = basePhone.dial(dialString);

GsmPhone.java

Return mCT.dial(newDialString, uusInfo);

cm.dial(*****,  obtainCompleteMessage(EVENT_DIAL_CALL_RESULT));

此后,AP端通过RIL.java将拨号发送至libril,最终到达modem。

  • Modem端,

Modem这边的问题主要通过modem log来排查:

关于MTK平台CC相关的Log查询

图表 A  MT端正常Modem log示例

PS:可以通过AT+ECPI来查看当前的CC的状态。其中,各字段的值可以参考MTK  AT文档。

被叫方:

1、  粗步定位:

Modem接收到寻呼消息时,会通过检测TMSI来判断是否是对于自身的寻呼。如果是,对其进行响应,并向AP上报RING。

11-04 10:54:09.154   482   497 D AT      :

11-04 10:54:09.154   482   497 D AT      : RING

11-04 10:54:09.154   482   497 D AT      : AT< RING

11-04 10:54:09.154   482   497 D AT      : RIL_URC_READER:RING

11-04 10:54:09.154   482   497 D AT      : RIL_URC_READER Enter processLine

11-04 10:54:09.154   482   497 D RIL     : Nw URC:RING

11-04 10:54:09.154   482   497 D RIL     : receiving RING!!!!!!

11-04 10:54:09.154   482   497 D RIL     : receiving first RING!!!!!!

  • AP端,

RIL.java中接收到下层上报的RING信息之后,会通知CallTracker.java。此中,会将来电信息通知到在其中注册的Handler。

一般而言,这期间一般没有什么问题。

  • Modem端,

正常MT端的modem log如下:

关于MTK平台CC相关的Log查询

图表 B  MO端正常Modem log示例

通常的问题有如下:

l  没有接收到Paging消息:

[NW->MS] RRC__PAGING_TYPE1

[3G SMART PAGING] Smart Paging Enable = 1,Level2 Enable = 0,Learning CN Domain = 2,SmartPaging_Available = 0,is_Risk_RNC = 1

PGD_TMSI: 4B 54 B 1E

Paging record 2 is for this UE.

CN Paging: CS_DOMAIN, TMSI_TYPE, RRC_PagingCause_terminatingConversationalCall

RRCE: Starts the timer RRCE_PendingPagingTmr_TIMER_ID for 3 seconds and 0 milliseconds

MSG_ID_RATCM_RRCE_PAGE_IND

MSG_ID_MM_RATCM_PAGE_IND

MS is paged with TMSI_TYPE

[MS->NW] MM__PAGING_RESPONSE

以上是UE对Paging的正常响应,可以通过参看MM__PAGING_RESPONSE消息来检测UE是否对问题时间点的寻呼进行响应。

PS: TMSI是MT与网络交互的过程中,网络给MT发送的一个临时的识别码。modem log中可以查看到:

[RRM]  TMSI value 4b54b1e

上一篇:基于Linux 3.0.8 Samsung FIMC(S5PV210) 的摄像头驱动框架解读(一)


下一篇:将php网站移到CentOS 6.7上[二]:将网站部署到服务器上