DP83826E: DP83826E EtherCAT does not work with F28P650DK9NMR

Hi,

Thank you for sharing the information

• May ask is the link partner also DP83822?
• May I ask are you able to see link?
• If possible, could you share the registers 0x0000 to 0x001F on DP83822?
• If possible, could you try to remove the ESD diode and see if that help with the issue?

--

Regards,

Hillman Lin

Hi Hilman, thank you for your support.

• May ask is the link partner also DP83822?
  We are using the DP83826E not DP83822, we plug the slave to a computer and use twincat
• May I ask are you able to see link?
  Not sure to follow, link between what?
• If possible, could you share the registers 0x0000 to 0x001F on DP83822?
  DP83826E not DP83822, here are the reg:
  
• If possible, could you try to remove the ESD diode and see if that help with the issue?
  I can yes, but how it could impact the phy?

I removed the ESD, did not changed anything

Hi,

Sorry for the confusion and thank you for pointing it out. I will debug this case based on DP83826.

May I ask is the register dump you provided are the condition where both of the DP83826 connected to each other?

ESD diode sometime will degraded the signal on MDI lines. Just want to confirm if there is any effect done by ESD diode.

--

Regards,

Hillman Lin

Conditions are: only PORT 0 is connected to a laptop using RJ45 cable, PORT 1 is not connected.

Hi,

The register you are reading is based on port 0 right?

--

Regards,

Hillman Lin

This is phy_regs_0 so I am pretty sure it is PORT 0?

Hi,

I will discuss with the team on the register dump and provide you an response later

--

Regards,

Hillman Lin

Hi,

We double check with the team. Here are some further test for debug:

• Try to perform a reset on the board after the PHY is power up. See if this resolve the issue.
• Remove the 2.2uF CEXT capacitor
• Read register 0x0467 and 0x0468 to see if the PHY is strap into the right configuration.
• If possible, could you connect both of the DP83826 together using RJ45 and see if you are able to see a link up?

--

Regards,

Hillman Lin

Hi Hilman.

• Try to perform a reset on the board after the PHY is power up. See if this resolve the issue.
  I push the reset push button on the board to reset the F28 after the PHY are powered up, nothing change
• Remove the 2.2uF CEXT capacitor
  Removed the cap, still the same
• If possible, could you connect both of the DP83826 together using RJ45 and see if you are able to see a link up?
  I did plug them together, if I flash it the two LED turn off on the two ports.
  If I try in debug, it get stuck in and return ESC_HW_INIT_FAIL
  

      //
      // Wait for ESCSS memory initialization to complete
      //
  
  
      if(ESCSS_getMemoryInitDoneStatusBlocking(ESC_SS_BASE, memoryTimeOut) !=
         ESCSS_API_SUCCESS)
      {
          return(ESC_HW_INIT_FAIL);
      }
  

  
  Then we have the RED led turn on.
  Here are the two registers for PHY0 and PHY 1
  
  Not sure why when we are not in debug, the RED led is off, meaning ESC_HW_INIT is ok
• Read register 0x0467 and 0x0468 to see if the PHY is strap into the right configuration.
  I tried to add a global variable  uint16_t readWordDebug =0; then use ESC_readWord with the address, but the value is always 0:
   

      while(1)
      {
          ESC_debugUpdateESCRegLogs();
          DEVICE_DELAY_US((uint32_t)(50000));
          readWordDebug = ESC_readWord(0x0467);
          DEVICE_DELAY_US((uint32_t)(50000));
          readWordDebug = ESC_readWord(0x0468);
          DEVICE_DELAY_US((uint32_t)(50000));
      }

Hi,

Unfortunately, I am not a software expert. I am not sure what is the functionality of ESC_HW_INIT. I will focus on the hardware standpoint or the PHY only

• In order to prevent any register write during the boot up process. Are you able to remove the connection between MDIO and MDC and see if the PHY is able to link up?
• Could you only power up the PHY but not the SoC and see if you are able to see a link up

This could give us an indication is the issue between PHY to PHY or MAC to PHY.

• If you can see a link up after the above two test, I would try the loopback mode later.

--

Thank you,

Hillman Lin

Hi Hilman, sorry for the delay.

• In order to prevent any register write during the boot up process. Are you able to remove the connection between MDIO and MDC and see if the PHY is able to link up?
  
  Unfortunately our design is super dense, we cannot really remove the connections between the MCU and MDC or MDIO:
  

  

• Could you only power up the PHY but not the SoC and see if you are able to see a link up
  Could you please define what link up means? Are we just talking about the yellow led that indicates the link status?
  

In an act of despair we've changed the PHY for new one from Digikey.
The new part number is 826E TI 298 AS8K G4.

The behaviour of the PHY are different now:

The pin RBIAS is at 1V now, before it used to be 0V.

I tried the original f28p65x_cpu1_pdi_hal_test_app

Nothing connected, leds are OFF (LINK status and LINK ACTIVE)
If I connect a RJ45 the two leds a blinking, but I cannot see any slave on twincat

Same if I try the modify firmware (write in EEPROM first, then f28p65x_cpu1_pdi_hal_test_app with ethercat_slave_cpu1_hal_PHY_check file added)

---------------------------------------------------------------------------------------------------------------------

Let say we are in an ideal world, we use the latest PHY revisions available, MCU uses same pinout as the launchpad F28P65, we should be able to run the f28p65x_cpu1_pdi_hal_test_app from C2000Ware.

But the C2000 example does not even compile in LAUNCHXL_FLASH:

If we build in FLASH, we get the error: Description    Resource    Path    Location    Type
Cannot find a driver for Cpu CPU1_CLA1    TMS320F28P650DK9.ccxml    /f28p65x_cpu1_pdi_hal_test_app    Texas Instruments XDS110 USB Debug Probe_0\CPU1_CLA1    Problem

So then we need to get the file from:
https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1325578/launchxl-f28p65x-cannot-find-a-driver-for-cpu-cpu1_cla1

Then we need to Define _LAUNCHXL_F28P65X in order to set the pin configuration correctly...

This whole process is really frustrating right now, we cannot tell if:

• we are doing something wrong
• if the example project f28p65x_cpu1_pdi_hal_test_app is actually working?

This issue has been significantly delaying our product development. The fact that changing the PHYs on the same board results in different behavior makes us think that it is difficult to determine whether the problem is hardware or software. Would you be able to bring someone from the software side into the loop to tell us exactly which register to look at to first determine the revision of the PHY, and then to confirm if we need the workaround firmware in order to detect the slave, etc.?

HI AI,

Did you have the register dump for the new setup that you currently have? If possible, could you constantly pulling the register 0x0001 to see if the PHY have the stable link up? 

• I would like to confirm in your new setup, is the PHY able to link up properly.
• Could you also provide the register log from 0x0000 to 0x001F
• Again, in your current setup, could you power up only the PHY but not the SoC and see the status of LED?

Unfortunately, I am not too familiar with the CPU flashing software that you are currently using. Not too sure what CPU example project that you are current using. If possible, could you reach out to C2000 product line for further detail on the software

--
Regards,

Hillman Lin

Hi Hillman.

With the new PHYs:

With PORT 0 connected to a laptop using RJ45and PORT 1 is left open:

With PORT 0 connected to PORT 1:

When the MCU is held in reset, no LEDs light up even when connected to a laptop or when port 0 and port 1 are connected together.

Hi,

Thank you for sharing the information. Through the register write, it seems like both port 1 and port 2 is not able to link up properly.

It seems like the PHY is not able to link up that is why you are not able to communicate. Here is the following steps I would like to try:

• Remove the pull down resistor on reset pin
• May I also see a picture on the RJ45 connector?

MDI lengths may also have an effect on the signal quality and result on not linking up.

--

Regards,

Hillman Lin

Hi Hillman
I cannot test without the PD resistors on reset yet, I will give it a try.

Here is the DUT:
RJ45 is deported using twisted cable. This is used on other design with no issues.

Great attention has been paid to the layout, with the lengths of MDIO and MDC being 47 mm and 45 mm, respectively.

Same from the PHY to transformer then connector:

All the signals are adjacent to a ground plane:

1. Could you tell me what would make the LINK STATUS and ACTIVE LEDs blinking when we connect the RJ45?
2. If we refer to this post, it says the first EEPROM program will load only the minimum needed bytes into the EEPROM so that debug access can then be enabled to the F28P65x ESC registers. This is needed so that the device can read and write to the PHY.
   My question: to get the link properly setup for the PHY we need the correct firmware right? How can we be sure what version of the PHY we currently have installed? Is that possible we are looking on the hardware but it is just the firmware that does not correctly setup the PHY registers?
   e2e.ti.com/.../faq-launchxl-f28p65x-how-do-i-fix-the-ethercat-issue-where-the-launchpad-cannot-be-scanned-in-twincat

Hi,

Unstable link will result in linking in RJ45. Poor layout or week signal quality would also result in unstable link.

I see that you have separate board between the transformer and connector. We normally don't recommend customer to use this topology because the twisted pair does not have continuous ground below which result in not stable cable termination. May I ask is the cable termination between the connector and transformer? Is it 100 ohms termination?

If possible, could you try to run the compliance test with the current setup you have and see if you are able to pass? 

You could also try a shorter cable and see if that help with your signal quality.

--
Regards,

Hillman Lin

Hello Hillman,

I’m back with some interesting news.

We started with a brand new board, flashed the demo example firmware, but there was no LINK. Then we removed the original PHYs 826E TI 198 ALSF G4 and replaced them with new ones from Digi-Key  826E TI 348 AHLD G4.

Now, when we plug in our RJ45, PORT 1 is working (LINK LED solid and I see a slave on EtherCAT), but PORT 0 isn’t and LED is blinking

I repeated the exact same process on another board with the new PHYs from TI samples 826E TI 2A8 AH8X G4, and got the same result: PORT 1 works, but PORT 0 can’t establish a link.

So my first conclusion is, there is definitly something wrong or different with the batch 826E TI 198 ALSF G4.

Now I try to understand why PORT 0is still not working.

Could you please double-check the EtherCAT schematic again?

QUESTION: I’m trying to narrow down the issue. When the PHY isn’t able to link, could it be on the RMII side, the magnetic/RJ45 side, or both?

QUESTION:If I swap the two PHY addresses using P-U/P-D resistors, I should be able to talk to both PHY or I need additional changes?

Another test I would like to do is to connect the PHY 1 that works to the magnetics of PORT 0, but this involve cutting traces so I wanted to have your input first.


Thank you

Not sure if its relevant but when PORT 1 is connected to TWinCAT (RJ45 plugged) I get the state OP LNK_MIS_LNK_ADD A B
So I guess PORT 0 is setup correctly?!?

HI AI,

I double check on the schematic again. It seems like bottom PHY and top PHY do have the same schematic other than the strapping on PHY ID or LED_0 pins. The main thing I would focus on is the layout (both on RJ45 connector board and the main board). Here are three further we could perform:

• Change cable between first PHY and second PHY (the orientation between two pair of cable):
  • 
• Change magnetic between the two PHYs and see if any results changes
• Change PHY ID between two PHYs and observed the behavior of two PHYs.

--

Regards,

Hillman Lin

Hi Hillman,

When you say "Change cable between first PHY and second PHY (the orientation between two pair of cable): "
You want me to connect
RX_P PHY to RX_P RJ45 cable
RX_N PHY to RX_N RJ45 cable
TX_P PHY to TX_P RJ45 cable
TX_N PHY to TX_N RJ45 cable

then try to flip:
TX_P PHY to RX_P RJ45 cable
TX_N PHY to RX_N RJ45 cable
RX_P PHY to TX_P RJ45 cable
RX_N PHY to TX_N RJ45 cable

I already tried that did not do thing.

I also interchanged the PHY adresses using PU and PD resistors on pin 30, result was the same, the same PHY was able to link not the other one.
What I don't understand is that when PORT 1 is connected the slave is in OP mode it can detect that the other PHY cannot link. This would means the MII connection is wrong between MCU and PHY 0 right?

HI AI,

TwinCAT directly connected to port 0 able to recognize the PHY but TwinCAT directly connected to port 1 cannot recognize the PHY?

Have you try changing transformer and CMC between the two PHY? If possible, also test on the Rbias and CLK_OUT signal for PHY 0 and PHY 1.

--

Regards,

Hillman Lin

No, TwinCAT directly connected port 1, it recognizes that PHY 1 is LINK and PHY0 is "missing", I don't know how that works.
We try everything, changing the CMC, transformers, Rbias is 0.9V, clkout...
I also drived the GPIO manually Low-high and probe on the PHY side with an oscillo to make sur the MCU is correctly wired and tracks are connected where it is supposed.

I am close to give up

Hi AI,

let us take one more step back. Please read the register status between port 1 connected to PC and port 0 connected to PC.

• 0x0000 to 0x001F

From the register you send above the E2E, both port 0 and port 1 is always not seeing link up. We need to see the different register status between working ports and non working ports

Here is the indication where one of the PHY is link up:

• register 1 = 30829

If you are not able to see this register value, this indicate both of the PHY or ports is not seeing link up.

--

Regards,

Hillman Lin