How to "loopback test" ethernet and USB?

[peter-h]

I have a board, ST 32F417. It all works.

I am writing some factory test code. Is there some way to do "loopback" on these subsystems? I realise that if it gets as far as getting DHCP, ETH is "probably ok", and if USB works for the MSC and CDC devices, likewise. But is there some more rigorous way of testing it? Particularly in light of some earlier posts about the LAN8742 and 25MHz/50MHz clock stuff "forum controversy" (using the uC to generate the 25MHz and the LAN8742 feeding back the 50MHz).

Like one does loopback tests on serial ports.

[rstofer]

You can ping your own IP address if ping is implemented.

Otherwise, open a TCP Berkeley Socket connection to a printer (my HP Laserjet works for this) and send a test page of any kind.  There's a lot of networking involved with opening up a Berkeley Socket, sending data, printing and, finally, disconnecting.  The code is all over the internet and it's pretty trivial.

[rfclown]

For ethernet I've used iperf which will show you the speed.

[mikeselectricstuff]

For ethernet you should be able to loop your tx to rx and send yourself UDP packets. or raw ethernet frames.

[peter-h]

How would one get into the ST ETH code at a low enough level to do that?

[Jeroen3]

Ethernet you can attach to a small router/switch, dump a load of packets and just look at the error counters.
You can probably telnet the counters from a mikrotik, which provides many stats.
There is also a traffic generator, never used it though.

USB just use a 5 meter cable. If it's bad it won't work.

[m k]

How would one get into the ST ETH code at a low enough level to do that?

Can you PING?
If so use broadcast address.

[Cerebus]

Well you could try opening the data sheet for the LAN8742 (presuming that is the PHY chip you're using, you mention it but you don't actually say) search for the word "loopback" and you'll find both the control register bits to enable near and far end loopback modes, and descriptions.

USB being having an intrinsically master/slave relationship between hosts and devices it isn't really possible to do a meaningful loopback test. I suppose some USB PHYs may have some sort of loopback-like test mode but I've never looked for or noticed one.

And of the responders, only mikeselectricstuff seems to understand what "loopback" means. It means, usually physically, looping the communications medium back on itself so that anything you send out as a transmission comes immediately back to you, unaltered, as a receive signal. This enables you to do a simple bit by bit test that you're receiving what you send, or calculate statistics like bit error rate on the raw physical medium. You can have near-end loopback, where you make the loop at the outbound interface on a device, and far-end loopback, where you make the loop at the distant end of a circuit or at progressive points on the way to the distant end. The whole point is to enable one to test the physical connection without getting any other systems involved (e.g. pinging) as you have no way of knowing if they are operating correctly.

Sometimes referred to as hairpining* because a crude way of doing it was to borrow a hairpin from a secretary and physically stuff the ends of it into a comms device's socket's tx and rx pins - not recommended. For 10/100Base-T Ethernet on RJ45s you can wire a plug to cross the receive and transmit pairs. (Gigabit ethernet gets more involved at the signalling level and switches have OAM modes to provide loopback, not quite as satisfactory as literally testing just the wires in the way a classic physical loopback does.) Most Ethernet PHYs will have a test mode where you can command the PHY to cross connect its tx and rx paths just before they leave the chip.

Loopback plug


For telecoms E1 links (i.e. PDH) and similar on standard coax patch panels there were/are 'U-links' made specifically to allow the adjacent tx and rx connectors to be joined to form a far-end loopback. In fact it was standard practice to leave a physically ready, but not in-service, circuit with a U-link in place so that the remote end could test the circuit without it having to be fully commissioned (seeing a far-end loopback was also a hint that the far-end hadn't been commissioned and it was time to kick somebody to finish patching it to where it was supposed to be going).

U-link


*Not to be confused with hairpining traffic in voice networks which refers to erroneously routing traffic back to its originating network.

[peter-h]

Yes, LAN8742, but it connects to the reduced ETH interface on the 32F417 and doesn't appear to be directly accessible. I will look into this. Maybe there is a pass-through mode.

[mikeselectricstuff]

If you're doing production test, internal loopback is of little value as it doesn't test the magnetics or connector connections.

[Cerebus]

Yes, LAN8742, but it connects to the reduced ETH interface on the 32F417 and doesn't appear to be directly accessible. I will look into this. Maybe there is a pass-through mode.

It should be accessible over the Station Management Interface (SMI, pins MDC and MDIO of the MII/RMII interface) which lets you read and write the PHY's control registers. See the STM32F417's reference manual entries for the Ethernet MAC MII address register (ETH_MACMIIAR) and Ethernet MAC MII data register (ETH_MACMIIDR) and the PHY documentation for the SMI register map.

How easy those are going to be to access without messing everything up is highly dependent on the middleware you're using to control the ethernet interface.

The MII (Medium Independent Interface) and RMII (Reduced MII) interfaces are standardised, and you might help yourself by reading the standards. See IEEE 802.3 subsection 22 et seq. RMII is just an electrical variation of MII, logically the two interfaces are equivalent.

22. Reconciliation Sublayer (RS) and Media Independent Interface (MII) 22.1 Overview
This clause defines the logical, electrical, and mechanical characteristics for the Reconciliation Sublayer (RS) and Media Independent Interface (MII) between CSMA/CD media access controllers and various PHYs.

As Mike says, if this is for production board level test, then a physical loopback the other side of the physical interface is where you want to be looking. However, if this is for operational self-test then loopback at the MII level is useful as a confidence test while booting the system/running diagnostics.

[mikeselectricstuff]

As Mike says, if this is for production board level test, then a physical loopback the other side of the physical interface is where you want to be looking. However, if this is for operational self-test then loopback at the MII level is useful as a confidence test while booting the system/running diagnostics.

For production test, use physical loopback. For debugging production test failures, local loopback can be useful to figure out where the problem is.

[peter-h]

Often it is a matter of how much non-repairable scrap you are happy with.

If you are happy with say 1% then you can just chuck away any board with duff ETH, and not worry about whether it is the PHY, or the (cheap chinese - the German made ones from Würth cost 5x more and I don't know who uses them) RJ45 with integrated magnetics. The LAN8742 can be replaced, with a bit of work, but is not actually likely to be faulty. The RJ45 is almost impossible to unsolder.

I always implement loopback on serial ports; that's easy. But perhaps doing it on ETH and USB is not worth the trouble - if these interfaces actually function in the normal way.

At work we find a 40x microscope finds most faults and what it doesn't find is not worth repairing. Then, after 10 years, you end up with a box containing about 4 digits' worth of boards and you wish they could be recovered

[janoc]

To folks talking about using ping - I strongly suggest you check how your TCP/IP stack is implemented. You will likely discover that the stack "sees" you are attempting to ping own own address and will simply generate the reply directly, without the packet ever leaving the kernel. I.e. no networking hardware will be tested whatsoever.

Also, this assumes:

• The application actually has a full blown OS with a TCP/IP stack running. Given the micro in use, this is unlikely, also production testing fw may not be full featured. Also ethernet does not imply the device  actually does TCP/IP in the first place
• That there is a ping command and something to execute it available (ok, you can probably craft ICMP packets by hand but see above)
• That you have a configured and working network attached, with some devices that can actually reply back on it (for the ping broadcast address idea) - unlikely during production testing

I.e. this suggestion is not usable for the OP at all.

[mansaxel]

I would say, first, that mikeselectricstuff and Cerebus nailed it. Do what they suggest and you'll likely be fine.

If you want to use an active network connection for a more "holistic" test, which was also suggested, then I would run either against another test computer or a more competent Ethernet switch. 

The computer needs to be running some kind of manageable OS where you have access to the Ethernet card driver and statistics, and then you look, in that end, for packets arriving and if the broken frames across a crossover cable are less than 1ppb or so it's probably working. What you can't test for, in that end,  is the RX part of the DUT, so you must ask the DUT what it thinks too. 

If you put a switch in the mix, it probably needs to have some kind of management control, and also an API. The classic of course is SNMP; which would let you set the switch up for next DUT (clear counters et c.) and then poll packet and error counters as well as it trap'ing you with "link connected" messages that could be useful in test automation.

It might be that you want to combine, and have a switch and a computer. Then it is important that all nodes involved are at the same link speed, or there will be trouble. Even very expensive Ethernet switches need careful deliberation to not drop packets if they are to speed convert. OTOH, most Ethernet switches actually manage to switch as long as they don't need to queue packets to pace them out on a slower port.

[hans]

Also concerning USB.. it's not easy to do a functional loopback test. I suppose you could echo back data from one endpoint to another, but it would require setting up the device descriptors in such a way that it allows you to do that.

If it's a USB 12Mbit/s device, I would just make sure that the device enumerates. That's all. In that case you know the device can pull-up the USB data lines for enumeration, transmit/receive tokens and has the oscillators set right for communication. 12Mbit/s USB speeds is pretty robust.

At 2.0 speeds or greater my first go-to method is similar to as @Jeroen3 suggests. Use a long USB cable and see if the connection stays up for a little while. Maybe, if you can, send it large packets to see if the connection doesn't drop suddenly. But IME those tests are getting on the border of engineering verification, because if there are a lot of devices dropping out with random boards/cables.. then probably the design is not right in the first place (or you got some really bad quality cables).

[wek]

Also concerning USB.. it's not easy to do a functional loopback test.

But also maybe not necessary.  If mcu-to-connector continuity and shorts test is all what is needed, it's enough to set DP/DM to GPIOs and plainly loop them back.

A suitably chosen capacitor to ground may perhaps serve as a rudimentary test for value of the series resistors, if this is needed.

The STM32F417 has two USB ports capable of being both device and host, so a full-fledged loopback is possible if both are brought out to connectors - but I personally don't think it's worth it.

JW