AM4377: EtherCAT issue on custom board

Liliane,

Have you done any diagnostic/sanity check to confirm the ethernet port work properly?

You may try to disable the 'enhanced link detection' to see if helps. The MDIO/PHY app note may help - 

Regards,

Garrett

Dear Garrett,

Thank you for the reply.

I have already checked this application note.
Maybe the following info can help you to understand where I am stuck at.
1) Run the demo app on IDK Dev board to make sure app + TwinCAT are configured correctly and the TwinCAT Ethernet adapter is working properly
2) Adapt the demo app according to my custom hardware:
- Change the PHY addresses in board_phy.c according to the hardware (we have them configured as 1 and 2 instead of 0 and 1, but since these addresses will be mapped to 0x54400e08/09 (TI ESC register) anyways, I think it should not be relevant)
- Change the PHY reset function in board_phy.c according to the DP83848M datasheet: I am pretty sure that the PHYs are reset correctly, as reading the ID1 register gives me back 0x2000 as expected
- Change the files board_tlk105.c/h, board_tlk105.c and tiescphy_tlk105.l (into new files) according to the DP83848M datasheet
- Turn off the enhanced link enable function (if I leave it turned on, the corresponding bit on MDIO register MDIO_LINK of PRU_ICSS1_PRU1 stays on 0, if I turn it on, it gets set which probably means that the link only gets detected when I manually set the link polarity)
- Replace the LED output with debug prints (not relevant)

I had a look into the MDIO register of PRU_ICSS1_PRU1 and saw that both of my PHYs are recognized as alive. Together with the fact that I can successfully read back the PHY_ID1 registers, I assume that the PHYs are working properly.

In order to understand better from which point the TwinCAT master is able to detect the slave, I connected the dev board via JTAG and noticed that the slave is recognized after writing the register permissions (w/o writing these, the slave does not get recognized)), loading the firmware to the PRU ICSS, and enabling the PRUs.
Also, the Link LED which is configured to indicate a good link when it is turned on.
Within TwinCAT, I tried to manually add a master with a AM437x slave and send some frames via emergency scan. All the frames are lost, and in the master online view I see the state INIT NO_COMM.
If I look at the network connections, I see unidentified network (meaning that a link is existent, otw I would see network cable unplugged) at given Ethernet adapter.

I really don't see any differences between the dev board and our custom board that could be the reason for not being able to detect my device. Our PHY transceiver differs from the TLK105 in the PHY_ID2 register, but this register never gets read by the firmware. Also, I tried it on more than one of our boards to make sure it is not a single board issue, and apparently it is a systematic error. 

Maybe you can answer me the following questions:
- Could it still be an issue of the PHY transceiver  (e.g. unproper reset) according to the observations above?
- Could it be an issue of having different PHY addresses than on the dev board despite the fact that the addresses are writting into the ESC registers) ?
- The PRU_ICSS firmware is provided as binary. Is the firmware dependent on the phy transceiver (though I think that there should be an abstraction layer in between) ?
- Any other ideas on where to dig?

Thank you so much in advance,

Liliane

Hi Liliane,

Did you update the pinmux file for your board and rebuild board library? You may run icss_emac driver loopback unit test to verify if the PHY and network set up properly. From your description, it doesn't seem to be a MDIO/PHY control issue, but have you tried to capture the network traffic using wireshark or any network analyzer?

There is no PHY dependence in PRU firmware.

REgards,
Garrett

Hi Garret,

Thank you for your reply.
Yes, I analyzed the network traffic on both the dev board and our custom board using Wireshark and I can't see any difference in the network traffic up until the point where a TwinCAT device scan is performed. In the case of the dev board, I can track some communication, but not on our custom board.
I would assume this means that no response is coming from the slave in the case of the custom board?

Regarding the ICSS Emac loopback, I ran the example and noticed that the interrupts are not always triggered (i.e. the code gets stuck at SemaphoreP_WAITFOREVER) and I could not find a deterministic trend about this behavior. At first, I assumed that the interrupts may be too close together, and tried to enable interrupt pacing. But actually when thinking twice, I guess that the code being stuck at a SemaphoreP_WAIT_FOREVER, this would mean that either
- the interrupt is not triggered
- the interrupt is not captured
Can you confirm this?
I checked the interrupt numbers in the TRM/ICSS EMAC guide and they seem ok. Also, if they were not configured accordingly, the interrupts could never get triggered. Actually, I had a similar issue with an interrupt on an old version of my custom board, and it seemed to be linked to a power supply problem. We are using the discrete power solution for AM437x. Do you have any other ideas or suggestions what could cause this?
What surprises me a bit is that the problem is really not repeatable (sometimes it doesn't get stuck, sometimes it gets stuck very fast).

Another strange observation: With the loopback test, both of my ports work equally good/bad. However, when I plug in the network cable from the second port to a PC, no link is detected. On the first port this seems to work. I also observed that on the dev board TX/RX from PHY transeiver to  RJ-45 connector are inverted on the second port. On our board, we did not do this inversion, but I guess this could be fixed anyways just by forcing the cable crossover in the PHY registers. Do you have any clue what could be causing this issue?

Best,

Liliane

Hi Garret,

The problem turned out the be a hardware problem, and is resolved.

Thank you for your help and regards,

Liliane