嵌入式系统调试方法介绍 提高诊断能力

文章介绍了嵌入式系统开发过程实际上就是一个调试诊断的过程，而且调试诊断将一直伴随着一个产品的终身，即使是最成熟的产品也偶尔会出现这样或那样的问题，这都需要开发人员去诊断、排查。

嵌入式系统的调试包括硬件调试、软件调试以及综合调试。硬件调试一般是指系统刚开发出来时上电前后的检查，包括：

1)上电前检查电源和地是否短路，目视检查是否有虚焊、漏焊;

2)上电后检查时钟线上的频率和波形、幅度是否正常，各电源电压是否稳定正常，各芯片温度是否正常，各指示灯是否正常。

软件调试一般是指保证硬件一切正常的情况下验证程序执行的时序是否正确，逻辑和结果是否与设计要求相符，能否满足功能和性能要求等。软件调试的方法有很多，包括：

1)用指示灯跟踪调试;

2)用串口打印调试;

3)用简单的调试器进行汇编代码级调试;

4)用比较高端的调试器进行源代码级调试;

5)用仿真器进行硬件仿真。

上述单纯的硬件调试或软件调试都是相对比较简单的，困难的是综合调试。下面我先举一些自己在工作中曾经碰到的疑难问题，然后再从中归纳出一些一般的调试方法和注意事项。

例 1：我们自主设计制作的PPC860(Motorola)网络引擎平台的调试已接近尾声，同一批生产的4块板子都通过了全部软件测试，于是又去焊了第二批，可是在第二批板子中有1块板子的FEC不能正常工作，我们几个软件和硬件工程师使用了各种手段，重新看了多遍芯片手册，还是没找出原因，于是把板子发回工厂重新焊接BGA，可是回来问题还是照样存在，没办法最后打算将这块板子当作个样处理，把板子上的芯片都焊下来。按常理来说这种做法很符合逻辑，因为元器件都是一样的，板子也是一批的，那就可能是这块板子的某个地方焊接不好，但又不好查，反复重新焊接可能会把主板焊坏。后来有人从PPC860芯片上用放大镜都要睁大眼睛才能看清的字符上(据说我国第一代国产高端处理器芯片“寒心”就是某“科学家”将“摩托”同一类型芯片上的这些字母磨掉后刻上“寒心一号”摇身一变造出来的!!!)发现这块板子的CPU版本号是“D4”，而其他板子的CPU版本号是“D3”，可芯片手册上并没有这两个版本之间的比较说明，从网上找到PPC860的勘误手册，发现在PPC860TZP50D4版本中，ECNTRL寄存器增加了一个叫FEC_PIN_MUX的位(bit2)来控制FEC各管脚的复用功能，如果要使用FEC就必须将该位设置为1，所以要在FEC的相关程序中加上ECNTRL |= 0x00000004语句行。

例2：当我调试业余自制的MC68VZ328板子时，电路板硬件检查没有问题，用Code warrior通过串口往flash中烧制编译好的uClinux程序也一切正常，但是重新上电，发现串口没有任何数据，用万用表检查(当时自己没有示波器等“先进设备”)也没查出结果，然后每天上下班把这块板子放在包里，没事就拿出来瞪大眼睛看看，看着也不免窝火，但有一天却发现一个标着电阻符号的地方却焊上了电容，回到家把电阻换上去再上电，串口一下就打印出uClinux的启动信息，呵，那滋味，比喝了蜂蜜都甜，当然当时也是因为没有太多经验，如果这问题放现在，估计一天内肯定解决掉。另外在初次调试自制的S3C4510开发板时，就是不能从串口输出字符，费了半天时间才发现把串口电平转换芯片 max3232cse的第6脚上的旦电容极性焊反了。

例3：在调试SB1250嵌入式服务器主板时，由于使用的是DDR1代内存条，数据线和时钟线上串并联的去耦电容电阻相当多，第一批焊回来的板子几乎没有一块能够顺利进入CFE(BIOS)菜单界面的，检查时钟波形和电源与借用的 DEMO板相比都很好，我把主板上DDR DIM槽周围的那些去耦电阻电容都全部用烙铁重新过一遍锡，嘿嘿，还真管用，这种方法屡试不爽，而且在后面调试PCI和HT总线时使用这招也很有用，可能是因为SB1250系统是高频电路，对焊接要求比较高，稍微有一点漏焊或者虚焊都不行，我是这样认为的。

从上述几个例子中我们可以总结归纳以下几点调试方法和注意事项：

1)加深理解法：加深理解包括加深对硬件和软件的理解，加深对硬件的理解主要是详细阅读相关的芯片数据手册，而加深对软件的理解是因为现在开发嵌入式系统并不是所有程序都需要自己编写，很多都是已经做好的，直接从网上获取或者采购获得，但这些软件不一定是完全针对我们自己的目标板的，所以在使用过程中经常会发现一些问题，特别是底层软件，而一旦出现问题，开发人员首先必须了解出现问题的代码。只有建立在对相关硬件和软件深入理解的基础上才可能做出更符合实际的判断，才可能更好地解决问题。

2)比较法：比较的方法有很多，比如将同样的软件放在两个类似但不相同的硬件平台上运行比较现象;将两个不同版本的软件放在同一个硬件平台上运行比较现象;将相同的软件放到相同批次但不同的两个硬件平台上运行比较现象。对于一些不是很隐蔽的问题通过比较法通常能得到不错的效果。

3)分解法：当碰到分析起来比较复杂、可能有很多因素的问题时，可以把问题分成解几个小问题来测试诊断，比如编写几个单独的小测试程序对各种可能因素进行排查测试，根据这些测试结果再进行科学判断。

4)软硬件结合法：这种方法是需要一定灵感和悟性的。比如上面的例5，在测试过程中，可以在不破坏硬件的前提下临时改变一下硬件的状态(比如该例中将数据线和时钟线短路)，看问题现象会不会有所变化，如果有，那么多做类似试验找出变化规律和关键因素，然后再进行分析解决。在底层软件开发中，对于时序要求严格的硬件模块的软件编程要特别注意，一旦程序的时序出了问题，而这部分软件已经与其他系统软件融合到一起，那么这种软件让别人去检查是很难查出问题的。

5)诊断、排故要建立在大量实验的基础之上，要多动手，不能光知道臆想，不愿实际操作，还美其名曰“善于思考和分析”。嵌入式系统开发是一门实践性很强的科学，需要在实践中总结出事物客观规律，从而更好地认识和利用它们，让它们更好地按我们的意图工作。

6)嵌入式系统开发调试要求开发人员有严谨细致的工作态度，决不放过调试过程中发现的任何一点蛛丝马迹，因为它很可能就是打开潘多拉宝盒的钥匙。

7)要有实事求是的工作作风，要有敢于怀疑一切的精神和勇气，我们理当尊重权威和前人的科技成果，但当出现矛盾时我们更应该相信实验结果，这样科学才会进步。

8)要勇于挑战自我，抛开习惯性思维和成见，拓宽思路，多角度分析问题。

9)嵌入式系统开发特别是底层软件和操作系统内核开发因为需要同时跟软件和硬件打交道，所以是一件比较艰苦的工作，很有挑战性。即使我们各方面都做得非常好，考虑得非常细致周全，目标系统仍然可能跟我们开一些小小的玩笑，我们经常会碰到一个非常小的问题困扰我们几天甚至几周的时间，这期间我们可能茶饭不思、夜不能寐，因此嵌入式系统底层软件开发人员不但要有平和的心态，且具备一定的耐心和毅力，还要有勇于克服一切困难的勇气和信心!只要我们做得足够好，那么可能解决一个具体疑难的过程带有一定偶然性，但我们终将排除所有阻碍!

所以说，嵌入式系统调试过程就是一个更加深入了解我们的目标系统以及系统中的每个单元模块特性的过程，就是一个锻炼我们的逻辑思维和分析推理能力的过程，就是一个开拓思路、向习惯思维和权威挑战的过程，就是一个培养严谨细致的工作态度和实事求是工作作风的过程，就是一个锻炼我们耐力和毅力的过程，最终是一个学习进步的过程!

嵌入式系统调试诊断能力的提升是一个长期实践、积累、提高的过程!