uIP调试之ping、arp与死机

         话说博主我这几天被uIP整的可以说焦头烂额，出了不少问题，在此小结一下。

         也是最近一个月才接触使用stm32+DM9000AE组成的百兆网络，与之前enc28j60比起来算是高大上了。uIP在实现TCP server、TCP client、UDP server、UDP client等很方便，一个月前做了块数据转换的板子，使用了一个UDP client，连上电脑OK，没问题，可以正常发出数据，本以为大功告成，便将之束之高阁。可最近产品联调前，发现怎么也ping不通这个小东西，也偶尔有一两次回应，虽然能正常发数据就可以了，但对于一个网络设备来说ping不通怎么好意思！查了好一会儿发现不能正常收数据，只能发数据，说明ARM对DM9000的读写是有问题的，仔细查看代码，原来是FSMC总线配置函数DM9K_FSMCConfig()中的三个关键参数：

         p.FSMC_AddressSetupTime= 3;//3                 

         p.FSMC_AddressHoldTime= 3;//

         p.FSMC_DataSetupTime= 4;//4

时间设置的有问题！这指的是地址建立时间、地址保持时间以及数据建立时间不匹配造成的。在PCB布线时，数据线地址线和控制线的长短与这些参数紧密相关，为了减少数据传输错误，还特意设计了等长蛇形线，这样看来还是无法避免，针对不同的硬件还得调整这些参数。由于手中没有很好的示波器，无法观察这些信号时序上的差异。看DM9000手册上读写时序图

在此地址作用的是CMD信号，IO16是数据信号，FSMC速度在100M时，一个时钟的时间是10ns，由上图看到地址建立时间不小于5ns，地址保持时间不小于27ns，数据建立时间在5ns，也就是说最理想的状态参数应该是1、3、1就可以了，但觉得实际上还是需要在此基础上进行调整，经过几次尝试，发现为3、3、4的时候就可以ping通，说明此时可以正常收数据了。

         第二个就是使用UDP广播时ARP的问题。由于我的转换板需要在整个子网段内广播数据，比如设置远程ip为192.168.1.255，掩码为255.255.255.0时无法广播，使用wireshark抓包看竟然一直在发送arp包!而将远程IP设置为全255时候才能正常广播UDP数据包，这显然是不正常的。仔细研究uIP的arp机制，发现

         在UDP发送数据时候先要对比目的地址是否为广播包，如果是广播包就直接发出去而不进行arp询问，如果不是广播包就先查找arp table中是否有这个IP地址的MAC地址，如果没有，就发送arp询问对方的MAC地址，如果arp table中有这个MAC地址就直接填充并发送出去。问题就出现在判断是否为广播包上，看到broadcast_ipaddr地址只设置为全255地址才认为是广播地址，这是不科学的，做以下修改就可以更正此问题，子网段广播就正常了

#defineuip_broadcast_addr_cmp(addr1, addr2) (((((u16_t *)addr1)[1])&0xff00) ==((((u16_t *)addr2)[1])&0xff00))

         最让我郁闷的就是今天的调试。明明在办公室调好的板子，放到系统里运行2秒就死机！可是带着仿真器调试就一切正常，让我忙了一个上午也不得其解。通过尝试修改软件和硬件都无法解决，后来仔细想想应该是硬件上的问题，不应该去修改软件。但是对于硬件的调试绝对不能盲目，上网查有几个可能的原因，一是电源问题、二是复位问题、三是晶振问题。可是都一一排除。之后遇到相似问题几点作为参考：

         ①检查电源和复位电路，先排除基本问题

         ②将原正常系统复原对比差异。于是找来一个单独电源给板子供电就没问题了！难道是系统内其他设备对其干扰？

         ③断开原系统内其他设备，只给板卡单独供电，问题依旧存在，说明并不是系统内其他设备的干扰，那么是系统电源的问题？

         ④断开系统电源，将独立电源接入系统给板卡独立供电，问题仍然存在。到这一步就很明显了，为什么同样的电源和板卡在系统外和系统内就有这么区别呢。肯定是系统内线路有问题，最终发现是板卡接头处连接了一个U转串，而U端是悬空的！将这个根调试线拔了就一切正常。应该是U转串内部芯片在没有初始化时候输出了错误电平，在单片机初始化串口后造成的硬件错误导致死机的。

         问题往往就是这么低级，却很难被发现。还是做个有心人吧。