开发板硬件调试大致步骤(转)

古城微笑少年丶 2022-03-26 15:18 745阅读 0赞

开发板硬件调试大致步骤(转))

当用户的印制电路板制作完毕后，不要急于焊接元器件，请首先对照原理图仔细检查印制电路板的连线，确保无误后方可焊接。同时，尽可能的以各单元电路为单位，一个个焊接调试，以便在调试过程中遇到困难时缩小故障范围，在系统上电后，应先检查电路工作有无异常，芯片在工作时有一定的发热是正常的，但如果有芯片特别发烫，则一定有故障存在，需断电检查确认无误后方可继续通电调试。

调试工具需要示波器、万用表等，同时需要ARM调试开发软件ADS或SDT及相应的仿真器，本系统在调试时使用ADS1.2及Multi-ICE实时仿真器。

1.电源、晶振和复位电路

电源电路、晶振电路和复位电路相对比较简单，按原理图连接后应该就可以正常工作，此时电源电路的输出应为DC 3.3V和1.8V。

用示波器观测，有源晶振的输出应为12MHz；

复位电路的RESET端在未按按钮时输出应为高电平（3.3V），按下按钮后变为低电平，按钮松开后应恢复到高电平。

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

2.通过JTAG口对S3C2410进行调试

在保证电源电路、晶振电路和复位电路正常工作的前提下，可通过JTAG接口调试S3C2410X。

给系统上电后，可通过示波器查看S3C2410X对应引脚的输出波形，判断是否已正常工作，在保证S3C2410X已正常工作的情况下，可使用ADS或SDT通过JTAG接口对片内的部件进行访问和控制。

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

![11311c62842.jpg][]

按图接好硬件后，打开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口数据寄存器，低电平亮

3.SDRAM 接口电路

在系统的两类存储器中，SDRAM相对于FLASH存储器控制信号较多，似乎调试应该困难一些，但由于SDRAM的所有刷新及控制信号均由S3C2410X片内的专门部件控制，无需用户干预，在S3C2410X正常工作的前提下，只要连线无误，SDRAM就应能正常工作，反之，Flash存储器的编程、擦除操作均需要用户编程控制，且程序还应在SDRAM中运行，因此，应先调试好SDRAM存储器系统，再进行Flash存储器系统的调试。

对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中运行。

4.Flash接口电路

将已有的vivi 下载到Flash 中，连接串口，重启板子，从超级终端中看到vivi 运行正常，证明Flash接口电路连接正确。

接着烧写内核，文件系统，也都正确，接上USB摄像头，能识别出来，也能查看里面的内容，USB正常工作。插上网口，RJ45指示灯亮，用IFCONFIG命令设置一个IP，查看IP时值一致，至此以太网接口也调通了。跟单片机板对接，执行面部识别程序，成功。至此，整块开发板都调通了。

**S3C2410硬件调试笔记**

最近给一个ARM系统进行硬件升级，将S3C2410升级为S3C2442。调试过程中遇到了一些问题，现在拿出来跟大家分享。

2442这款芯片用的人不多，可参考的资料不多，可能有些人还比较陌生。下面我简单介绍一下：所谓2442就是2440 MCP(SDRAM NANDFLASH)，2440是2410 AC’97 CODEC interface  Camera interface。2410大家都很熟悉，这里我就不说了。关于2442芯片资料可以去三星网站下载。我的开发资料也就是在三星网站上下载的那些。

内置SDRAM、NANDFLASH正确的硬件接法：

2442的MCP有5种，我用的是2442A43，内置64M SDRAM 、128M NANDFLASH。SDRAM连接比较简单，只需将nGCS6或nGCS7接到/CS即可，SDRAM控制器其余引脚芯片内部已经接好了，不需操作。 NANDFLASH接法稍微复杂点，要接7个引脚：

1.nFCE接到/CE

2.NCON0上拉10K(3.3V)，配置为Advance

3.GPG13(PAGE)上拉10K(3.3V)，配置为2K bytes

4.GPG14(ADDR)下拉4.7K ，配置为 4 address cycle

5.GPG15(WIDTH)下拉4.7K ，配置为 8-bit bus width

6.FRNB（R/B）上拉4.7k（1.8V）

7./WP上拉4.7k（1.8V）

这几个引脚的配置害人不浅啊，详细情况回在以后的帖子中细说。晚了，先写到这（待续……）

文章引用自：

好几天没留言了，接着上次的地方写。 板子刚到手里，一量各路电压都正常。关于电压只说一点，我打算跑400M ，故将VDDiarm、VDDi、VDDMPLL、VDDUPLL 设为1.5V。各路电压正常，开始下一步。我用MULTI-ICE找到了ARM920T内核,然后在ADS中点击debug  
弹出一个提示框：Target processor would not enter debug state when requested. Do you want to try asserting system reset with a breakpoint on address 0? This will affect the other processors in a multi-processor system. Yes or no?  
选yes后  
弹出fatal AXD error  
RDI severe error 00259：unable to stop target processor. check the server configuration matches the target system, the target is powered up, not in reset and can operate at the TCK setting used.  
选择restart 后，重新出现第一个提示框，进入死循环了（这个问题相信很多人都遇到过，很头疼的问题）。问题可能出现在哪呢？我反复查JTAG电路，该上拉的地方都做了，示波器测JTAG信号质量也可以，找内核时TCLK信号质量还不错。RESET电路也工作正常。请教了很多朋友，也没有什么进展，问题出在哪就是查不出来。这个问题困扰了我一周多，郁闷可想而之了。无奈之下有病乱投医，开始拆电阻。把NANDFLASH和SDRAM配置的电阻都拆掉了，结果进入了调试状态（小爽一下）。原来问题出现在NANDFLASH的配置电阻上，板子焊接时将NCON0接了下拉，配置为Normal 。这个就是上篇帖子中说的害人不浅之一。（待续...）

自己做的第二版板子， 拿回来后， 可以通过ICE检测到arm核， 但是不能进入AXD， 错误提示如下：

Target processor would not enter debug state when requested. Do you want to try asserting system reset with a breakpoint on address 0? This will affect the other processors in a multi-processor system. Yes or no?

弹出fatal AXD error  
RDI severe error 00259：unable to stop target processor. check the server configuration matches the target system, the target is powered up, not in reset and can operate at the TCK setting used.  
选择restart 后，重新出现第一个提示框，进入死循环了

百思不解， 几乎都快放弃了， 郁闷良久。

幸亏在网上找到诸多同行提供的信息终于解决问题。

问题的关键在于： OM0, OM1没有配置正确， OM0必须接到高电平才能工作。

（建议nwait也要拉高， OM2,OM3有正确的配置）

感谢以下网上同行提供的资料：

SoupDragonDec 13 2006, 03:15 PM  
Hi,

The ARM can only respond to a debug request between instructions (in the same way that most ARM cores can only respond to an interrupt between instructions).

If the bad boot loader that you have programmed in tries for example, to access non-existent memory and the memory controller does not signal an abort, then the core can never finish the instruction and therefore never respond to the debug request.

To get the core to go into debug mode you need to get your debugger/ICE to do the following (and this is only possible if nTRST and nSRST are truly separate signals on your chip and board\[1\]);

assert the nSRST signal  
assert the nTRST signal  
release the nTRST signal - this resets the TAP controller  
program a HW breakpoint at 0x0  
release the nSRST signal - this lets the core start running

The ARM will immediately hit the breakpoint at 0x0 (and stop) before it does anything else. See sections 5.1.2 and 5.1.3 of the MultiICE user guide for some more on this topic.

What you do after this to program a new boot monitor depends on the board/chip/debug tools but I guess you'll have to run some kind of script to initialise RAM and program the FLASH??

\[1\]If nSRST and nTRST are joined then resetting the ARM (so that it starts running at 0x0) will also reset the TAP controller and remove the breakpoint at 0x0.

最近在做基于三星S3C2410的项目，在硬件调试过程中碰到一些特殊的问题，困惑了我好久，现在终于解决了，为了避免类似问题再次发生，特地写下这个总结，也希望同行们以此为鉴。

1、nWait信号上拉电阻的阻值选择不当，会引起系统死机。为了节约成本，产品的PCB采用核心板加底板的结构，其中，S3C2410核心板是在别的产品中采用过的，是经过验证能够正常工作的；底板是本次项目重新设计的。将核心板插到底板后，通过USB下载BOOT,linux内核和文件系统，启动linux系统。系统在装载CS8900驱动时死机，连复位按钮也不响应，只能切断电源进行重新启动。

既然是在装载CS8900驱动时CPU死机，问题基本定位在CS8900这颗IC的电路上。CS8900在核心板上，而核心板在别的产品中，一切工作正常，那是不是底板上的器件影响到了CS8900的相关电路呢?用示波器对CS8900的控制信号逐个检查，终于找到了问题。系统死机时，CS8900输出到S3C2410的nWait信号线的电压是0.9V左右，属于低电平或电平信号的临界状态，S3C2410检测到nWait信号，所以会停止运行，等待nWait恢复到高电平后再执行下面的指令。

再次检查原理图发现，在核心板上nWait信号线通过一个10K欧姆的电阻上拉到3.3V电源；在底板上，以前的产品没有使用该信号，而这次的产品nWait信号还连接到其他的IC。nWait信号本该是高电平，但由于IC驱动不够，才导致实际输出0.9V，被当成低电平了。

真相一切大白，将上拉电阻改为1.5K欧姆，问题解决，系统终于正常运行，熟悉的小企鹅跃入眼帘，显得异常可爱！

[11311c62842.jpg]: /images/20220326/d37e72c251af47eab01afb6214408a80.png