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 inPCB Layout

DDR设计

AT91SAM9G25 DDR2布线规则 首先，DDR离CPU越近越好。很长的走线会增加信号的上升时间和下降时间。CPU发起的信号建立时间也会因为走线长度的增加而减小 保证DDR的时钟和控制线越短越好 保证DDR的地址和数据线越短越好 对于工作在133MHz的DDR2，线上的阻抗匹配是必须的。10－30Ω的串联电阻可以放置在所有的转换信号以限制过流。这个电阻需要靠近CPU放置。是否需要终端电阻以及它的特性最好使用仿真来决定，使用IBIS模型和特定的PCB layout。在SAM9G25上，采用的是27Ω的串联电阻。 为支持最大速度，必须遵守合理的DDR2负载。对于高速操作，地址线和数据线的最大负载不能超过30pF，SDCK和#SDCK为10pF。用户必须考虑接在不同总线上的所有器件，来计算系统的总负载。 MPC8315 DDR2布线规则 建议的布线顺序：1) DATA, 2) Address/Command, 3) Control, 4) Clocks, 5) Power 阻抗匹配 单端阻抗 ＝ 50 - 60Ω（MDQ, MDM, Address, Command, Control）…
Posted inDebug

pppd拨号出错

修改dialer文件，通常位于/etc/dialer。在char一行中增加-s参数，如下： [crayon-682420401a418387894613/] 其中，-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 inCrossCompile

Cross-compile iptables

今天编译了iptables着实令我郁闷了一下。 我们的kernel用的是linux-2.6.36-rc2。由于历史原因，客户应用层使用的编译器和我们编译kernel的编译器不一样。 结果就很悲摧： iptables v1.4.12.1: can't initialize iptables table `filter': Invalid argument Perhaps iptables or your kernel needs to be upgraded. 查了一下bing，从什么大之前开始google就一直在抽风。 找到了一个更加令人悲摧的地方：http://www.iptables.info/en/iptables-problems.html This is a bit more serious since…
Posted inCrossCompile

Cross-compile vsftpd

下载vsftp源码 然后修改Makefile，将CC修改为$（CROSS_COMPILE)gcc 编译即可。 默认vsftpd需要PAM支持。如果使用busybox做rootfs的话支持PAM比较麻烦，可以将sysdeputil.c文件中关于“pam_”开头的函数调用全部删除。然后重新编译。 编译最后会出现如下错误： arm-linux-gcc -o vsftpd main.o utility.o prelogin.o ftpcmdio.o postlogin.o privsock.o tunables.o ftpdataio.o secbuf.o ls.o postprivparent.o logging.o str.o netstr.o sysstr.o strlist.o banner.o filestr.o parseconf.o secutil.o ascii.o oneprocess.o…
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 inMicriμm

uC/TCP-IP分析

不管在使用socket的任何时候出现了以下任何一个严重的错误代码，socket必须立即closed()。 NET_SOCK_ERR_NOT_USED NET_SOCK_ERR_INVALID_FAMILY NET_SOCK_ERR_INVALID_PROTOCOL NET_SOCK_ERR_INVALID_TYPE NET_SOCK_ERR_INVALID_STATE NET_SOCK_ERR_FAULT
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 inCrossCompile

Cross-crompile minicom

minicom需要ncurses，如果你的交叉编译环境自带的话会省很多事情。否则需要先编译ncurses。 不然会出现如下的错误信息： [crayon-682420401a895169938772/] 从http://www.gnu.org/software/ncurses/ncurses.html下载ncurses [crayon-682420401a898153730199/] 因为我们指定了prefix，ncurses会到错误的地方(prefix/share/terminfo)找terminfo。执行minicom的时候就会出现如下的错误信息： No termcap entry for vt102 所以需要修改TERMINFO默认寻找路径。 [crayon-682420401a899226992233/] 修改TERMINFO_DIRS和TERMINFO宏为"/usr/share/terminfo" [crayon-682420401a89a017557527/] [crayon-682420401a89b216265434/] 从http://alioth.debian.org/projects/minicom/下载minicom [crayon-682420401a89c490472295/] [crayon-682420401a89d144536854/] 就可以获得minicom 最后拷贝libncurses.so到/lib，拷贝文件/usr/share/terminfo/v/vt102即可。