AM2432: EIP Connection failure occurs with using DP83822

By the way,I thought it possible before driving the DP83822 PHYs with the ind_comms_sdk_am243x_09_00_00_03 stack which can drive the DP83869 at AM243x_LP.

However,I find the function in stack needs some unseeable inputs,like EI_API_ADP_pruicssInit,CUST_PHY_DP83869_setMIIMode.

So,does it mean I have to construct drivers for DP83822 PHYs? Or where I can find the reference used in the current stack?

Hi Sigong,

sigong said:

So,does it mean I have to construct drivers for DP83822 PHYs? Or where I can find the reference used in the current stack

Dp83822 PHY is very similar to DP83826E so with some modifcations you should be able to get it working. I am sharing the phy driver for dp83826E.

/cfs-file/__key/communityserver-discussions-components-files/908/CUST_5F00_PHY_5F00_dp83826e.h

/cfs-file/__key/communityserver-discussions-components-files/908/CUST_5F00_PHY_5F00_dp83826e.c

Hi Nilabh,

Thanks for your response.

I have replaced the former driver with dp83826e.h and .c. 

Here is the lastest logs:

[MCSPI] Loopback example started 3
Pruicss max =3 selected PRU:3
The data is corrupted, write default values.
Did Map 0x30080000 len 0x2000 to 0x30080000 (dram0)
Did Map 0x30082000 len 0x2000 to 0x30082000 (dram1)
Did Map 0x300b4000 len 0x4000 to 0x300b4000 (iram0)
Did Map 0x300b8000 len 0x4000 to 0x300b8000 (iram1)
Did Map 0x30090000 len 0x10000 to 0x30090000 (shdram)
Did Map 0x300a2000 len 0x400 to 0x300a2000 (control0)
Did Map 0x300a4000 len 0x400 to 0x300a4000 (control1)
Did Map 0x300a0000 len 0x2000 to 0x300a0000 (intc)
Did Map 0x300a6000 len 0x2000 to 0x300a6000 (cfg)
Did Map 0x300a8000 len 0x2000 to 0x300a8000 (uart0)
Did Map 0x300ae000 len 0x2000 to 0x300ae000 (iep)
Did Map 0x300b0000 len 0x2000 to 0x300b0000 (ecap0)
Did Map 0x300b2000 len 0x400 to 0x300b2000 (mii_rt)
Did Map 0x3009f000 len 0x1c00 to 0x3009f000 (mdio)
Did Map 0x3008a000 len 0x2000 to 0x3008a000 (txPru0Iram)
Did Map 0x3008c000 len 0x2000 to 0x3008c000 (txPru1Iram)
Did Map 0x300a5000 len 0x100 to 0x300a5000 (txPru0CtlReg)
Did Map 0x300a5000 len 0x100 to 0x300a5000 (txPru1CtlReg)
DP83826E detected
DP83826E detected
PRU_PHY_detect:185 Phy 1 alive
PRU_PHY_detect:185 Phy 4 alive
Phy 1 : REG[0x0000] = 0x3100
Phy 1 : REG[0x0001] = 0x7849
Phy 1 : REG[0x0002] = 0x2000
Phy 1 : REG[0x0003] = 0xA240
Phy 1 : REG[0x0004] = 0x01E1
Phy 1 : REG[0x0005] = 0x0000
Phy 1 : REG[0x0006] = 0x0004
Phy 1 : REG[0x0007] = 0x2001
Phy 1 : REG[0x0008] = 0x0000
Phy 1 : REG[0x0009] = 0x0000
Phy 1 : REG[0x000A] = 0x0100
Phy 1 : REG[0x000B] = 0x1000
Phy 1 : REG[0x000C] = 0x0000
Phy 1 : REG[0x000D] = 0x0000
Phy 1 : REG[0x000E] = 0x0000
Phy 1 : REG[0x000F] = 0x0000
Phy 1 : REG[0x0010] = 0x1002
Phy 1 : REG[0x0011] = 0x0108
Phy 1 : REG[0x0012] = 0x0000
Phy 1 : REG[0x0013] = 0x0200
Phy 1 : REG[0x0014] = 0x0000
Phy 1 : REG[0x0015] = 0x0000
Phy 1 : REG[0x0016] = 0x0100
Phy 1 : REG[0x0017] = 0x0041
Phy 1 : REG[0x0018] = 0x0400
Phy 1 : REG[0x0019] = 0x8021
Phy 1 : REG[0x001A] = 0x0010
Phy 1 : REG[0x001B] = 0x007D
Phy 1 : REG[0x001C] = 0x05EE
Phy 1 : REG[0x001D] = 0x0000
Phy 1 : REG[0x001E] = 0x0102

Phy 4 : REG[0x0000] = 0x3100
Phy 4 : REG[0x0001] = 0x7849
Phy 4 : REG[0x0002] = 0x2000
Phy 4 : REG[0x0003] = 0xA240
Phy 4 : REG[0x0004] = 0x01E1
Phy 4 : REG[0x0005] = 0x0000
Phy 4 : REG[0x0006] = 0x0004
Phy 4 : REG[0x0007] = 0x2001
Phy 4 : REG[0x0008] = 0x0000
Phy 4 : REG[0x0009] = 0x0000
Phy 4 : REG[0x000A] = 0x0100
Phy 4 : REG[0x000B] = 0x1000
Phy 4 : REG[0x000C] = 0x0000
Phy 4 : REG[0x000D] = 0x0000
Phy 4 : REG[0x000E] = 0x0000
Phy 4 : REG[0x000F] = 0x0000
Phy 4 : REG[0x0010] = 0x0002
Phy 4 : REG[0x0011] = 0x0108
Phy 4 : REG[0x0012] = 0x0000
Phy 4 : REG[0x0013] = 0x0000
Phy 4 : REG[0x0014] = 0x0000
Phy 4 : REG[0x0015] = 0x0000
Phy 4 : REG[0x0016] = 0x0100
Phy 4 : REG[0x0017] = 0x0041
Phy 4 : REG[0x0018] = 0x0400
Phy 4 : REG[0x0019] = 0x8024
Phy 4 : REG[0x001A] = 0x0000
Phy 4 : REG[0x001B] = 0x007D
Phy 4 : REG[0x001C] = 0x05EE
Phy 4 : REG[0x001D] = 0x0000
Phy 4 : REG[0x001E] = 0x0102

+EI_API_ADP_pruicssStart
-EI_API_ADP_pruicssStart
Assembly 0x64 size: 0
Assembly 0x64 size: 2 (attrId 0x340)
Assembly 0x64 size: 4 (attrId 0x341)
Assembly 0x64 size: 6 (attrId 0x342)
Assembly 0x64 size: 8 (attrId 0x343)
Assembly 0x64 size: 10 (attrId 0x344)
Assembly 0x64 size: 12 (attrId 0x345)
Assembly 0x64 size: 14 (attrId 0x346)
Assembly 0x64 size: 16 (attrId 0x347)
Assembly 0x64 size: 18 (attrId 0x348)
Assembly 0x64 size: 20 (attrId 0x349)
Assembly 0x64 size: 22 (attrId 0x34a)
Assembly 0x64 size: 24 (attrId 0x34b)
Assembly 0x64 size: 26 (attrId 0x34c)
Assembly 0x64 size: 28 (attrId 0x34d)
Assembly 0x64 size: 30 (attrId 0x34e)
Assembly 0x64 size: 32 (attrId 0x34f)
Local interface IP is 192.168.1.19
EI_API_ADP_getMacAddr: 1c:63:49:20:7c:bc

We can find the phy reg BMSR 's value is not equal to 0x786d.Meanwhile,neither of RJ45's link and ack LED is on.

So,what step I can take next  to find the problem?Thank you.

regards,

sigong

Hi Nilabh,

I found the EIP stack's syscfg not including pins like RX_ER,RX_LINK.Does it mean that RX_ER,RX_LINK can be not used in MII?

If not,why it shows like that?

Besides,when the initial code has been excuted completedly,AM2432 could not output 25MHz frequency which should be used by PHYs.I tested the pin A18(EXT_REFCLK1) and did not find the 25MHz.

The PHYs cannot work normally still.

Could tell me the reason for it?Thanks.

Hi Nilabh,

Could you help on this one?

Thanks,

Hang.

sigong said:

I found the EIP stack's syscfg not including pins like RX_ER,RX_LINK.Does it mean that RX_ER,RX_LINK can be not used in MII?

If not,why it shows like that?

RX_ERR_lINK pin is required only for EtherCAT in my opinion, I can check it and get back to you.

sigong said:

Besides,when the initial code has been excuted completedly,AM2432 could not output 25MHz frequency which should be used by PHYs.I tested the pin A18(EXT_REFCLK1) and did not find the 25MHz.

The PHYs cannot work normally still.

Could tell me the reason for it?Thanks.

Hi Hang, Please create a separate thread for this, this needs to be handled by clock peripheral expert.

sigong said:

We can find the phy reg BMSR 's value is not equal to 0x786d.Meanwhile,neither of RJ45's link and ack LED is on.

So,what step I can take next  to find the problem?Thank you.

Hi Hang,

Is the schematic of the custom board by the customer already reviewed by the HW apps team? If not could you please raise the request.

Hi Nilabh,

Their schematic has been reviewed the HW team. Meanwhile, they have fixed the PHY link by add the 25Mhz clk input to PHY and are now able to see 0x786D in one of the PHY.

Below is terminal output, register dump is included.

You 4/1/2024 11:16 AM • [MCSPI] Loopback example started 3
Pruicss max =3 selected PRU:3
The data is corrupted, write default values.
Did Map 0x30080000 len 0x2000 to 0x30080000 (dram0)
Did Map 0x30082000 len 0x2000 to 0x30082000 (dram1)
Did Map 0x300b4000 len 0x4000 to 0x300b4000 (iram0)
Did Map 0x300b8000 len 0x4000 to 0x300b8000 (iram1)
Did Map 0x30090000 len 0x10000 to 0x30090000 (shdram)
Did Map 0x300a2000 len 0x400 to 0x300a2000 (control0)
Did Map 0x300a4000 len 0x400 to 0x300a4000 (control1)
Did Map 0x300a0000 len 0x2000 to 0x300a0000 (intc)
Did Map 0x300a6000 len 0x2000 to 0x300a6000 (cfg)
Did Map 0x300a8000 len 0x2000 to 0x300a8000 (uart0)
Did Map 0x300ae000 len 0x2000 to 0x300ae000 (iep)
Did Map 0x300b0000 len 0x2000 to 0x300b0000 (ecap0)
Did Map 0x300b2000 len 0x400 to 0x300b2000 (mii_rt)
Did Map 0x3009f000 len 0x1c00 to 0x3009f000 (mdio)
Did Map 0x3008a000 len 0x2000 to 0x3008a000 (txPru0Iram)
Did Map 0x3008c000 len 0x2000 to 0x3008c000 (txPru1Iram)
Did Map 0x300a5000 len 0x100 to 0x300a5000 (txPru0CtlReg)
Did Map 0x300a5000 len 0x100 to 0x300a5000 (txPru1CtlReg)
DP83826E detected
DP83826E detected
PRU_PHY_detect:185 Phy 3 alive
PRU_PHY_detect:185 Phy 15 alive
Phy 3 : REG[0x0000] = 0x3100
Phy 3 : REG[0x0001] = 0x7849
Phy 3 : REG[0x0002] = 0x2000
Phy 3 : REG[0x0003] = 0xA240
Phy 3 : REG[0x0004] = 0x01E1
Phy 3 : REG[0x0005] = 0x0000
Phy 3 : REG[0x0006] = 0x0004
Phy 3 : REG[0x0007] = 0x2001
Phy 3 : REG[0x0008] = 0x0000
Phy 3 : REG[0x0009] = 0x0000
Phy 3 : REG[0x000A] = 0x0100
Phy 3 : REG[0x000B] = 0x1020
Phy 3 : REG[0x000C] = 0x0000
Phy 3 : REG[0x000D] = 0x401F
Phy 3 : REG[0x000E] = 0x0000
Phy 3 : REG[0x000F] = 0x0000
Phy 3 : REG[0x0010] = 0x4002
Phy 3 : REG[0x0011] = 0x0108
Phy 3 : REG[0x0012] = 0x0000
Phy 3 : REG[0x0013] = 0x0800
Phy 3 : REG[0x0014] = 0x0000
Phy 3 : REG[0x0015] = 0x0000
Phy 3 : REG[0x0016] = 0x0100
Phy 3 : REG[0x0017] = 0x0041
Phy 3 : REG[0x0018] = 0x0400
Phy 3 : REG[0x0019] = 0x8023
Phy 3 : REG[0x001A] = 0x0000
Phy 3 : REG[0x001B] = 0x007D
Phy 3 : REG[0x001C] = 0x05EE
Phy 3 : REG[0x001D] = 0x0000
Phy 3 : REG[0x001E] = 0x0102
Phy 3 : REG[0x001F] = 0x0000
Phy 3 : REG[0x0025] = 0x0000
Phy 3 : REG[0x0027] = 0x0000
Phy 3 : REG[0x003E] = 0x0000
Phy 3 : REG[0x003F] = 0xB4FF
Phy 3 : REG[0x0040] = 0xC11D
Phy 3 : REG[0x0042] = 0x0000
Phy 3 : REG[0x0218] = 0x00A4
Phy 3 : REG[0x0467] = 0x3FC3
Phy 3 : REG[0x0468] = 0x0000

Phy 15 : REG[0x0000] = 0x3100
Phy 15 : REG[0x0001] = 0x786D
Phy 15 : REG[0x0002] = 0x2000
Phy 15 : REG[0x0003] = 0xA240
Phy 15 : REG[0x0004] = 0x01E1
Phy 15 : REG[0x0005] = 0xCDE1
Phy 15 : REG[0x0006] = 0x000F
Phy 15 : REG[0x0007] = 0x2001
Phy 15 : REG[0x0008] = 0x4006
Phy 15 : REG[0x0009] = 0x0000
Phy 15 : REG[0x000A] = 0x0100
Phy 15 : REG[0x000B] = 0x1020
Phy 15 : REG[0x000C] = 0x0000
Phy 15 : REG[0x000D] = 0x401F
Phy 15 : REG[0x000E] = 0x0003
Phy 15 : REG[0x000F] = 0x0000
Phy 15 : REG[0x0010] = 0x5615
Phy 15 : REG[0x0011] = 0x0108
Phy 15 : REG[0x0012] = 0x6400
Phy 15 : REG[0x0013] = 0x2A00
Phy 15 : REG[0x0014] = 0x0000
Phy 15 : REG[0x0015] = 0x0000
Phy 15 : REG[0x0016] = 0x0100
Phy 15 : REG[0x0017] = 0x0049
Phy 15 : REG[0x0018] = 0x0400
Phy 15 : REG[0x0019] = 0x8C2F
Phy 15 : REG[0x001A] = 0x0010
Phy 15 : REG[0x001B] = 0x007D
Phy 15 : REG[0x001C] = 0x05EE
Phy 15 : REG[0x001D] = 0x0000
Phy 15 : REG[0x001E] = 0x0102
Phy 15 : REG[0x001F] = 0x0000
Phy 15 : REG[0x0025] = 0x0000
Phy 15 : REG[0x0027] = 0x0000
Phy 15 : REG[0x003E] = 0x0000
Phy 15 : REG[0x003F] = 0xB4FF
Phy 15 : REG[0x0040] = 0xC11D
Phy 15 : REG[0x0042] = 0x0000
Phy 15 : REG[0x0218] = 0x005E
Phy 15 : REG[0x0467] = 0xFFC3
Phy 15 : REG[0x0468] = 0x0003

+EI_API_ADP_pruicssStart
-EI_API_ADP_pruicssStart
Assembly 0x64 size: 0
Assembly 0x64 size: 2 (attrId 0x340)
Assembly 0x64 size: 4 (attrId 0x341)
Assembly 0x64 size: 6 (attrId 0x342)
Assembly 0x64 size: 8 (attrId 0x343)
Assembly 0x64 size: 10 (attrId 0x344)
Assembly 0x64 size: 12 (attrId 0x345)
Assembly 0x64 size: 14 (attrId 0x346)
Assembly 0x64 size: 16 (attrId 0x347)
Assembly 0x64 size: 18 (attrId 0x348)
Assembly 0x64 size: 20 (attrId 0x349)
Assembly 0x64 size: 22 (attrId 0x34a)
Assembly 0x64 size: 24 (attrId 0x34b)
Assembly 0x64 size: 26 (attrId 0x34c)
Assembly 0x64 size: 28 (attrId 0x34d)
Assembly 0x64 size: 30 (attrId 0x34e)
Assembly 0x64 size: 32 (attrId 0x34f)
Local interface IP is 192.168.1.20
EI_API_ADP_getMacAddr: 1c:63:49:20:7c:d3

As the PHY is link-up, the issue might be in the stack or driver.

Is it possible to help look into the issue through on-line debug session?

Thanks,

Hang.

As update, the ICSS MDIO register is read to confirm PHY address and link-up, below are screenshot of the registers, the bit 3 (0x00000008)and bit15 (0x00008000)is toggling with cable connection/disconnections.

The PHY address (3 and 15) is aligned with ones in syscfg

Hi Hang,

I have a few steps that I would like to check on the customer end:

1. We need to check the MDIO register for LINK Status? 
   1. If using MDIO manual mode base address is as follows: ICSSG0: 30010e40
      ICSSG1: 30090e40
   2. If using MDIO state machine mode:ICSSG0: 30032400
      ICSSG1: 300B2400  
2. Is the phy address properly populated in syscfg(as this is a custom board?)-- Please check this?
3. Next we can have a debug call if things are working properly.

Can you disable the mdio manual mode and try.

Hi,

I have followed you advice and disabled the manual  mode.

And some changes happened in the addr 0x300B2408.

as is shown below:

However,there is no changes about EIP in the logs.

[MCSPI] Loopback example started 3
Pruicss  max =3 selected PRU:3
The data is corrupted, write default values.
Did Map 0x30080000 len 0x2000 to 0x30080000 (dram0)
Did Map 0x30082000 len 0x2000 to 0x30082000 (dram1)
Did Map 0x300b4000 len 0x4000 to 0x300b4000 (iram0)
Did Map 0x300b8000 len 0x4000 to 0x300b8000 (iram1)
Did Map 0x30090000 len 0x10000 to 0x30090000 (shdram)
Did Map 0x300a2000 len 0x400 to 0x300a2000 (control0)
Did Map 0x300a4000 len 0x400 to 0x300a4000 (control1)
Did Map 0x300a0000 len 0x2000 to 0x300a0000 (intc)
Did Map 0x300a6000 len 0x2000 to 0x300a6000 (cfg)
Did Map 0x300a8000 len 0x2000 to 0x300a8000 (uart0)
Did Map 0x300ae000 len 0x2000 to 0x300ae000 (iep)
Did Map 0x300b0000 len 0x2000 to 0x300b0000 (ecap0)
Did Map 0x300b2000 len 0x400 to 0x300b2000 (mii_rt)
Did Map 0x300b2000 len 0x1c00 to 0x300b2000 (mdio)
Did Map 0x3008a000 len 0x2000 to 0x3008a000 (txPru0Iram)
Did Map 0x3008c000 len 0x2000 to 0x3008c000 (txPru1Iram)
Did Map 0x300a5000 len 0x100 to 0x300a5000 (txPru0CtlReg)
Did Map 0x300a5000 len 0x100 to 0x300a5000 (txPru1CtlReg)
DP83826E detected
DP83826E detected
PRU_PHY_detect:185 Phy 3 alive
PRU_PHY_detect:185 Phy 15 alive
Phy 3 : REG[0x0000] = 0x3100
Phy 3 : REG[0x0001] = 0x786D
Phy 3 : REG[0x0002] = 0x2000
Phy 3 : REG[0x0003] = 0xA240
Phy 3 : REG[0x0004] = 0x01E1
Phy 3 : REG[0x0005] = 0xCDE1
Phy 3 : REG[0x0006] = 0x000F
Phy 3 : REG[0x0007] = 0x2001
Phy 3 : REG[0x0008] = 0x4006
Phy 3 : REG[0x0009] = 0x0000
Phy 3 : REG[0x000A] = 0x0100
Phy 3 : REG[0x000B] = 0x1000
Phy 3 : REG[0x000C] = 0x0000
Phy 3 : REG[0x000D] = 0x0000
Phy 3 : REG[0x000E] = 0x0000
Phy 3 : REG[0x000F] = 0x0000
Phy 3 : REG[0x0010] = 0x0615
Phy 3 : REG[0x0011] = 0x0108
Phy 3 : REG[0x0012] = 0x6400
Phy 3 : REG[0x0013] = 0x2800
Phy 3 : REG[0x0014] = 0x0000
Phy 3 : REG[0x0015] = 0x0000
Phy 3 : REG[0x0016] = 0x0100
Phy 3 : REG[0x0017] = 0x0049
Phy 3 : REG[0x0018] = 0x0400
Phy 3 : REG[0x0019] = 0x8C23
Phy 3 : REG[0x001A] = 0x0000
Phy 3 : REG[0x001B] = 0x007D
Phy 3 : REG[0x001C] = 0x05EE
Phy 3 : REG[0x001D] = 0x0000
Phy 3 : REG[0x001E] = 0x0102
Phy 3 : REG[0x001F] = 0x0000
Phy 3 : REG[0x0025] = 0x0000
Phy 3 : REG[0x0027] = 0x0000
Phy 3 : REG[0x003E] = 0x0000
Phy 3 : REG[0x003F] = 0xB4FF
Phy 3 : REG[0x0040] = 0xC11D
Phy 3 : REG[0x0042] = 0x0000
Phy 3 : REG[0x0218] = 0x004B
Phy 3 : REG[0x0467] = 0x3FC3
Phy 3 : REG[0x0468] = 0x0000

Phy 15 : REG[0x0000] = 0x3100
Phy 15 : REG[0x0001] = 0x7849
Phy 15 : REG[0x0002] = 0x2000
Phy 15 : REG[0x0003] = 0xA240
Phy 15 : REG[0x0004] = 0x01E1
Phy 15 : REG[0x0005] = 0x0000
Phy 15 : REG[0x0006] = 0x0004
Phy 15 : REG[0x0007] = 0x2001
Phy 15 : REG[0x0008] = 0x0000
Phy 15 : REG[0x0009] = 0x0000
Phy 15 : REG[0x000A] = 0x0100
Phy 15 : REG[0x000B] = 0x1000
Phy 15 : REG[0x000C] = 0x0000
Phy 15 : REG[0x000D] = 0x0000
Phy 15 : REG[0x000E] = 0x0000
Phy 15 : REG[0x000F] = 0x0000
Phy 15 : REG[0x0010] = 0x0002
Phy 15 : REG[0x0011] = 0x0108
Phy 15 : REG[0x0012] = 0x0000
Phy 15 : REG[0x0013] = 0x0000
Phy 15 : REG[0x0014] = 0x0000
Phy 15 : REG[0x0015] = 0x0000
Phy 15 : REG[0x0016] = 0x0100
Phy 15 : REG[0x0017] = 0x0041
Phy 15 : REG[0x0018] = 0x0400
Phy 15 : REG[0x0019] = 0x802F
Phy 15 : REG[0x001A] = 0x0000
Phy 15 : REG[0x001B] = 0x007D
Phy 15 : REG[0x001C] = 0x05EE
Phy 15 : REG[0x001D] = 0x0000
Phy 15 : REG[0x001E] = 0x0102
Phy 15 : REG[0x001F] = 0x0000
Phy 15 : REG[0x0025] = 0x0000
Phy 15 : REG[0x0027] = 0x0000
Phy 15 : REG[0x003E] = 0x0000
Phy 15 : REG[0x003F] = 0xB4FF
Phy 15 : REG[0x0040] = 0xC11D
Phy 15 : REG[0x0042] = 0x0000
Phy 15 : REG[0x0218] = 0x001F
Phy 15 : REG[0x0467] = 0xFFC3
Phy 15 : REG[0x0468] = 0x0003

+EI_API_ADP_pruicssStart
-EI_API_ADP_pruicssStart
Assembly 0x64 size: 0
Assembly 0x64 size: 2 (attrId 0x340) 
Assembly 0x64 size: 4 (attrId 0x341) 
Assembly 0x64 size: 6 (attrId 0x342) 
Assembly 0x64 size: 8 (attrId 0x343) 
Assembly 0x64 size: 10 (attrId 0x344) 
Assembly 0x64 size: 12 (attrId 0x345) 
Assembly 0x64 size: 14 (attrId 0x346) 
Assembly 0x64 size: 16 (attrId 0x347) 
Assembly 0x64 size: 18 (attrId 0x348) 
Assembly 0x64 size: 20 (attrId 0x349) 
Assembly 0x64 size: 22 (attrId 0x34a) 
Assembly 0x64 size: 24 (attrId 0x34b) 
Assembly 0x64 size: 26 (attrId 0x34c) 
Assembly 0x64 size: 28 (attrId 0x34d) 
Assembly 0x64 size: 30 (attrId 0x34e) 
Assembly 0x64 size: 32 (attrId 0x34f) 
Local interface IP is 192.168.1.19
EI_API_ADP_getMacAddr:  1c:63:49:20:7c:d3

Besides,in the wireshark,I couldn't find the TCP packet from the EIP board.

Can you share the network topology?

Is you PC connected to the DUT.

Also can you try to ping the DUT it it is conneceted to a PC?

The DUT is connected to pc via a RJ45 cable directly.

I tried the ping cmd and it showd that most or all of packets are lost.

Can you please share the IP address of your PC, I want to check if it is on same network.

As an update, we are not able to ping the device on today's debug call.

customer has measured RX_D0 ~RX_D3 pin and TX RX pins, there is signal on TX/RX pin but no signal on RX_D0~3 

Hang Yang said:

customer has measured RX_D0 ~RX_D3 pin and TX RX pins, there is signal on TX/RX pin but no signal on RX_D0~3 

Thanks Hang for the update, lets get review results from HW team.

Hi Nilabh,

So far, the schematic has not found any critical issue, the only issue found is on the magnetic side and is fixed, but the problem remains. We are now testing with the loopback example, and it fails too. The loopback cannot receive packets and stuck at waiting.

As we check the PRG register, we see only one frame is transferred.

Also, we are not seeing signals on TD[0-3] pins, and only saw a 121 ms pulse, which is not normal.

Could you help looking into the loopback example too? 

Regards,

Hang.

Cusotmer has corrected some configs in the syscfg, as an update to the status, they can see waveforms on RD[3] pin when running EIP stack, but still no waveform TD[0-3] pin. Below is the TX and RX registers

Hi Hang,

Nilabh is out of office and i will be supporting the query.

Could you give me some information to understand this better
1) Which is the loopback example you are using to test?

2) From the statistics, it looks like the packets are being transmitted. Did you check the pinmux configuration of TX pins?

3) Could you check if the driver is able to receive packet? - Please put a break point here - ICSS_EMAC_rxInterruptHandler and see if it is hitting or not

Regards,
Prajith

Hi Prajith, 

Sorry forget to update this thread, the original issue which is EIP connection failure is solved. So we don't need to test the loopback example anymore. 

Though EIP stack is working normally now, we still not understand the root cause of the issue, could you help explain the following behavior?

When we run the EIP stack and use the host PC the ping the device, we didn't see any response in the ping. As we probe the signals in the meantime, we picked up signals on port0 (0 is the port above,1 is the port below) RX and port1 TX, but no signals on port0 TX,  as shown in the picture. RJ45-A is connected to the host, and the red frame marks where we picked up signals. 

This looks like the am243x is responding the ping at the wrong port. It should respond on port0 instead on port1.

After switching the PHY address (address is 3 and 15, we switched it to 15 and 3)in syscfg, everything works fine, the ping, and the EIP stack.

We don't understand why am243x is responding the ping in the wrong port in the first place, and also don't under stand how PHY address is affecting the port selections, we thought these addresses are just for the MDIO interfaces.

Could you help us understand this?

Thanks,

Hang.

Hi Hang,

Glad to know the issue is fixed. Will check this and comeback by next week.

Can you confirm the customer board schematics is following the same as TI evm?

Regards,
Prajith

Hi Prajith,

They are using dp83822, which is different to evm, but the mii and mdio interfaces are similar.

The schematic has been reviewed as well. I can provide it to you if needed.

Regards,

Hang.

Hang Yang said:

nd also don't under stand how PHY address is affecting the port selections, we thought these addresses are just for the MDIO interfaces.

PHY Address to port mapping is important to extract port/link status info from MDIO as PRU firmware needs to know this

Hi Pratheesh,

Does Firmware decide which port to use based on PHY address? If that's the case, the PHY address in syscfg must be configured correctly. Is there any guide on how to configure it correctly? For example, in my case the addresses are 3 and 15, how do I know whether it should be 3/15 (PHY1/PHY2) or 15/3? 

Regards,

Hang.

Hi Hang,

Sysconfig configuration is used by icss emac driver for its operations. Firmware does not depends on PHY configuration.

There is an internal mux configuration available inside ICSS (MII_RT_RXCFGx and MII_RT_TXCFGx) which will allow PRU to do Rx and TX on any of the ports. This configuration is already taken care inside icss emac

Regards,
Prajith

Hi Prajith,

Do you mean the mux configuration is taken care inside the icss emac and has nothing to do with the syscfg? In this case,  I am still not sure why switching the PHY addresses would affect the TX/RX port, could you help me understand it?

Regards,

Hang.

Hi Hang,

Yes. I dont expect the ICSS internal mux to be dependent on Sysconfig. Let me check this with team and comeback

Regards,
Prajith

Hi Hang

As this threads was locked and is 2 months old, can you please highlight if this is still open or was there any offline conversion to close this?

Regards

Karan