MTK功能机平台死机原因调试方法

  • 2017-09-20
  • 919
  • 0
  • 2

最近在做IOT模块,用的MTK的方案,有时候会发现自己写的程序跑着跑着就崩掉了,这时候如果用catcher连上去调试,崩溃的时候catcher会打印调用堆栈:

116 Trace 8105 19:36:48:582 2017/09/19 MOD_NIL TRACE_ERROR 0x100278C4
117 Trace 8109 19:36:48:582 2017/09/19 MOD_NIL TRACE_ERROR 0x1001F490
118 Trace 8112 19:36:48:613 2017/09/19 MOD_NIL TRACE_ERROR 0xF01CAFC6
119 Trace 8115 19:36:48:629 2017/09/19 MOD_NIL TRACE_ERROR 0xF013F6CC
120 Trace 8117 19:36:48:629 2017/09/19 MOD_NIL TRACE_ERROR 0xF012AC70
121 Trace 8121 19:36:48:660 2017/09/19 MOD_NIL TRACE_ERROR 0xF0124C00
122 Trace 8123 19:36:48:675 2017/09/19 MOD_NIL TRACE_ERROR 0xF011BF98
123 Trace 8127 19:36:48:675 2017/09/19 MOD_NIL TRACE_ERROR 0x10013128
124 Trace 8130 19:36:48:707 2017/09/19 MOD_NIL TRACE_ERROR 0x10031B10
125 Trace 8134 19:36:48:722 2017/09/19 MOD_NIL TRACE_ERROR 0x00000000

这个堆栈怎么用呢,主要是从上往下看,最顶上那个是最后调用的函数,但是只有地址我们怎么确定是哪个函数呢,这个就要通过我们编译出来的的符号文件来看了,在编译出来的build文件夹下面,会有个类似MTK03D_M2M_11C_PCB01_gprs_MT6261_S00.sym这种的符号文件,我们打开可以看到有地址对应的函数名称,我们从出错调用栈从上到下查询,首先我们看0x100278C4,如果搜索不到,可以把地址+1,因为有可能这个函数是Thumb指令编译的,我们搜索0x100278C5可以找到:

0x100278c5 T tst_log_primitive_without_filter_check

其中那个T表示这个是Thumb指令的函数,这个函数是打印系统最后出错日志的函数,对我们没帮助,所以继续往下,看0x1001F490,可以找到

0x1001F491 T time

可以看到出错原因是因为调用了MTK平台废弃的系统函数time引起的,继续找是谁调用了这个函数,再看地址0xF01CAFC6,可以找到:

 
0xF01CAFC7 T LowResTimer 

这时候就找到我有问题的用户函数了,把time(0)用系统的app_getcurrtime()替换,问题解决。

评论

还没有任何评论,你来说两句吧

发表评论

*

浙ICP备16016405号-2
浙公网安备 33010602007544号