mtk平台软件调试方法与技巧

1、前篇文章介绍了手机调试的TRACE技巧,MTK手机调试是比较简单的,除了打TRACE,找ASSERT,分析DUMP外,剩下的就是经验了,有经验的人看到现象就能猜到问题出在什么地方,简单看一下TRACE只是为了确认自己的猜测.初涉此道的朋友往往需要时间,慢慢积累经验.要达到熟练,就需要有空的时候多读多研究代码.熟练的掌握了代码,解决问题就会熟能生巧. MTK的模拟器调试说没技巧也是对的,说有技巧也不错.因为模拟器的技术与其说是MTK经验,不如说是VC经验. 由于模拟器能在没有样机的情况做大量的UI方面的开发,同时模拟器具有快捷,所见即所改等优点,因此,受到很多开发老手的青睐.熟练掌握模拟器使用技

2、巧,对于提高工作效率,节省资源具有很积极的意义. 工欲善其事,必先利其器.欲了解模拟器调试,就要先了解VC使用.VC调试过程中经常使用的快捷键如下: vc+断点的使用：按F9（设置断点），F5调试，F10单步调试，shift+F5退出调试F10单语句执行，F11单指令执行，Ctrl+F10执行至光标处；F9按行设置/取消断点, Alt+F9可按行，按数据或按消息设置断点；调试时，按Alt+3打开跟踪窗口，Alt+4打开变量窗口，Alt+5打开寄存器窗口，Alt+6打开内存窗口，Alt+7打开堆栈窗口，Alt+8打开汇编指令窗口； 1.只要你有源代码,拥有一个模拟器是一件很容易的事.当然,有些情

3、况下,这对于初入MTK的人来说,也是困难的,特别是在一些代码管理不善,公司人员众多,员工流动频繁的公司,你永远想象不出他们的代码会有多糟.不过一般情况下,我到一个新公司,都会试着去使用他们的代码编译得到模拟器,不管他们的代码多么糟,我总能快速的编出模拟器来.只要三个步骤: a.在编译模拟器前请关掉所有SP的宏,这是很重要的,很多SP都不提供在模拟器下运行的库,所以一个项目SP越多,在模拟器下,他无法识别的函数也会越多 b.在编译过程中遇到错误,可以把所有与显示无关的代码全部使用#ifdef WIN32宏括起来,把所有不认识的类型使用typedef int xxx;重定义.把一些不能识别的宏定义

4、使用WIN32括起来重定义一下 c.在生成MODIS时,会遇到大量不认识的函数,如果少于50个,全部建成void xxx(类型的空函数.如果多于一百个,尝试查找这些函数的来源,如果是相关SP的,就再次补充关掉相关SP.当然如果你不怕麻烦,也可以把这一百个函数建成空函数.一般来说,把所有第三方功能和与MTK无关的功能关掉的话,不能识别的函数一般不会超过十个. 经过这样三步,一般情况下你都能得一个差不多可以使用的模拟器.有了模拟器,你就可以进行下面的工作了.如果你仍然无法获得模拟器,建议咨询你的项目领导,如果你的领导也无法解决,说明这个软件组是 个地方代码出来问题,从而找到解决方法.有关此类的函数

5、太多,不一一举例. C.断点可以用来研究全局变量被意外修改问题,我们打开断点对话框,选第二个选项卡,把需要跟踪的变量打进去,当每次变量变化时,VC都会停下来等我们调试.也可以设置条件,假设某全局变量U8 g_XXX, 其值等于5时会出错,但你不知道这个全局变量在什么地方被什么代码赋值为5,这时就可以设置数据断点,在第二选项卡上面的对话框里输入g_XXX = 5,当其值为5时就会停下来. d.研究代码也可以使用断点,比如MTK代码里使用有很多函数指针封装,例如gui_print_text指针,你想研究他的实现过程,但由于是指针,你找不到他的函数体,这时你就可以在数据断点中,把指针gui_prin

6、t_text输入进去,重启模拟器时,他就会定位到ui_print_text函数处. 兹举这四个例子吧,断点可以使用于你需要调试的任何场合,但过多的断点会影响你查找问题的速度,等熟练使用时,就可以有针对性的对某些变量和函数打断点以解决问题.这是一个积累的过程 3.堆栈调试,Alt+7打开堆栈窗口.该窗口中我们可以看到函数之间的调用关系,这是十分有用的,一般都是结合断点使用,定位BUG和研究代码十分有用.由于上面有例子,这里就不举了 4.变量窗口,Alt+4打开变量窗口,该窗口会自动显示断点代码处使用的变量及其值,阅读代码解决BUG时使用,单步执行时经常参考该窗口数据 5.WATCH窗口,按Alt

7、+3打开,由于变量窗口自动显示的变量有时不是我们需要的,这时就可以把我们需要查看的变量拖放到该窗口研究,结合断点使用,并且这里也支持表达式取值,真是太棒了. 6.内存窗口,Alt+6打开内存窗口,内存窗口可以显示一块内存的内容,这是很有用的,比如我们要跟踪短信内容,有一个短信内容的指针,把该指针输入WATCH窗口,只能看到该指针指向的第一个值,要看其他的,会很麻烦,你只能输入表达式,但你把该指针输入内存窗口,就不必这样费事了 7.Alt+8打开汇编指令窗口,这个窗口用处不是很大,学习汇编的话,还是有用处的.一般情况下,如果第三方的库文件出了问题,也就只能使用这个窗口调试了.普通情况下,如果错误

8、定位在C标准库文件的汇编代码上,只有一种可能,就是你的调用出错了. 调试占了研发的很大一部分时间,调试的基本技术就这样,一般情况下是综合运用,灵活掌握,以期快速解决问题,稳定代码.剩下就是经验积累的问题了. 注： MTK Modis 使用简介 Modis PC仿真， 要进行如下操作:(假设工程路径为D:X 第一步：在如下目录中D:X 执行 make Prj_Name GPRS gen_modis 第二步： 转到modis目录 D:Xmodis执行 createmodis.pl .makePrj_Name_GPRS.mak 第三步：再切换到 D:X 执行 ma 到该软件版本对应 的sym文件。该

9、sym和BIN文件同步生成，都位于BUILD文件下。该文件储存了ARM编绎器为软件中所有函数生成的地址。 而出错时，MTK会保存当时栈中最近执行的10条指令的地址，我们通过对这些地址的研究，就可以找到出错的地方。 由于sym文件只保存了函数的地址，函数体里执行的代码地址没有列出，而一般打出的错误地址不会正好对应某个函数的 地址，一般会会偏移N个单位。当然也有例外，我曾遇到一次出错，有一个地址正好和某函数地址对应。对于出错信息 的地址与函数地址不对应的情况，我推测应该是函数体里的指令出错，所以应查找比该出错指令小且最近的函数。 比如上例行“Trace 1745424 150706 MOD_NIL

10、 TRACE_ERROR 0x085569C9”，我们在sym文件中不应该查找0x085569C9 对应的指令，因为一般会一个也找不到，我们要查找x085569C或者x085569对就的函数，这时大约可以查到许多函数， 找到与该出错地址最近且比该地址小的地址对应的函数，十个地址大约可以找到十个左右的函数，通过仔细排查， 确认以下函数： med_int_left_size med_int_sfreeaud_main aud_tts_play_req_hdlr med_int_smalloc med_set_ext_memory_pool TCC_Task_Shell 如此可以大致确定问题出处和原

11、因了，请教项目负责人，知道aud_tts_play_req_hdlr 是语音王的播放函数，在呼入时，有来电报号，该功能和QQ都是从MED栈上动态分配内存，由于QQ占用了一部内存，有呼入电话时，语音王分配内存失败，导到语音解码故障。问题一下解决。 = 呵呵，通过map信息，来查找导致问题的函数入口，是最常用的调试手段之一。其实， 也完全可以通过现象分析来查找问题点。比如，这种完全能复现的问题，很容易找到固定路径的。 如来电提示改为震动，或者无声，会怎样，关闭来电报号，会怎样。一下问题点就出来了。共享内存导致的这个问题， 其实是设计时候的欠考虑，没有考虑到各种可能常见的边界。 Assert用得太多

12、也未必好，作为一种调试手段， 如果都出厂了，还到处Assert或重启来处理一些问题，显得太那个了吧，太不健壮了。 MTK串口调试设置 MTK产品发布时AT和Debug复用仅有的一个串口。 一般AT指令和下载代码一般用串口(APP uses uart_port1， debug调试一般用串口（TST uses uart_port2）。 代码中有可能把串口2和串口3设置为普通IO口来用，因此，在程序调试阶段，如果要想把AT调试和Debug调试同时打开，则需要从新设置uart_port2的GPIO设置。 设置方法：进入customdrvDrv_Tool,用DrvGen.exe 打开customdrvmisc_drv"项目名"cod egen.dws,对uart端口对应的GPIO进行相应设置即可。 如果只是想掉换TST和AT调试信息的串口，只需设置： ./custom/common/PLUTO_MMI/nvram_common_config.c中NVRAM_EF_PORT_SETTIN