Posted inDebug

Intel 82551强制模式

最近遇到了一个问题，公司之前设计的产品在旁路网络的时候只旁路了百兆4根线，结果造成用户在使用的过程中一旦将网络盘路后两端的装置无法正常协商成功。后来只能将两端的装置强制为百兆全双工，我们的设备依旧为自动协商。 后来我们的产品在运行过程中出现了协商时为百兆全双工、时为百兆半双工。在百兆半双工的情况下会造成网络故障。 开始以为是Intel 82551网络协商问题，后来查了一下网络自动协商的规范，原来在一端强制、一端自动的时候只能协商网络速度，而不能协商双工与半双工，在一端强制的情况下，另外一端也必须强制对端的速率和双工。 于是通过options=0x70强制网卡驱动在加载的时候为百兆全双工。但是又遇到了另外一个问题：网口在ifdown/ifup或者拔掉在插上的时候检测link非常慢，需要5分钟以上，这个肯定是不正常的。 接着google，但是毫无进展。后来查看到82551的DS中对MDI/MDI-X有一个切换时间的选择配置，想一下我们的装置也配置了MDI/MDI-X自适应，会不会是这个问题呢。 马上修改驱动禁止MDI/MDI-X自适应，网口检测马上好了，接着打开MDI/MDI-X自适应，同时修改切换时间从80ms到105ms，问题解决。 怀疑是网络设计信号完整性不是很好，检测link时间过长而导致MDI/MDI-X切换。   参考资料： http://en.wikipedia.org/wiki/Autonegotiation
Posted inDebug

LPC2366 Ethernet CRC error

最近公司用NXP的LPC2366做了一个新板子。很奇怪。我们使用之前现成的程序，发现网络ping不通。但是这个程序在之前的板子上是可以正常工作的。 后来同事使用周立功的程序跑了一下，OK，可以ping通。现在就有一个奇怪的现象： 老程序在老板子能正常工作 老程序在新板子不能正常工作 周立功的程序在新老板子都能正常工作 问题来了，究竟是程序的问题还是硬件的问题呢？ 今天终于得空把这个问题整理一下。首先我在老程序的网络中断中增加了打印信息，主要是中断类型和接收报文的状态信息。在新老2个板子上测试。 发现在老板子上多报出AlignmentError和CRCError错误。看来应该是CRC错误导致报文无法被进一步处理。因为老程序的协议栈我还是非常相信的。没办法，google吧。 LPC2000系列的MCU在yahoo上有一个group，于是我在上面搜索了一下。果然发现一个帖子也是遇到了CRC错误的问题，他最后给出的问题原因是PHY芯片的CRS和CRSDV不是同一个管脚，是不是我们的问题原因也是这个呢？于是看了一下原理图，发现果然犯了一样的错误。DM9161的作为RMII使用时，CRSDV应该接到35脚，但是我们的设计接到了37脚。明显接错了。割线飞线，问题解决。 参考 RE: [lpc2000] LPC2368 and KSZ8041NL
Posted inDebug

pppd拨号出错

修改dialer文件，通常位于/etc/dialer。在char一行中增加-s参数，如下： [crayon-68033b8783c5c630395176/] 其中，-s为使用标准错误。所有由“-v”产生的日志信息和所有的错误信息将发送到标准错误。如果pppd在前台运行则信息输出到stdout和stderr，否则输出到/etc/ppp/connect-errors。 然后查看/etc目录下是否有ppp目录。 调用拨号脚本 查看/etc/ppp/connect-errors文件，此文件包含的拨号的详细过程。下面为成功拨号的信息 # cat /etc/ppp/connect-errors timeout set to 3 seconds abort on (\nBUSY\r) abort on (\nNO ANSWER\r) abort on (\nRINGING\r\n\r\nRINGING\r) send (rAT^M) send (rAT+CGDCONT=1,IP,CMNET^M) expect (OK)…
Posted inDebug

Freescale MPC8241 with USB controller

客户想在我们一款很老的设备上（MPC8241）上扩展一个USB控制器。让我很是头疼。因为现在主流的CPU，包括MCU基本都带有USB host/device。 于是各种google，查内核代码，发现NEC/CYPRESS/NXP/VIA均有USB控制器。打电话了解了如下： CYPRESS的USB控制器是本地总线接口，但是没有很好的linux驱动支持，可能需要用户自己调试。PS：我们之前有用过PCIE接FPGA挂载CY7C67200,虽然linux-2.6带有驱动，但是调试中发现各种问题，最后也不清楚是FPGA逻辑还是驱动问题，最后不了了之。 NXP的USB控制器也是本地总线接口，这就需要我们改版，但是代理说NXP现在不是主推这个芯片，并且这个芯片已经很久了，不一定什么时候就停产了。 NEC的USB控制器是PCI接口，这个非常好，因为我可以不用改版。但是代理很久都没有给我找到做好的USB扩展卡。 VIA就更悲剧了，我们连代理都没搞到。 测试1： 研究了一下NEC/VIA的手册和linux的USB控制器驱动。NEC和VIA都是OHCI，通过pci_register_driver注册，理论上来说插上就可以用。于是买了几款USB扩展卡，插上。系统检测到PCI设备，bingo，上个厕所先。结果回来以后发现CPU烧到了。 原来买的USB扩展卡做的有BUG，VIO居然直接直接和5V短在一起。而我们板子的VIO接的是3V3，结果导致3V3和5V短路，把CPU烧掉了。 测试2： 向我们在郑州的同事了解了一下，原来那边已经在MPC8247上扩展了USB控制器。于是原理图和驱动要来。画图、生产。 加载驱动可以找到芯片ID，但是向scratch寄存器写入后在读发现读回来的永远是0x00，放慢写时序也没有效果。这个是很奇怪的，因为读芯片ID之前也要做一个写操作。 想起来很早前用的一款CONEXANT的CS86500。当时调试这个芯片的时候所有寄存器都正常，只有读IIR的时候清不掉中断。后来发现需要在CS有效到RE有效之间有一定延时。MPC8241的LB没有地址建立时间这个概念，当时是通过调整CPLD解决的。 于是修改CPLD在CS有效和WE有效之间增加的一个延时。向scratch寄存器写入0x55AA读回来正确了。插入U盘，提示如下信息： hub.c: new USB device ISP116x_HCD-1, assigned address 2 usb_control/bulk_msg: timeout usb.c: USB device not accepting…
Posted inDebug Micriμm NXP

LPC2366 uC/OS & uC/TCP-IP

最近调试LPC2366+uC/OS+uC/TCPIP，因为是从别人那里拿来的的代码。烧写进去可以ping通。 但是连接远端服务器后不能连续发送，必须要等一段时间（100ms）的延时在发，不然跑着跑着程序会挂掉。 于是埋头google、看源码、调试参数、查文档。依然不行，只能解决到延时10ms发送出错后可以恢复。但是2366发送网络报文依然很慢。 折腾了1个星期。 今天终于试了最后一招（其实还有最最后一招），我们的代码是用git管理的。 git reset --hard OLD_VERSION 测试通过。 心态啊、心态。。。 PS： 最最后一招就是我去PORT Micriμm的2378的TCPIP工程。 最最最后一招就是买ZLG的协议栈。 优秀的开发风格和项目管理是做好项目的第一步。
Posted inDebug PowerPC

Freescale MPC8309调试

10/09/2011 第一步是连接仿真器。 打开ltib默认的MPC8309配置，修改 DDR大小为128M NOR Flash为8bit OK，连接上仿真器，仿真器居然没有8309的选项，郁闷，下载了8309的补丁包，EPPC_8.8_830X_b101126.exe。安装，可以选择8309了。又在freescale上瞄了一下，CW8.8.5的patch可以支持win7，这是个好消息，因为之前都是在虚拟机用的，贼不方便。安装好patch，在按照说明装好了驱动，又拿8315的板子连了一下，通过。 好的，连上8309，擦写Flash，显示”连接失败”。新建一个8309的工程，点击Debug->connect，显示无法复位CPU或者无法将CPU置于DEBUG模式，看来是CPU没有正常工作。 郁闷了，检查8309配置，复位配置字为1100，没问题；JTAG设计也没问题；复位没问题；晶振也没问题。最后发现PCI_SYNC_IN没有和PCI_SYNC_OUT连接，导致CPU没有时钟。还好PCI_SYNC_IN通过一个下拉电阻引了出来，不然这个板子就废掉了。 将33M时钟飞到PCI_SYNC_IN上，在次连接一下，成功！擦除Flash，成功！校验Flash，不对。到底是没擦除还是校验错呢？还好Flash上Busy信号接了灯，在擦一下，发现灯亮了，所以应该是校验错误。因为8309和8315是一样的，将8309的NOR Flash配置改成与8315一样。校验成功！ 接着烧写u-boot，改为NOR Flash启动，串口显示启动信息，但是出现”Error in I2C Direction reg read”，搜索u-boot源码，原来freescale公版会先读一个EEPROM。注释掉。 这次显示了”Not a microcode”，然后就在打印NET:后停掉了。跟踪了代码，发现是在初始化QE的UEC的时候执行初始化TX&RX的时候一直没有等到命令执行完成。会不会和”Not a microcode”有关呢。查看源码发现这个是因为u-boot给QE下载微代码的时候打印的，因为我的u-boot是没有这个微代码的。但是后面程序有设置启动微码指令，注释掉。发现还是这个问题。 10/10/2011 难道是QE输入时钟的问题，我们接的是33M的，6倍频到198M。公版是25M，8倍频到200M。而MII的时钟是25M。 换成25M时钟，修改QE PLL倍频，发现还是一样。 会不会是8309必须需要一个微码呢？google、看QE的手册，没有什么可用的资料。在次检索ltib，突然在tools_8309som下面的nor_flashing目录下面发现一个好东西”iram_mpc8309_r1.bin”。哈哈，找到了。用USB TAP烧写到指定位置。”=>”提示符有了。ping了一下地址。发现没有读到PHY ID。…
Posted inDebug

Debug SK2000L

给客户做的一款低端板子，其实就是8241+5*DM9000。之前用的Intel的82551太贵了，而且已经停产。市面上其他网络芯片的厂商基本上也没有PCI总线的网络芯片。 板子到手后，5V、3V3、1V8，测量均无短路。 好的，上电电压正常，烧写CPLD，但是串口打印信息并没有按照想象的出现。问题麻烦了。 重新烧了一块FLASH，换了依然没有打印。 看来要动用重武器了。 测量复位、时钟输入、SDRAM时钟均无问题。看来PLL应该发挥作用了。 接着测量Boot Flash的CS，复位后有波形，但是会一直保持。难道是DM9000前面总线驱动的逻辑错了。 审阅了以下CPLD逻辑，果然有错误，改掉后在量CS，发现每次复位后只出现13次。 这个是不应该的，因为前面读u-boot应该会保持一段时间。拿公司另外一块同平台的板子测试印证了我的想法。 然后给郑州的一位同事电话，希望得到一些提示。结果很遗憾，答曰看启动配置。。。。。 这个是Copy的图，应该是不会有问题的。 难道还是CPLD逻辑的问题？我改了以后又用示波器测了一遍，应该没问题的啊。不会是开始烧坏了吧。算了，还是把不用的逻辑禁掉吧。 奇迹出现了，久违的启动信息出来了。看来就是逻辑问题。   接着配置了一路DM9000，probe成功，发送超时，cat /proc/interrupts无中断，量中断管脚是有的。怀疑是发送设置定时器，结果没有中断清除定时器。改回并行中断，ok。在改回去串行中断，ok。估计是'/IRQ1/S_CLK'在拷逻辑的时候忘了加反向。 之后5片DM9000全部找到。   TODO：u-boot下无法配置RCS2，准备飞线将RCS1和RCS2对调。   Added on 08/01/2011 PS: 悲剧，今天测量网卡速度只有30Mbps。
Posted inDebug

BUG Fixed：中断上下文申请内存

今天客户反应我们的驱动在运行中还是会Oops，奇怪了。因为这个驱动我们之前是在我们自己的一个板子上做的，稳定性之类的已经验证过了，虽然现在的运行环境不是我们自己的版本，既然驱动正常加载，怎么还会出问题呢。 下面的是Oops信息： BUG: scheduling while atomic: swapper/0/0x40010100 Modules linked in: drv Pid: 0, comm:              swapper CPU: 0    Not tainted  (2.6.33.5 #19) PC is at __rcu_process_callbacks+0x68/0x3a0 LR is at __rcu_process_callbacks+0x68/0x3a0 pc…
Posted inCF-Card Debug PowerPC

CF-Card拷贝出错——续

终于解决CF卡出错问题了。先记录如下： 当我在板子上面对主机的文件进行MD5校验的时候惊奇的发现同一个文件在板子和主机上面居然MD5也不一样。主机的目录是用NFS mount到板子的。那么就有可能有2个原因： 网络错误 内存错误 NFS服务我是相信的，不然不可能用的这么广泛。那么只有一个可能，内存有问题。 于是换了一个板子。mount后md5文件，与在主机的MD5值一样。好的。这事内存问题。那么拷贝文件出错是不是也是内存影响的呢？ 重新拷贝，md5sum后发现与主机一样。KO。搞定了 做了一夜的拷贝、md5sum、删除，CF卡都依然坚挺。看来是内存问题了。折腾了我好久。郁闷～～～～～ 手头还有一个Kingston的256M的CF卡，插上去试试，发现在分区保存的时候打印下面的错误： hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error } hda: task_no_data_intr: error=0x04 { DriveStatusError } hda: Write Cache FAILED Flushing! 呃。难道还有问题。…