使用OpenJTAG来检查硬件焊接问题。
今天有一个上门来的客户，他们公司使用S3C2440做了一个产品，碰到一些问题：
1. 通过H-JTAG烧录程序到NOR Flash，有时可以烧，有时不可以烧；无法烧写时，H-JTAG出现“无法加载驱动”的错误提示。
2. 碰运气烧写成功后，vivi有时候可以启动，有时候不行。
3. vivi启动后，通过USB烧写Nand Flash，必导致串口没有任何反应。
因为主要器件的原理图与我手上的一块开发板完全一样，并且我对它所用的supervivi非常熟悉，所以开始我认为是硬件设计得不稳定，导到有时候可以运行，有时候无法运行。
于是，我修改一个u-boot，把CPU频率从400M降低到200M，SDRAM频率从100M降低到50M，在开发板上验证通过后，烧写到用户的板子上，仍是无法运行。
上述实验都是使用并口JTAG进行烧写的，实验进行到这里，单是使用并口JTAG已经无法再进行下去了：同样的板子，同样的程序，在A板子上可以运行，在B板子上有时行有时不行，任谁都会想：肯定是板子不稳定！
但我不想止步于此，于是使用OpenJTAG监测单板：连接OpenJTAG，当程序没反应时，执行halt命令停住CPU，查看寄存器。发现PC值总是4，这表示发生了“未定义指令异常”，就是说CPU执行时，所取得的指令是不对的。这些指令是一开始就不对，还是运行一段时间后才被破坏？还要继续查下去。
我再使用OpenOCD的“load_image u-boot.bin 0x33f80000”命令把u-boot.bin下载到SDRAM 0x33f80000位置处；然后使用“verify_image u-boot.bin 0x33f80000”比较本地的u-boot.bin与单板SDRAM 0x33f80000中的数据，发现数据不一致！所以，可以说明：SDRAM的操作有问题。
那么，SDRAM的问题，是不隐定导致的，还是硬件本身的缺陷(比如焊接)导致的？一般先确定是否焊接问题，因为它比较容易。我先使用“mww 0x33f80000 0xaaaaaaaa”往0x33f80000地址写入数据0xaaaaaaaa，再使用“mdw 0x33f80000”读出数据，发现所得数据为0xaaaaaeaa；再执行“mww 0x33f80000 0x55555555”、“mdw 0x33f80000”，得到数据0x55555555。
先暂停一下，为何使用数据0xaaaaaaaa、0x55555555而不是其他？这是因为0xa的二进制是0b1010，0x5的二进制是0x0101。0xaaaaaaaa、0x55555555这两个数，可以让32根数据线的电平高低相间，这可以观察相邻数据线是否短路。
现在分析上述结果：写0xaaaaaaaa得到0xaaaaaeaa，即bit[10]本来应该是0，现在变成了1；写0x55555555得0x55555555，bit[10]仍是1。从这两点可知：数据线DATA[10]是有问题的，但是它并没有与旁边的DATA[11]、DATA[9]短路。
根据这个结果，再进行一些实验：“mww 0x33f80000 0”、“mdw 0x33f80000”得到数据0x00000400，这也表明了DATA[10]有问题。
现在再来访问内部RAM，看看有无这个现象：“mww 0x40000000 0xaaaaaaaa”、“mdw 0x40000000”，发现得到的数据是0xaaaaaaaa。
所以，结论是：外部SDRAM的DATA[10]被拉高了，原因可能是焊接时短路了。在我这里的试验到此结束，客户把板子回去找原因了。
转载请注明出处，文章来源：http://www.threeway.cc/sitecn/InformationInfo.aspx?tid=1382&pid=2450