很久没有遇到过这么折磨人的工作了,随着昨天换了器件,设备工作正常后,折磨人的状态也可以告一段落了。调试最郁闷的阶段时,曾设想过结果,总觉得出个稳定结果是那么遥不可及,总觉得设备能正常工作了简直是天方夜谭,当时就想,要是有一天能调通了,一定得作个总结。称着现在还记得细节,把调试过程记录一下,好为以后工作时做个参考。
运行平台:OMAP3530-MINI开发板
操作系统:Linux 2.6.28
处理器:ARM ContexTM-A8
文件系统:Angstrom
调试设备:WIFI Ralink RT2571MF,摄像头 Sonix SN9C230A
调试需求:使WIFI和摄像头在 OMAP的开发板上正常运行。
调试过程:
首先进行摄像头的调试,到最后这玩意儿也没有成功,所以说这个起点的选择本身就增加了调试的难度。
设备插到无源USB HUB上,一直取不出设备ID和厂商ID值,总报错误:
> usb 1-1.4: device descriptor read/64, error 2
> usb 1-1.4: new full speed USB device using musb_hdrc and address 5
> usb 1-1.4: device descriptor read/8, error 2
> usb 1-1.4: device descriptor read/8, error 2
> usb 1-1.4: new full speed USB device using musb_hdrc and address 6
> usb 1-1.4: device descriptor read/8, error 2
> usb 1-1.4: device descriptor read/8, error 2
或类似错误。开始一直怀疑驱动有问题,或者内核编译有问题,起初几天一直在内核的选项上绕来绕去。由于以前没有搞过嵌入式的开发,花了近一个星期的时间熟悉了内核文件及文件系统的到OMAP开发板的转移。更换了许多次内核选项后,错误依然存在,现象稍微有点差别就是error值可能会出现-71 -110。
期间跟驱动的开发团队(大部分是外国人)联系,让他们帮忙找原因,得出的结论是驱动肯定支持这款摄像头,需要找其它方向的原因。当时考虑到错误信息是在USB总线控制驱动上打出的,偶尔会出现总线异常,怀疑过内核总线部分的驱动会不会有BUG,或许最新版本才修正的,曾考虑过升级内核版本,可惜因为这种内核版本的升级太复杂,搞了半天没整明白就放弃这种想法了(就算能整明白,时间上也是不允许的)。也曾有人说硬件有问题,但也说不出啥问题,只说硬件有问题,而定位不到是啥问题,或没有合理的证据证明问题所在,没法跟BOSS交待,就只能继续偿试变更内核编译选项,更换驱动来进行测试,继续偿试不同的修正方案。
调了很长时间摄像头没有啥结果后,就想在WIFI上试试,看能不能先把WIFI试通。虽然此时已经在使用有源USB HUB,但WIFI插到HUB上时只在第一天晚上试成功的概率比较大,以后就一直大概率发生不认识设备的现象。总体上看,调通WIFI还是有门的。
现在的调试思路还是以解决驱动问题作为出发点,试了很多次内核驱动没效果后,被逼无奈放弃了内核自带驱动,用了厂商提供的驱动。先前不想使用这个驱动是因为不会交叉编译,搜了一些资料后,费了很大劲编译好驱动后,现象还是没有多大改善。但完全可以排除驱动有问题,思路也就转到了从硬件上找原因了。
根据错误提示代码找到了提示信息大致为USB总线协议错误和超时错误。按这两个提示,猜测是经常HUB的转换,信号变弱了,试着把设备线和HUB线改短了,还是没有啥效果。想到以前把WIFI直插到板子上后,每次都能取得设备信息,就是驱不起来,此时就想从此处试着找突破口。无意间发现了下面的错误提示:
usb 1-1: Manufacturer: Ralink
usb 1-1: rejected 1 configuration due to insufficient available bus power
usb 1-1: no configuration chosen from 1 choice
在google上搜的时候找到了下面的链接,
http://rt2x00.serialmonkey.com/phpBB/viewtopic.php?f=5&t=5459
参考里面的一个命令 echo -n 1 >/sys/bus/usb/devices/1-1/bConfigurationValue居然把WIFI给驱起来了。驱起来后,马上把这个美好的情况和同事分享了。然后确定HUB有问题,就电询了一下瑞泰的技术支持,按照他们的推荐买了一个USB HUB,然后再在HUB上试WIFI,居然能完美的正常工作了。
此时问题的原因基本上能确认了,板子的芯片或电路有问题,可惜的是摄像头在新HUB上还是不能用,从WIFI的情况,完全可以确定这个问题是出现在硬件上,暂时就不是我能解决得了的了,让他们搞硬件的想办法去吧。
调试结果:近四个星期,调出一个设备;找出比较合理的证据,把另一个设备出错的原因给推到硬件层。
调试总结:
1、调试的大部分时间都放到内核的编译,驱动的编译上。如果以前对Linux熟悉得很,这部分时间能缩短。
2、问题方向的定位没找好。以前做的工作,都是在硬件的工作正常的前提下进行的,找硬件原因没有太多经验。如果早点能确认出HUB问题,完全可以很快把WIFI整出来。
3、对Linux的基本命令不熟悉。到现在为止也不知道为啥 echo -n 1 >/sys/bus/usb/devices/1-1/bConfigurationValue 命令能激活WIFI。如果早些时候就知道这个命令可以激活WIFI的话,就不用怀疑驱动有问题了,早就可以在板子的USB接口上调通WIFI了。
后记:
调试的中间那一周,是最郁闷的时刻,该试的方法都试过了,一点方向也找不到了,曾想过放弃这个任务,让BOSS换人调试,或直接取消这个方案。看到BOSS不可商量的表情下,硬着头皮进行了最后几天的偿试,其间不小心发现了救命的echo -n 1 >/sys/bus/usb/devices/1-1/bConfigurationValue命令,居然给合格的完成了这任务。郁闷的时候曾经想,这个活儿也许会成为我做过的最失败的活儿,可能会以完败而告终,虽然不想承认,但要真出现那种结果,以当时的想法来看,也只能认了。也不好说达到现在的结果是喜是忧,可能用苦尽甘来描述会恰当些吧。