12/28/2023 0 Comments Ethernet phy loopback test![]() In any case, with only two units involved, the network settings don't have to be unique. Or the 2nd unit could be a known good unit that is just used for testing. 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. 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.Īnother way, which we will probably use, is to require a 2nd of the devices, and have the two connected together with a crossover cable. If the unit could be connected to a network with some known host on it, as you suggest, that would work fine. 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 test will be performed by a contract manufacturer overseas, and it is desirable to keep the requirements as simple as possible. An error indicates that there is probably a HW problem at the interface. A successful response indicates that the test worked and the board's interface is OK. 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. Production testing is probably best performed by connecting the Ethernet interface to a switch or hub to ensure that the autonegotiation works correctly. 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. This will reject in your test case (as the HW does). ![]() This is accepting all broadcast, irrespective of whether they originate internally. ![]() If (fnIsOurMAC(&ucData)) return 0 // reject own frames If (!(uMemcmp(ucData, cucBroadcast, MAC_LENGTH))) return 1 // accept all broadcasts Changing the ordering of the following lines in fnCheckEthernetMode(), in M5223X.c, should correct this: 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.Īnyone have any other suggestion for testing the ethernet port with a minimum of external hardware?įirst 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). 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. When I run on the target board, it never sees the 'request' frame that it sent. 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. Code: extern void test_svr(TTASKTABLE *ptrTaskTable) įnSendUDP(socket, new_ip, TEST_SERVER_PORT, (data - sizeof(UDP_HEADER)), usLength, OWN_TASK)
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |