Trouble bringing up embos/IP

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • Trouble bringing up embos/IP

    I need some help bringing up embos/IP on my custom board. This is based on the AT91SAM9260 but with a National DP83848C PHY instead of Davicom. In a nutshell, I see that the a link is established and some connections can be made, but communication fails eventually. The failure is associated with the host resending a lot of packets and the embedded system eventually timing out. When I test with the simple server, the symptom is that some keypresses do nothing, and others work. When one does work, then output corresponding to the missing responses comes out. So maybe I hit enter twice and nothing happens, then on the third time I get three responses. When testing with the speed test, a connection is made with the server and some data is sent across, but there are gaps of many seconds and eventually the server says that the client disconnected.

    Can someone suggest some things that I can look at to narrow the source of the problem ? I have a stack-log text file showing much debug output from the speed test client when it is trying to connect to the speed test server. Also a matching packet log on the PC side. The forum will not allow me to upload these. There is a direct cable connection from the embedded system to the PC running the speed test server and packet sniffer, with no other devices on that network. The PC is and the embedded system

    I am running this with embOS 3.62a1 and no other tasks running except for the three IP tasks. embosView shows very low processor utilization. I based my port on the Segger-supplied IP_NI_AT91SAM9260.c driver. In IP_X_Config I gave the stack 0x10000 bytes with default assignments for buffers. The docs mention IP_NI_SAM9260_ConfigNumRxBuffers but it looks like a call to that is not necessary as it has a default assignment. I left tx buffers in internal SRAM at 0x200000 and rx buffers in SDRAM. I added some counters to see how many packets are received at the interrupt level (9) and sent (10). netstatic.mib shows all 0 except iflnUcastPkts = 6.

    Edit: Since posting I found a hardware problem affecting the RMII clock signal fidelity. Fixing that resolved a high rate of error on ethernet packets, which was at the root of this problem.

    The post was edited 1 time, last by gpontis ().