嵌入式系统开发过程实际上就是一个调试诊断的过程，而且调试诊断将一直伴随着一个产品的终身，即使是最成熟的产品也偶尔会出现这样或那样的问题，这都需要开发人员去诊断、排查。
      嵌入式系统的调试包括硬件调试、软件调试以及综合调试。硬件调试一般是指系统刚开发出来时上电前后的检查，包括：
      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系统是高频电路，对焊接要求比较高，稍微有一点漏焊或者虚焊都不行，我是这样认为的。
      例4：在一个使用实时时钟芯片 SD2000的应用系统中，经常会出现读出的时间被复位到 “2000年1月1日”的情况，我用自己编写的测试程序经过多次测试发现，按照SD2000芯片手册中的时序进行连续读写确实会经常出现复位现象，好像是芯片错把读写时序当成了复位操作时序，而且每次必出，所以我感觉到芯片本身应该有Bug，于是告诉同事可能是芯片本身有问题，让他跟厂家联系，但因为这个芯片在老产品中用了比较长的时间，所以同事不太认同我的看法，但还是与SD2000厂家取得了联系，厂家经过两天专门强化测试后通知我们“SD2000本身确实有Bug，可能因为干扰导致芯片复位到2000年1月1日”。
      例5：在用PNX1700（DSP）处理器设计成的音视频开发平台上，常会出现CVBS输出黑白图像（应该是彩 {MOD}）或颜 {MOD}不正常现象，于是先详细阅读CVBS输出芯片AVS3169的手册，然后用示波器测量3169芯片的时钟管脚，在测量的过程中经常会出现颜 {MOD}恢复正常的现象，再做多次测试发现这种现象是由于将场同步VSYNC信号与相邻的数据线Data7短路造成的，再测试发现将VSYNC与其他数据线（Data[0:6]）任一根短接一下都可以恢复正常，再用视频时钟信号CLK与数据线短接一下有时也能恢复正常，但有时也不能恢复，所以怀疑是视频场同步信号有问题。顺着这根线索查了一下AVS3169的VSYNC信号与PNX1700的连接方式，发现在用CVBS输出时，PNX1700上与AVS3169的VSYNC信号相连的引脚是输出QVCP_VSYNC信号，检查VO输出模式设置没有问题，再查QVCP的设置，看哪个寄存器能控制QVCP_SYNC信号，发现在QVCP_CONTROL(0x10e020)寄存器中有对HSYNC和VSYNC的控制，用命令在线修改了直接相关的该寄存器中4个位的值，但没有任何效果，再在整个PNX1700芯片手册中查找关键字VSYNC，发现在398页有对QVCP VSYNC设置要求的描述：该寄存器的bit1(Master)要求设成1，即从模式，而我们现在是设成0，即主模式，我把该位改成1后屏幕出现黑屏，没有任何显示，再把这位恢复到0，竟然出现了颜 {MOD}，屡试不爽，仔细研究这个寄存器的bit1和bit0分别是控制屏幕时钟发生器（STG）工作模式（主/ 从）和STG的复位，分析觉得在系统上电后对QVCP初始化之前先把QVCP的STG置成从模式并且复位STG，然后再用原有的初始化程序，这样应该可以解决视频信号的时钟和数据不同步问题，所以在主程序中初始化QVCP之前加入MMIO(0x10e020) = 0x20050006行，测试果然不再出现上述问题，问题解决；并顺势延伸一下，以前用SAA7105做CVBS输出时偶尔也会出现屏幕顶部显示不正常问题应该与这个问题一样，所以用上述相同的方法修改程序后对SAA7105 CVBS输出进行强化测试（每8秒钟重新启动一次，强化测试3天），结果没有再出现显示不正常现象；
      例6：同样是PNX1700音视频开发平台上遇到的问题，VGA输出时OSD菜单会抖动，最先想到的方法是把OSD的scaler改用QVCP来做而不是MBS来做，这样在1500上会减轻 OSD抖动现象，几乎不出，但在1700上测试效果还是很不好，抖动仍然很厉害，后来安排同事将1500种DDR时钟的工作频率从166MHz提高到 200MHz，并告诉他需要改哪个模块的哪几个寄存器，这时正好是用VGA做视频输出（一般情况是用CVBS做视频输出，但因为此时正在跟踪VGA中 OSD抖动问题，所以用了VGA输出模式）来调DDR工作频率的，在同事修改DDR寄存器过程中我却发现OSD怎么不抖了，仔细研究同时修改过的寄存器相关位的定义，发现在DDR模块中有两个寄存器与DDR仲裁相关，一个是ARB_HRT_WINDOW（0x65184，DDR仲裁硬件实时窗口），另一个是ARB_CPU_WINDOW（0x65188，DDR仲裁CPU窗口），将这两个寄存器分别设置成ARB_HRT_WINDOW = 0xffff及ARB_CPU_WINDOW = 0x0就不会出现OSD抖动，因为在这种设置情况下DDR对DMA的占有权高于CPU对DDR的拥有权，DDR可以抢断CPU，原来的设置使CPU可以抢断DDR占有DMA。其实在发现问题VGA中的OSD抖动问题之初我也找过与memory相关的寄存器设置，因为根据以前经验和习惯思维，DDR配置寄存器只是负责DDR部分，而memory与CPU之间关系的寄存器应该在系统寄存器中，所以没有去查找DDR配置寄存器，可是在这一例子中却偏偏在DDR配置寄存器中。
      从上述几个例子中我们可以总结归纳以下几点调试方法和注意事项：
      1）加深理解法：加深理解包括加深对硬件和软件的理解，加深对硬件的理解主要是详细阅读相关的芯片数据手册，而加深对软件的理解是因为现在开发嵌入式系统并不是所有程序都需要自己编写，很多都是已经做好的，直接从网上获取或者采购获得，但这些软件不一定是完全针对我们自己的目标板的，所以在使用过程中经常会发现一些问题，特别是底层软件，而一旦出现问题，开发人员首先必须了解出现问题的代码。只有建立在对相关硬件和软件深入理解的基础上才可能做出更符合实际的判断，才可能更好地解决问题。
      2）比较法：比较的方法有很多，比如将同样的软件放在两个类似但不相同的硬件平台上运行比较现象；将两个不同版本的软件放在同一个硬件平台上运行比较现象；将相同的软件放到相同批次但不同的两个硬件平台上运行比较现象。对于一些不是很隐蔽的问题通过比较法通常能得到不错的效果。
      3）分解法：当碰到分析起来比较复杂、可能有很多因素的问题时，可以把问题分成解几个小问题来测试诊断，比如编写几个单独的小测试程序对各种可能因素进行排查测试，根据这些测试结果再进行科学判断。
      4）软硬件结合法：这种方法是需要一定灵感和悟性的。比如上面的例5，在测试过程中，可以在不破坏硬件的前提下临时改变一下硬件的状态（比如该例中将数据线和时钟线短路），看问题现象会不会有所变化，如果有，那么多做类似试验找出变化规律和关键因素，然后再进行分析解决。在底层软件开发中，对于时序要求严格的硬件模块的软件编程要特别注意，一旦程序的时序出了问题，而这部分软件已经与其他系统软件融合到一起，那么这种软件让别人去检查是很难查出问题的。
      5）诊断、排故要建立在大量实验的基础之上，要多动手，不能光知道臆想，不愿实际操作，还美其名曰“善于思考和分析”。嵌入式系统开发是一门实践性很强的科学，需要在实践中总结出事物客观规律，从而更好地认识和利用它们，让它们更好地按我们的意图工作。
      6）嵌入式系统开发调试要求开发人员有严谨细致的工作态度，决不放过调试过程中发现的任何一点蛛丝马迹，因为它很可能就是打开潘多拉宝盒的钥匙。
      7）要有实事求是的工作作风，要有敢于怀疑一切的精神和勇气，我们理当尊重权威和前人的科技成果，但当出现矛盾时我们更应该相信实验结果，这样科学才会进步。
      8）要勇于挑战自我，抛开习惯性思维和成见，拓宽思路，多角度分析问题。
      9）嵌入式系统开发特别是底层软件和操作系统内核开发因为需要同时跟软件和硬件打交道，所以是一件比较艰苦的工作，很有挑战性。即使我们各方面都做得非常好，考虑得非常细致周全，目标系统仍然可能跟我们开一些小小的玩笑，我们经常会碰到一个非常小的问题困扰我们几天甚至几周的时间，这期间我们可能茶饭不思、夜不能寐，因此嵌入式系统底层软件开发人员不但要有平和的心态，且具备一定的耐心和毅力，还要有勇于克服一切困难的勇气和信心！只要我们做得足够好，那么可能解决一个具体疑难的过程带有一定偶然性，但我们终将排除所有阻碍！
      所以说，嵌入式系统调试过程就是一个更加深入了解我们的目标系统以及系统中的每个单元模块特性的过程，就是一个锻炼我们的逻辑思维和分析推理能力的过程，就是一个开拓思路、向习惯思维和权威挑战的过程，就是一个培养严谨细致的工作态度和实事求是工作作风的过程，就是一个锻炼我们耐力和毅力的过程，最终是一个学习进步的过程！
      嵌入式系统调试诊断能力的提升是一个长期实践、积累、提高的过程！         本文节选自王洪辉老师的《嵌入式系统Linux内核开发实战指南（ARM平台）》一书。