Other Parts Discussed in Thread: C2000WARE
Hi,
My team have a proprietary PCBA with a F28388D microcontroller and an Ethernet PHY on it. We wanted to use the DP83822 PHY (just like the one on the controlCard) but it was sold out at the time, so we substituted it for a DP83826E. We have no issues reading from and writing to the registers in the PHY chip, however we cannot successfully perform a MII loopback. We tried to run the C2000Ware F28388D example project, ethernet_ex2_phy_loopback, on our custom board but it always failed without receiving a good packet. The controlCard had some issues with the wait time (to be explained at the end), but after a slight variable tweaking, the MII loopback project ran perfectly on the controlCard. We are baffled because at first glance, the two PHYs are very similar. More specifically, the Basic Mode Control Register for both the DP83822 and the DP83826 are located at the same address and contain the same fields at the same bit locations. But despite the familiar programming interfaces, the example project only passed for one and not the other. However, we have confirmed that the internal loopback example, ethernet_ex1_basic_tx_rx_loopback, does work (once again with increases to the wait time) with our proprietary board.
So far we have followed the tables and instructions provided by the DP83826 datasheet to the best of our ability, but it is to no avail. Therefore, we would like the TI staff to help us by providing some concrete example code on how do MII loopback on the DP83826E PHY with a F28388D microcontroller. If it is of any relevance, we also use a 25MHz clock signal for PHY just like in the controlCard and we are using BASIC mode Ethernet only.
P.S.: The SysCtl_delay() value to wait for the packets to return is too short even in the internal loopback example. I had to increase it to at least 6000 cycles from 3000 cycles in order to not have issues with receiving the returning packets.
UPDATE1:
We disconnected the PHY RX_ER pin from the microcontroller GPIO pin muxed as the ENET_MII_RX_ERR signal and then ran the MII loopback example.
This time it passed. However, this is a less than ideal solution as it is comparable to putting a penny in a fuse box to get the all the high power house appliances to run at once.
But this does help narrow our search as we are now looking as to how the RX_ER might have been asserted during the operation of our custom board.
Of course, we would gladly welcome any help from TI in finding the cause of the RX_ER assertion.
UPDATE1_EDIT: I would like to correct my earlier statements. There was no way to actually physically disconnect the PHY RX_ER pin from the microcontroller. Instead, my teammate simply did not mux any pin to act as the Ethernet receive error pin.
UPDATE2:
We attempted to performed an external loopback using a segment of Ethernet cable that we cut apart and shorted certain wires together. We then ran a modified version of the PHY MII loopback project where we don't change any PHY registers so all the packets go through all the stages of the PHY and on to the cable line. The controlCard had no issue with receiving its own packets sent over this loopback cable segment. However, our own proprietary board experienced a strange phenomenon where we don't receive any good packets yet we are not getting any receive errors either (and yes the GPIO pin serving as ENET_MII_RX_ERR was re-enabled to serve that function).
As of this post, all hardware diagnostic attempts so far indicated that there is nothing wrong with the board. If the issues are indeed firmware or PHY register related, then we currently have no idea of what needs to be done to get this PHY to work with the MCU as there dozens of configuration variables for the Ethernet module and at least 17 of the 32 standardly addressed PHY registers have some writable bits in it.
