硬件调试流程及说明

1

2

3硬件调试流程

硬件调试是一项细心的工作，一定要有耐心。硬件调试工具需要示波器、万用表等，同时需要主芯片调试开发软件及相应的仿真器。硬件调试首先要熟悉原理图原理和PCB布局，然后根据功能模块进行相关调试。调试流程如下。

3.1PCB裸板测试

PCB加工生产故障往往由于设计和加工制板过程中工艺性错误所造成的，主要包括错线、开路、短路。当用户的PCB板制作完毕后，不要急于焊接元器件，请首先对照原理图仔细检查印制电路板的连线，确保无误后方可焊接。应特别注意电源系统检查,以防止电源短路和极性错误，利用数字万用表的短路测试功能测量一下板上所有的电源和地有没有短路的。

然后检查系统总线（地址总线、数据总线和控制总线）是否存在相互之间短路或与其它信号线路短路。

对于需要SMT的PCB板，量小建议每个PCB板都进行一下检查，如果量大可抽样检查。检查完毕无异常后交由SMT焊接，SMT焊接资料有硬件工程师提供焊接用partlist，PCB工程师提供PCB的SMT相关文档。

如果是手工焊接，建议焊接3块，以便调试时进行比较，排除焊接异常出现的问题。并且焊接时建议根据功能模块进行焊接，功能模块调试完成后再焊接其他功能模块。焊接及调试的一般顺序如下：

电源

主芯片及外围最小系统，包括主芯片，晶振，复位电路

RAM，FLASH，串口外设

其他功能模块

按照这样的序调试焊接，优点在于能一步一步的排除问题点。假设，当你把主芯片，存储器都焊好，而且也调试可以工作了，再去焊你的电源，结果板上的

电源部分出问题了，一个高压窜到了主芯片上，那后果不是很严重？

3.2排除元器件SMT错误

SMT后，观察板上是否有下述现象

有漏贴的器件

有焊接不牢固的现象

有极性电容、二极管、芯片是否焊接方向有错误

芯片的相邻管脚焊接短路

小封装的无极性的陶瓷电容，电阻焊接短路

相同封装的芯片焊接错误

芯片管脚有虚焊，挂锡现象

。。。。。。

若发现不正常现象，应分析其原因，并排除故障，再进行调试，直到满足要求。然后用万用表测量电路板上各种电源对地阻抗，记录各电源到地的阻抗值；由于CPU/FPGA等内核电容越来越低，所以1.2V等电压的对地电阻可能会低于100欧姆，需要用万用表的200欧姆档来测量。

如果有短路现象出现，分析并查找原因，处理完毕后再进行下一步硬件调试。

3.3电路板上电操作

上电前一定要检查外接电源电压的幅值是否为输入所需的电源电压数值，极性是否正确，否则很容易造成系统损坏，并确定电路板电源端无短路现象后，才能给电路接通电源。

上电时可用带限流功能的可调稳压电源。先预设好过流保护的电流，一般情况下限流为1.5-2倍的工作电流，如果不确定工作电流，可以先从低到高限流，比如开始限流1A，第一次上电后再改为2A。

电源一经接通，不要急于用仪器测量波形和数据的电气指标，而是要观察是否有异常现象，如冒烟、放电的声光、听听有无异常杂音，闻闻有无异常气味，用手触摸集成电路有无温度过高现象。如果有，应立即关断电源，待排除故障后方可重新接通电源。如果瞬间出现电压值变小，电流变大或出现过流保护，说明

电路板有短路或其他问题，则要断开电源，寻找故障点，并重复上述步骤，直到电源正常为止。

上电，同时监测输出电流和输出电压，并记录输入电压值和电流值，以便调试互相比较。

电源电路、晶振电路和复位电路是整个系统正常工作的基础，应首先保证它们的正常工作。

3.4电源调试

上电通过万用表测试各电源输出值是否正常（如果有电源指示灯，观察指示灯是否正常点亮）。记录此时系统各模块的工作状态和电源的输入电流。

通过示波器测试各电源输出的纹波是否满足设计要求，并保存波形和幅值，纹波等数据记录。

如果板上各电源输出有0R短接电阻，可去掉此0R电阻，串万用表测试电流（万用表打到电流档，表笔测量为电流输出档），记录此时各电源负载的工作状态和电源的输出电流。

3.5主芯片硬件调试

主芯片供电正常后，可调试其最小系统外围电路。这个环节容易出问题的就是复位电路工作不正常，主芯片某些引脚虚焊。主芯片的系统配置正确与否暂时不会影响到芯片是否工作，可以最后检查。

外接晶振调试

通过示波器检测晶振是否起振，振幅，起振时间等参数是否满足要求，并进行波形保存和参数数据记录，如果晶振没有起振，一般说明主芯片没有正常工作，但有些芯片上电缺省采用内部晶振，需要软件配置后，外部晶振才可以起振；

有些主芯片有CLKO管脚，即缺省32.768KHz的时钟输出，可通过示波器检查此管脚是否有时钟输出，开确定主芯片是否上电正常工作。

复位信号调试

复位信号电压是否满足设计要求，上电复位时间是否满足要求；如果外部有硬件看门狗，测试其是否按照设计要求复位。并进行相关波形保存和参数数据记录，

3.6JTAG仿真器连接调试

以通过JTAG口对S3C2410进行调试为例。

在保证S3C2410X已正常工作的情况下，可使用ADS或SDT通过JTAG 接口对片内的部件进行访问和控制。

在此，首先通过对片内控制通用I/O口的特殊功能寄存器的操作，点亮连接在GPG1,GPG8,GPG9,GPG10口上的4只LED，用以验证ADS调试环境是否已正确设置，以及与JTAG接口的连接是否正常。下图为调试系统的硬件连接。

按图接好硬件后，打开AXD Debugger,建立与目标板的连接，AXD Debugger有软件仿真方式和带目标系统的调试方式，此时应工作在带目标系统的调试方式。

首先打开Multi-ICE Server（v1.2），点击左上角的Auto-configure按钮，此时检测板子上S3C2410内的ARM920T核，如果能检测到，证明JTAG连接没有问题，否则，则应检查电路连接，直至检测到ARM920T核才可进行下面的操作。

打开ADS中的AXD Debugger，首先对其进行配置，打开option-->configure target,要使Multi-ICE与AXD Debugger 连接，需要添加一个动态链接库，点击add,把Multi-ICE安装目录下的Multi-ICE.dll添加进去。然后双击，对其进行配置，这里自动给配置好ARM920T，点击OK即可。

打开ADS中的CodeWarrior（代码编辑编译器），新建工程选择ARM Executable Image，并在工程中新建文件，添加亮灯代码到文件中。然后选择菜单中project-->addfile，将刚才写好的代码文件添加进去。打开新建的工程，选择

DebugRel Settings按钮，对Target Settings进行设置。（具体设置见笔记）然后对该工程代码进行编译，若编译成功，则会在当前工程目录下生成.axf文件。

回到AXD Debugger，点击File-->load image，将之前生成的.axf文件导入，然后点击运行，若灯如设想的正常工作，表示调试系统的软、硬件连接完好，可以进行下一步的调试工作。

也可以通过命令行直接点亮灯。选择菜单“System Views”→“Command Line Interface”功能，该选项为AXD Debugger的一个命令行窗口，可在该窗口内输入各种调试命令，使用非常方便。在命令行窗口输入：

>setmem 0x56000060, 0xFFD5FFF7,32//通用I/O G口控制寄存器设为输出状态

>setmem 0x56000064, 0xF8FD,16 //通用I/O G口数据寄存器，低电平亮

外接RAM，FLASH的主芯片，需要通过JTAG仿真器调试，编写相关驱动软件，让最小系统工作正常。

Flash存储器的编程、擦除操作均需要用户编程控制，且程序还应在SDRAM中运行，因此，应先调试好SDRAM存储器系统，再进行Flash存储器系统的调试。

3.7外接RAM调试

SRAM可以直接由ARM芯片来读写，只要信号线接的没错，系统设置没错，SRAM一定会工作，除非买到坏的SRAM。用JTAG接口将板和电脑连接，打开AXD的Command line和Memory watch，使用命令行来对芯片进行初始化。AXD中使用setmem命令对相关寄存器进行设置。如果不知道如何使用Command line,可以在命令行中输入help来查询。设置完寄存器后，后在Memory watch中修改对应地址单元的数据，就可以看到修改后的数据保存下来

了。用这个方法可以测试LPC2214，4510，44B0，2410外部SRAM是否已经工作。

对SDRAM调试之前，首先要对CPU 、SDRAM等进行初始化。

在“Command Line Interface”窗格中的“Debug>”提示符下依次键入以下命令：spp vector_catch,0x00

spp semihosting_enabled,0x00

sreg psr,0x60000013

smem 0x53000000,0,32

smem 0x4C000004,((0x47<<12) (0x1<<4) 0x2),32

smem 0x56000070,0x280000,32

smem 0x56000078,0x0,32

smem 0x48000000,((2<<28) (2<<24) (1<<20) (9<<16) (1<<12) (1<<8) (1<<4) 0),32

smem 0x48000004,((3<<13) (3<<11) (7<<8) (3<<6) (3<<4) (3<<2) 3),32

smem 0x4800001c,((3<<15) (1<<2) 1),32

smem 0x48000020,((3<<15) (1<<2) 1),32

smem 0x48000024,((1<<23) (0<<22) (0<<20) (3<<18) (2<<16) 1113),32

smem 0x48000028,0x32,32

smem 0x4800002c,0x30,32

smem 0x48000030,0x30,32

或者将以上内容保存在C:\memmap.txt中，然后在“Debug>”提示符下键入以下命令：obey C:\memmap.txt,也可以达到上面的命令效果。

选择菜单Processor Views→Memory选项，出现存储器窗口，在存储器起始地址栏输入SDRAM的映射起始地址：0x3000,0000,数据区应显示SDRAM中的内容，此时所显示的内容为一些随机数。双击其中的任一数据，输入新的值，如输入0xAA,若对应的存储单元能正确显示刚才输入的数据，则表明SDRAM 存储器已能正常工作。在连续的4个字节输入0xAA，然后再输入0x55，检测

32位数据是否正确传输，若其中的某一位或几位数据出现错误，则多半是由于对应的数据线不通或连接错误所引起的。

在SDRAM可以正确访问之后，用户可以将自己编写的应用程序编译后下载到SDRAM中运行。

当使用这种方法修改SRAM数据，需要注意的是，你所修改的地址，必须是位于SRAM地址范围内的，否则修改后不会得到正确的结果。如果发现修改后的数据不能得到你想要的数据，可能存在两个问题：1是电路板上数据线存在开、短路。2是芯片的初始化设置不正确，导致存储器映射错误，修改好即可。

3.8外部FLASH调试

使用FLASHPGM烧一个程序来实验一下。如果能顺利烧入，则表示FLASH可以正常工作。如果不能正常烧入程序，多半情况是焊接不够好，FLASH可能存在短路或者虚焊。这里需要知道一件事，FLASHPGM软件是利用SRAM来烧录FLASH的。它先将一段可以烧录FLASH的程序及FLASH初始化软件下载到SRAM中，运行这段小程序，然后再烧录FLASH，所以提供给FLASHPGM的芯片初始化程序必须正确，这样才可能正常烧录FLASH，否则烧录肯定是失败的。

对于2410即外接NAND FLASH又外接NOR FLASH的芯片，用FLASHPGM调试NOR FLASH，用三星提供的小烧录工具调试NAND FLASH。

3.9串口调试

可提供串口调试的主芯片，需先调试好串口，再进行主芯片其他接口的调试，以便实时打印串口信息，确认程序编写是否有问题。

3.10其他外设调试

大部分外设需结合软件进行硬件调试。由于外设种类较多，暂不一一列举。一般根据数据手册或应用手册说明对软件进行编程后，可通过示波器测试相关的时序是否满足要求。

4调试出现问题的解决流程

4.1通用问题解决流程

如果在调试中出现问题，可以按以下步骤进行：

检查原理图连接是否正确

检查原理图与PCB图是否一致

检查原理图与器件的数据手册上引脚是否一致

用万用表检查是否有虚焊，引脚短路现象

用示波器观察数据波形，查询器件的数据手册，分析一下时序是否一致，同时分析一下命令字是否正确

软件的调试要和硬件配合进行，往往问题可能不单单是硬件引起的

4.2主芯片不工作

如果主芯片突然不工作，或工作不正常，一定要先排除软件方面的错误，如果软件正常，板子突然不工作则按如下流程检查

测量主芯片工作电压，确认的是各芯片电源引脚的电压是否正常，再检查各参考电压是否正常，还要测试主要功能点的电压是否正常

等。

测量晶振（体）是否起振，注意晶体的输出幅值比较小，晶振则和其电压相差不大

检查MCU各相邻管脚是否有短路，因为在调试的过程中某些管脚总会因为测量或焊接引起短路；MCU某些管脚会虚焊而没有被发现，

可重新焊接一下MCU各管脚

尝试降低MCU工作频率。

飞线。用别的的口线进行控制，看看能不能对其进行正常操作，

多试验，才能找到问题出现在什么地方

如果各种测试都无法找到问题所在，可更换一片新的主芯片不管是做硬件，还是软件，最重要的是思想，是分析问题的能力，逻辑思维一定要清晰，每测一项就要能排除一些问题，不要做一些重复的测试，记不住就用本子写下来。

5软件调试注意事项

用万用表或示波器对芯片管脚进行测量时注意不要与相邻的管脚接触，以免引起短路，造成器件损坏。

6软硬件调试错误排除

6.1理解系统

仔细阅读元器件数据手册：数据手册里有正确使用元器件的方法。

仔细阅读每个细节：出现问题的地方可能就在你不感兴趣的那一章，不要惧怕数据手册的厚度。

掌握基础知识：知道什么是正常的，才能知道什么是错误的。

了解系统工作流程：有助于定位bug。

了解调试工具：调试工具能干什么，不能干什么。

查阅细节：去阅读数据手册，而不是猜测或回想数据手册上的内容。

数据手册的正确性大于其他文档，比如设计文档。最终以数据手册为准

6.2制造失败

制造失败：目的是为了观察它，找到原因，并检查是否已修复。

从头开始：bug可能由一系列操作或者运行造成的，回到最初状态开始制造失败。

引发失败：试着让失败出现，而不是被动的等，尤其是间歇性失败。

但不要模拟失败：不要猜测失败产生的机理而去模拟一个系统，模拟的系统可能没有体现bug的根源，甚至产生新的bug。

查找不受你控制的条件（正是它导致了间歇性失败）：改变能改变的任何参数，或者将变量设成常量，知道bug再次出现并一直出现。

记录每件事情，并找到间歇性bug的特征：记录运行状态，分析并找到出现

bug时的状态特征。

不要过于相信统计数据：获得足够多的信息并分析，不要猜测。

要认识到“那”是可能会发生的：bug的根源可能是意想不到的，不要大喊“不可能！！！”。

永远不要丢掉任何一个调试工具：没准哪天就能派上用场。

6.3不要想，而要看

观察失败：发现bug不要猜测问题根源，而是要仔细观察bug到底是什么地方造成了bug。

查看细节：缩小范围。

植入插装工具：使用源代码调试器、调试日志、状态消息和printf。

添加外部插装工具：使用分析器、示波器、量表、金属检测仪、心电图仪和肥皂泡。

不要害怕深入研究：不要害怕找到更多的bug，虽然软件已经是成品，bug 还是必须要修复的。

注意海森堡效应：测不准原理。当你为了观察失败而改变系统或插装工具时，避免所做的改变影响系统。

猜测只是为了确定搜索的重点：猜测还是必要的，但不要过多的猜测。

6.4分而治之

通过逐次逼近缩小搜索范围：猜测1～100内的一个数字，只需7次。

确定范围：不要把初始范围设定的太小，如果数字是135而你却认为他在1～100内，那么你必须扩大范围。

确定你位于bug的哪一侧：在某一点检查系统，如果状态正确，则bug位于上游，反之位于下游。

使用易于查看的测试模式：从干净、清澈的水开始，以便当排放物进入河流时很容易看到它。

从有问题的一段开始搜索：正确的部分总是多于错误的部分，应该从有问题

的地方开始，向后追查原因，不要在正确的地方浪费时间。

修复已知bug。bug互相保护，互相隐藏：因此一旦找到，立即修复它们。

首先消除噪声干扰：注意那些导致系统问题的干扰因素，但对一些无足轻重的问题不要过于极端，也不要为了追求完美而去修改所有地方，虽然他看起来不美，但它可以正确工作。

6.5一次只改一个地方

隔离关键因素：当你观察某一个bug的问题时，不要改变与此bug不相关的因素。

用双手抓住黄铜杆：不要猜测并改变系统的不同部分，以便看看他们是否对问题有影响，这可能引起更多错误。

一次只改一个测试：使用步枪，而不是霰弹枪。

与正常情况进行比较：如果所有出错的情况都有一些特征，而这些特征是正常情况所没有的，那么你就找到了问题所在。

确定自从上一次正常工作以来你改变了什么地方：这个改变的地方是一个很好的调试起点。

6.6保持审计跟踪

把你的操作、操作的顺序和结果全部记录下来：当出现bug时你能查看之前更多的细节。

要知道，任何细节都可能是重要的：不要忽略不起眼或者不可能的细节。

把事件关联到一起：尽量详细并量化的描述问题。

用于设计的审计跟踪在测试中也非常有用：Git、CVS、Subversion……

把事情记录下来：好记性不如烂笔头。

6.7检查插头

置疑你的假设：是否运行了正确的代码？问题的根源可能没有想象的那么复杂。

从头开始：可能一开始就错了，以后怎么都不对了。

对工具进行测试：你的工具好用么？你会用么？（见6.1）

6.8获得全新的观点

征求别人的意见：

获取专业知识：

听取别人的经验：

帮助无处不在：同事、供应商、网络、书店……

放下面子：

报告症状，而不要讲你的理论：不要把别人拖进你的思维定势中。

你提出的问题不必十分肯定：提出任何你觉得可以的因素，没准哪个就有帮助。

6.9如果你不修复bug，它将依然存在

查证问题确实已被修复：不要假设bug已经修复了，你修改的地方可能不是造成bug的根本。

查证确实是你的修复措施解决了问题：撤销这个修复，看看bug是否再次出现。

要知道，bug从来不会自己消失：就算你再也找不到它了，它还是会在某一天跳出来，不要有侥幸心理。

从根本上解决问题：不要敷衍。

对过程进行修复：如果总是出现同类bug，检查最初的设计方案。