Ethernet Loopback Test

[danh]

I am trying to find a way to do a loopback test of the ethernet port on our target board. Ideally I would like to do this with just a loopback connector on the ethernet interface, and not require any external active device to be connected.

What I am seeing is that, when running in the simulator, the application can send a broadcast UDP frame, then receive that same frame. But when running on the target board, it definitely sends the frame (I can see it in Ethereal) but does not receive it.

I have the unit send a broadcast UDP frame, using IP address of 255.255.255.255 (using fnAddARP() to add something to the arp cache so the UDP send function does not try to arp it and fail). A UDP receive task is setup to see this frame, and currently, to send a 'response' frame (also a broadcast frame).

Here is the code to send the 'request':

Code: [Select]

   unsigned char ip[4] = {255, 255, 255, 255};
   unsigned char mac[6] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
   UDP_MESSAGE udp;

   uStrcpy((CHAR *) udp.ucUDP_Message, "Request");

   fnAddARP(ip, mac, ARP_FIXED_IP);
   fnSendUDP(socket, ip, A32_TEST_SERVER_PORT, (unsigned char *) &udp + 2, uStrlen((CHAR *) udp.ucUDP_Message), OWN_TASK);

And here is the code to receive the 'request' and send a 'response':

Code: [Select]

extern void test_svr(TTASKTABLE *ptrTaskTable) {

   if(!((socket = fnGetUDP_socket(TOS_MINIMISE_DELAY, udp_listener, (UDP_OPT_SEND_CS | UDP_OPT_CHECK_CS))) < 0)) {
      fnBindSocket(socket, TEST_SERVER_PORT);
      ptrUDP_Frame = uMalloc(sizeof(UDP_MESSAGE));
   } else {
      return;
   }
}

// UDP data server - reception call back function
//
extern int udp_listener(USOCKET SocketNr, unsigned char ucEvent, unsigned char *ucIP, unsigned short usPortNr, unsigned char *data, unsigned short usLength) {

   unsigned char new_ip[4] = {255, 255, 255, 255};
   unsigned char new_mac[6] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};

   switch(ucEvent) {
      case UDP_EVENT_RXDATA:
         if(uMemcmp(data, "Request", 7) == 0) {
            fnAddARP(new_ip, new_mac, ARP_FIXED_IP);
            uStrcpy((CHAR *) data, "Response");
            usLength = uStrlen((CHAR *) data);
            fnSendUDP(socket, new_ip, TEST_SERVER_PORT, (data - sizeof(UDP_HEADER)), usLength, OWN_TASK);
         }
         break;
   }
   return 0;
}



This works fine in the simulator; the frame gets sent, and the UDP receiver task sees the frame and then sends a similar but slightly different frame. When I run on the target board, it never sees the 'request' frame that it sent. If I run my target board AND the simulator on the same net, the target board receives the 'response' frame from the simulator, but not from itself; the target board does not see its own 'request' frame.

Maybe this just means the ethernet interface is running in half duplex mode? I'm not sure what determines that; the target and the PC running the simulator are connected to the same hub.

Anyone have any other suggestion for testing the ethernet port with a minimum of external hardware?

[mark]

Hi

First to the simulator behaviour: I think that this is not correct and it shouldn't really see its own transmissions (at least not in normal mode). Changing the ordering of the following lines in fnCheckEthernetMode(), in M5223X.c, should correct this:

if (!(uMemcmp(ucData, cucBroadcast, MAC_LENGTH))) return 1;        // accept all broadcasts
if (fnIsOurMAC(&ucData[MAC_LENGTH])) return 0;                               // reject own frames
This is accepting all broadcast, irrespective of whether they originate internally.

if (!(uMemcmp(ucData, cucBroadcast, MAC_LENGTH))) return 1;        // accept all broadcasts
if (fnIsOurMAC(&ucData[MAC_LENGTH])) return 0;                               // reject own frames
This will reject in your test case (as the HW does).

The PHY has a looback mode (LOOPBACK bit in EPHY control register) but I don't think that this is what you want to use since it is an internal loop and so isolated from the board's interface - HW problems like a broken track will not be detected. [More useful for testing SW].

Production testing is probably best performed by connecting the Ethernet interface to a switch or hub to ensure that the autonegotiation works correctly. I imagine that the switch will be in a network, so why not simply ping a PC which is always present (and doesn't have ping responses deactivated)? The PING_TEST in debug.c will send to a given IP address (no need to deactivate ARPs since they will not disturb) and will give an answer as to whether a PING response was received, whether there was no answer or whether the destination could not be resolved. A successful response indicates that the test worked and the board's interface is OK. An error indicates that there is probably a HW problem at the interface.

[Note that the default IP configuration of the board will need to match the local network]

Regards

Mark

[danh]

Hi Mark,

Thanks for your fast response...

This test will be performed by a contract manufacturer overseas, and it is desirable to keep the requirements as simple as possible. It would be great if the test can be performed anywhere by simply plugging in the loopback connector, applying power, and waiting for the test to finish and the result to be displayed on some LEDs, without requiring any other test infrastructure. This is the goal anyhow.

If the unit could be connected to a network with some known host on it, as you suggest, that would work fine. But if more than one unit could be tested at one time, each would have to have some unique network settings, and that would be another complexity.

Another way, which we will probably use, is to require a 2nd of the devices, and have the two connected together with a crossover cable. The 2nd unit could either be a unit under test, in which case if the ethernet test failed it might not be known which unit was responsible. Or the 2nd unit could be a known good unit that is just used for testing. In any case, with only two units involved, the network settings don't have to be unique. A unit sends a 'request' broadcast frame when it does its own test, and only sends a 'response' broadcast frame when it receives a 'request' frame from another unit; the individual MACs and IPs don't matter. (After a unit runs its test, it just sits there and can still send the UDP 'response' frame.) This method is working now, at least with the simulator being one of the two units (I don't have a 2nd piece of target hardware at this moment to try).

But it would be nice to avoid this and just use a loopback cable...

Regards,

Dan

[mark]

Dan

I just did some tests.

1. If you use a loopback cable (lines 1 connected to 3, and lines 2 connected to 6) the transmitted data will be looped back to the receiver (nothing new).
2. The first versions of the M5223X have some problems with autonegotiation and I don't think that it can autonegotiate with itself (I couldn't get a link with the cable although it worked with somem other processor/Ethernet types).
3. I configured to 100M fixed and then the link went up with this cable connected (looking better).
4. Transmitted frames are however not received when not in duplex mode, therefore I configured also for duplex (all configuration via the "Configure LAN interface" web page or via UART in the uTasker demo project).
5. Now it received its own transmissions. I activated the TIME_SERVER demo so that it would automatically try to contact a server in the Internet. This started off by trying to resolve the default gateway by sending ARPs.
These are received and rejected by ARP rx since the IP address is not equal to the local one, however this is counted in the Ethernet statistics.
6. Via the serial interface I request the IP stats (menu 5, then "ipstat"):
#ipstat
Ethernet Statistics

Total Rx frames = 32
Rx overruns = 0
Rx ARP = 0
Rx ICMP = 0
Rx UDP = 0
Rx TCP = 0
Rx checksum errors = 0
Rx other protocols = 0
Foreign Rx ARP = 32
Foreign Rx ICMP = 0
Foreign Rx UDP = 0
Foreign Rx TCP = 0
Total Tx frames = 32
ARP sent = 32
ICMP sent = 0
UDP sent = 0
TCP sent = 0
Other events = 0

This is about 20s after reset and the attempt to contact the server (ARPs) is repeated several times and finally gives up after a minute or so after 100 ARPs have been sent and received.

#ipstat
Ethernet Statistics

Total Rx frames = 100
Rx overruns = 0
Rx ARP = 0
Rx ICMP = 0
Rx UDP = 0
Rx TCP = 0
Rx checksum errors = 0
Rx other protocols = 0
Foreign Rx ARP = 100
Foreign Rx ICMP = 0
Foreign Rx UDP = 0
Foreign Rx TCP = 0
Total Tx frames = 100
ARP sent = 100
ICMP sent = 0
UDP sent = 0
TCP sent = 0
Other events = 0

If the test is repeated without the loopback cable attached (equivalent to bad HW) I get the following after about 5s:

#ipstat
Ethernet Statistics

Total Rx frames = 0
Rx overruns = 0
Rx ARP = 0
Rx ICMP = 0
Rx UDP = 0
Rx TCP = 0
Rx checksum errors = 0
Rx other protocols = 0
Foreign Rx ARP = 0
Foreign Rx ICMP = 0
Foreign Rx UDP = 0
Foreign Rx TCP = 0
Total Tx frames = 7
ARP sent = 7
ICMP sent = 0
UDP sent = 0
TCP sent = 0
Other events = 0

Here it is seen that several ARP messages have been sent but no response to any was seen.
If the cable is plugged in and out, the link up/downs are counted under "Other events" - the link up/down event can also be used by a test program of course.

I think that such a test is also adequate to verify that the HW is good - the ARP messages are just a valid as UDP or TCP etc.

The 100M, duplex setting is not a very good default configuration so it may be an idea to read a port on reset to see whether the test mode is required and only set this configuration when specifically required - otherwise use the standard configuration.

Therefore I think that you can achieve the goal of no extra infrastructure to achieve releiable HW test of the Coldfire Ethernet connection.

Regards

Mark

[danh]

Mark,

Thanks for taking the time to try this.

Yes, I just modified ethernet.c so that, only for my 'test' build, it ignores the settings and configures the ethernet port for 100M and FULL DUPLEX. I understand what you say about looking at certain stats to see whether the loopback is working or not, but since I already have this UDP test, and it gives instant gratification, I will just use that. The test passes with the loopback connected, and fails when it is not connected. It also fails when just connected to the hub; not sure I understand why sent frames are echoed in the simulator but not on the target, but this is not important. Now I have exactly what I wanted.

Thanks again.

Dan

PS. We are definitely using uTasker for our project; I put in a requisition a few days ago, and even at our small company it takes few days or a week to get it through...

[mark]

Dan

Yes, since you already have specific test code there is no reason why this can not be used...

The simulator uses WinPCap and this 'sees' transmitted and received frames (irrespective of line characteristics and settings) so the simulator needs to actively ignore the rx frames (SW filtering) depending on the embedded Ethernet settings to be totally accurate - this is quite a detail and normally not relevant.

Regards

Mark