AM2432: No communication EtherCAT with AM2432 and custom PHY dp83822

Also share the PHY register dumps from (0 to 0x1F) for both ports.

HI, Aaron and Pratheesh,

Aaron Thomas said:

Have you enabled Enhanced Link in your application? If yes, can you try disabling it and try scanning.

I made the following changes, is this correct? The link is still not established.

#define ECAT_PHYPOLINVERT_IN                (false)
#define ECAT_PHYPOLINVERT_OUT               (false)
#define ECAT_PHYUSERXLINK_IN                (false)
#define ECAT_PHYUSERXLINK_OUT               (false)

PratheeshGangadhar said:

share the PHY register dumps from (0 to 0x1F) for both ports.

After above change I read bellow.

Best regard,

Oyama

From the PHY register values, looks like link is down and no signal detected. Additionally, from the MDIO_CONTROL_REG, it shows the MDIO state machine is in IDLE state and disabled.

To check on this further, can you provide the values in PRU_MDIO_MDIO Registers (0x300B2400 to 0x300B2484) ?

Also, have you connected the ports to an active network while capturing the above values, or are the ports disconnected ?

Regards,
Aaron

Hi Aarom,

The phy0 was connected to active master device while capturing.

The phy1 was disconnected.  

Upon further investigation, I found that phy0 was transitioning every few seconds between two states as shown in the table below.

However, the master device can't scan device, and CPU register value remains the same shown in below screen shot.

Best regard,

Oyama

Hi,

From the PHY registers you shared, I see that Auto-negotiation is enabled, Extended Full-Duplex is enabled, Odd Nibble Detection is enabled. This follows the EtherCAT requirements.

I'll review in detail the PHY and MDIO registers and see for any possible issues/misconfigurations.

Tomoya Oyama said:

Upon further investigation, I found that phy0 was transitioning every few seconds between two states as shown in the table below.

A couple of things to check on:

• Are you invoking PHY_softwareRestart API in your application? If yes, you can try bypassing the reset?

Hi Aarom,

Aaron Thomas said:

If yes, you can try bypassing the reset?

Sorry I don't really understand it, is this all I need to change like below? 

void CUST_PHY_DP83822_softwareRestart(void* pAppCtxt_p, void* pStackCtxt_p)
{
    OSALUNREF_PARM(pAppCtxt_p);
    OSALUNREF_PARM(pStackCtxt_p);
}

or disable this CB function? 

void EC_SLV_APP_SS_registerStacklessBoardFunctions(EC_SLV_APP_SS_Application_t *pAppInstance_p)
{
    if (!pAppInstance_p)
    {
        goto Exit;
    }

    ESL_BOARD_OS_registerPhys(pAppInstance_p->ptEcSlvApi, pAppInstance_p->selectedPruInstance);

    CUST_PHY_CBregisterLibDetect(CUST_PHY_detect, pAppInstance_p);
    //CUST_PHY_CBregisterReset(EC_SLV_APP_SS_boardPhyReset, pAppInstance_p);

Exit:
    return;
}

On my board, there is no software reset gpio pin, only hardware reset pin now.

It is need to software restart phy after Auto negotiation setting?

Best regard,

Oyama

Hi,

I'll discuss this with the expert internally and get back to you.

Regards,
Aaron

Hi Tomoya,

additionally to setting ECAT_PHYUSERXLINK_IN and ECAT_PHYUSERXLINK_OUT to false, please comment out the content of the function body of CUST_PHY_DP83822_enableFastLinkDownDet().

Best regards

Andreas

Hi Andreas,

Andreas Zirin said:

comment out the content of the function body of CUST_PHY_DP83822_enableFastLinkDownDet()

I tried it but it didn't work.

Best regard,

Oyama

Sorry, overlooked this yesterday. Please re-include the CUST_PHY_CBregisterReset() function and remove the softwareRestart function by setting pPhyLibDesc_p->softwareRestart = NULL (in CUST_PHY_dp83822.c) to bypass the reset.

Best regards

Andreas

Hi Andreas,

Thanks, I confirmed that the link is always up. (BMSR = 786d)

But, it is unable to scan this device from master device.

I checked register below, MII link is no established.

And I also checked waveforms MII0_RXD0, and MII0_TXD0, after scan from master.

I confirmed MII0_RXD0 waveform, but I didn't see MII0_TXD0 waveform.

Best regard,

Oyama

From the MDIO memory dump, looks like MDIO_ALIVE_REG is still not set which implies the PHY is not connected successfully (even though BMSR shows valid link established).

Make sure the following are handled:

• PHY is configured in MII mode for the AM243x. You should select the corresponding mode in SysConfig and make sure the proper pins are muxed for the PHY.
• In SysConfig, ensure the Ethernet interface pins are correctly configured for the DP83822 PHY. You must ensure that the TX/RX lines, MDC/MDIO lines, and CLK pins are correctly assigned.
• Enable Extended Full-Duplex, enable Odd Nibble Detection - (These looks to be taken care as bit2 and bit5 in CR2 is set)

Hi Andreas,

On my board, LED_0 pin of dp83822 is not connected to MII0_RXLINK pin of AM2432,

is it necessary to MII link and, is it related to MDIO_ALIVE_REG value?

Best regard,

Oyama

MII0_RXLINK is required for Cable Redundancy support. 

PHY link loss reaction time (link loss to link signal / LED output change) has to be faster than 15 us to Enable redundancy operation and Enhanced Link using RXLINK takes care of this timing constraint (Refer to Testing Cable Redundancy for the test scenario).

If Enhanced Link is disabled, the MDIO state machine-based detection is implemented, which is slow due to a serial link for messaging from the MDIO controller to the PHYs, which typically takes from 200 to 250 µs. MLINK/mii_rxlink detection occurs as fast as the PHY can toggle the link and typically within 10 µs.

Absence of this pin shouldn't be a blocker for EtherCAT functionality. Even without RXLINK, EtherCAT communication should work as expected.

Also regarding the MDIO configuration, are you enabling MDIO Manual Mode from the sysconfig? If yes, can you disable that and see if you see MDIO registers getting loaded ?

Also, are you using ICSSG0 or ICSSG1 instance ? 

 Regards,
Aaron

Hi Andreas,

I'm using ICSSG1.

I understand about  RXLINK. but after disable MDIO Manual Mode, EtherCAT application is stacked.

Is it need additional configuration?

Best regard,

Oyama

Hi,

Tomoya Oyama said:

I understand about  RXLINK. but after disable MDIO Manual Mode, EtherCAT application is stacked.

• When MDIO Manual Mode is disabled, make sure the alive register bits are set (0x300B2408). When MDIO Manual Mode is enabled, the alive register are emulated at offset 0x30080000 + 0x10E40 + 0x08 which is to be monitored for alive register and link register.
• Additionally, make sure bit6 is set and bit7 is cleared for 0x300B2484 and 0x300B248C Registers and bit0-4 has the correct PHY addresses.
  •   

Regards,
Aaron

Hi Aaron,

I modified ESL_BOARD_config.h, 

#define ECAT_PHYADDR_IN                     (0u)
#define ECAT_PHYADDR_OUT                    (1u)
#define ECAT_PHYPOLINVERT_IN                (true)
#define ECAT_PHYPOLINVERT_OUT               (true)
#define ECAT_PHYUSERXLINK_IN                (false)
#define ECAT_PHYUSERXLINK_OUT               (false)

This confirmed that BMSR = 786d, MDIO_REGS_ALIVE_REG = 3, 0x300B2484 = 0x40 and 0x300B248C=0x41.

But after scanning, no packets were sent from there.

In my opinion, PRU is not able to catch MII rx signal. (I confirmed MII rx waveform.)

Is there anything else I should check?

Best regard,

Oyama

Has there been any progress?

Hi Aaron,

I have one more question,.

The PHY reset pin is defined in the default SDK, but is there a need for a connection between the PHY reset pin and a GPIO?
Currently my board does not have these connections.

// PHY0 GPIO pins
#define APP_PHYIN_RESET_PIN                 ESL_GPIO_enPIN_28    
#define APP_PHYIN_RESET_MODULE              ESL_GPIO_enMODULE_0
#define APP_PHYOUT_RESET_PIN                ESL_GPIO_enPIN_20
#define APP_PHYOUT_RESET_MODULE             ESL_GPIO_enMODULE_0

Best regard,

Oyama

Hi Oyama,

In our example APP_PHYIN_RESET_PIN & APP_PHYOUT_RESET_PIN are being configured as output pins in ESL_BOARD_OS_configureResets() and then being used in ESL_BOARD_OS_phyReset() resp. EC_SLV_APP_SS_boardPhyReset() to reset the PHYs.

EC_SLV_APP_SS_boardPhyReset() is a.) registered as a callback using CUST_PHY_CBregisterReset() in EC_SLV_APP_SS_registerStacklessBoardFunctions() and b.) directly called (for both PHYs) in EC_SLV_APP_SS_initBoardFunctions().

Therefore, if there's no connection between these GPIOs and the PHYs, make sure to adapt EC_SLV_APP_SS_boardPhyReset() accordingly, so that there's no unwanted behaviour to whatever is connected to these GPIOs on your board.

Best regards

Andreas

Hi,

I modified this section to the correct pin.

But the situation did not change.

// PHY0 GPIO pins
#define APP_PHYIN_RESET_PIN                 ESL_GPIO_enPIN_84   
#define APP_PHYIN_RESET_MODULE              ESL_GPIO_enMODULE_0
#define APP_PHYOUT_RESET_PIN                ESL_GPIO_enPIN_84
#define APP_PHYOUT_RESET_MODULE             ESL_GPIO_enMODULE_0

Best regard,

Oyama

Hi Aaron,

I checked the waveforms on the MII RX lines.
After scanning from the master, PHY pins 1, 30, 31, 32 (see my schematic) are stuck high.
This seems like abnormal behavior. How should I handle it?

Best regard,

Oyama

Hi,

The link will be established, but communication has not yet been possible.

Is there anything else I need to check?

Best regard,

Oyama

Tomoya Oyama said:

After scanning from the master, PHY pins 1, 30, 31, 32 (see my schematic) are stuck high.

This appears to be a PHY related issue, will assign the thread to PHY expert. Could be due to incorrect power or reset sequence or termination

Hi Oyama,

Do you see other MAC lines are also driven high (RX_CLK, RX_CTRL, ...)?

As the MDI link is up and registers are accessible, I don't expect the PHY to be driving these lines high (unless data payload is all F's).

Are the lines held high regardless of link or data being actively sent on the MDI-side?

Thank you,
Evan

Hi,

Maybe it was interpreted differently. After the first RX, RX_D0~D3 remain high, except while RX_DV is high.

I confirmed that RX_CLK is working fine at 25MHz.

I confirmed ESC register using EC_API_SLV_readWordEscRegister().

RX Port0 frame counter 0x0E00 was increment after coming scan from master, and RX Error Counter 0x0300 remain 0.

So, I think that the EtherCAT data has reached the PRU.

Hi Oyama,

That's great to see. Please let me know if you face any functional issues, otherwise we can consider this issue closed.

Thank you,
Evan

Hi, Evan

However, the main problem is No TX data from AM2432 to master, in spite of RX coming. 

Hi Oyama,

Here looks like TX_CLK is not connected? What I understand is COL_1, CRS_1 and TX_CLK1 has a no-connect marker or test-point indication? Please correct me if I'm wrong.

Hi Aaron,

As you say, the meshed resistors are not connected.
Today, I connected TX_CLK with a 0 ohm resistor and confirmed that the scan was successful and EtherCAT communication was possible.
COL and CRS are still not connected.
These pins do not exist in the EtherCAT section of sysconf, but do they need to be connected?
Also, is TX_CLK absolutely necessary for MII with AM243?

Best regard,

Oyama

Hi team,

Thank you for patiently answering my repeated questions.