DP83822I: The DP83822I issue for the Ethernet Transceiver

Part Number: DP83822I
Other Parts Discussed in Thread: AM3358,

Tool/software:

Hi,

We use the DP83822I for the Ethernet transceiver in our AM3358 board, and now, we find our mass product have the below issue for some board:

1. The network cards can be correctly recognized, but only eth0 is normal, eth1 cannot ping, and there is no network available, for this case, we can reboot or reset the uboot when we don't turn off the power

    that the ethernet signal will normal;

2. Similar as item#1, we reboot or reset the uboot but the ethernet signal is also abnormal;

3. Both eth1 and eth0 can be recognized normally, and the network is also normal. However, after repeated power on and power off tests, eth0 cannot be recognized, and the eth0 RJ45 light doesn't light up;

We have no idea how to solve the issue, and please kindly review below schematic diagram and provide your commend that how to check the HW or SW design, and we can solve the issue;

BTW, this issue don't happen in every board, it maybe about 2%-5% probability in our mass product, it is very serious impact on production efficiency, thanks.

  • Hi Zhang,

    Please correct me if my understanding is wrong.

    • Are you looking for RMII slave mode for DP83822 PHY?
    • If so, I did not see any strap resistors on the RX_DV pins. It seems like the PHY initially strap in the MII mode which input 25MHz instead of 50MHz. May I ask did you change it to RMII slave mode through registers write?
    • If so, we highly recommend configure the PHY into RMII slave mode through hardware strapping instead of register writ. This might possibility   mess up some of the clock signal block during power up before the PHY is configure to RMII slave mode through register.

    --

    Regards,

    Hillman Lin

  • Hi Hillman,

    Thanks for your reply.

    We push up the RX_DV with the 2.49Kohm resistor, so we have set the RMII for the slave mode with the hardwave strapping;

    The below is our register and pleaes kindly review if there are any error:

    reg: 0x0 value : 0x3100
    reg: 0x1 value : 0x786d
    reg: 0x2 value : 0x2000
    reg: 0x3 value : 0xa240
    reg: 0x4 value : 0x1e1
    reg: 0x5 value : 0xcde1
    reg: 0x7 value : 0x2001
    reg: 0x9 value : 0x0
    reg: 0xa value : 0x100
    reg: 0xb value : 0x100b
    reg: 0xf value : 0x0
    reg: 0x10 value : 0x1715
    reg: 0x11 value : 0x108
    reg: 0x12 value : 0x6400
    reg: 0x13 value : 0x2a00
    reg: 0x14 value : 0x0
    reg: 0x15 value : 0x0
    reg: 0x16 value : 0x100
    reg: 0x17 value : 0x2c9
    reg: 0x18 value : 0x400
    reg: 0x19 value : 0x8c03
    reg: 0x1a value : 0x10
    reg: 0x1b value : 0x7d
    reg: 0x1c value : 0x5ee
    reg: 0x1e value : 0x102

    And then, the failure DP83822I still have this issue when we SMT in the good board, so please also help to advise how to solve this issue, thanks.

  • HI Zhang,

    Based on the register 0x0001bit[2] read, it seems like DP83822 is link up fine. Is this register log are based on the abnormal scenario?

    --
    Regards,

    Hillman Lin

  • Hi Hillman,

    Yes, but the normal and abnormal device is the same register map, so we have no idea why we meet this issue.

  • Hi Zhang,

    If the PHY is always link up that means the issue is mostly not on the PHY to PHY connection or MDI interface.

    Let check on the SoC and MAC interface.

    • If possible, could customer write 0x0000bit[14] = 0 (MII loopback). After that customer could try to send a packets on the SoC side and see if the same SoC is able to receive the signals?

    --

    Regards,

    Hillman Lin