This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DP83867IS: need confirm about auto-negotiation enable

Part Number: DP83867IS

Hi,

I would like to confirm that TI's DP83867 datasheet is confusing.

Is it true that auto-negotiation is enabled at MODE 1?

( "Autoneg disable N/A" means enable?)

Any advice is welcome.

thanks,

TS

  • Hello TS,

    Thank you for using the TI forum. Our product expert will get back to you by Friday.
  • Hello Mitch,

    Thank for your kindly notice.

    With the TI DP83867 phy chip connected to the SGMII interface,

    At speed 100 / 1000M, link up, tx and rx are normal,

    In the speed 10M state, link up and tx operation is normal, but rx operation is not normal.

    (In the ping operation, the recv increase in the other device is confirmed.)

    I have two more questions as below.

    1. In the datasheet, only 100/1000 is explained in relation to SGMII function as below. Is it possible to communicate with 10M in sgmii state?

    2. Please explain about 10M_SGMII_CFG register. The datasheet contains only the following sentences.

    “The 10M_SGMII_RATE_ADAPT bit (bit 7) of 10M_SGMII_CFG register (0x016F) needs to be cleared for enabling 10M SGMII operation.”

    thanks,

    TS

     

  • Hello TS,

    To reply to your original question, N/A means Not Applicable. It means that RX_CTRl should not be used in Mode 1 or Mode2. RX_CTRL should be strapped to mode 3 or mode 4.
    For 10M communication in SGMII, write '0' to bit 7 in register 0x16F. Other connections and register values will be same for 10M SGMII as they are for 100M/1000M SGMII operation.

    -Regards,
    Aniruddha
  • Hello Aniruddha,

    thanks for your answer.

    In addition, link up and communication are operating normally at speed 100 / 1000M.

    However, at speed 10M, only link up is done well but communication is not possible.

    Is there any difference between 10M and 100 / 1000M?

    As a result of the software check, when set the speed to 10M as shown in the log below,

    the TX packets normally go out, and the partner device normally receives the response packets,

    but the RX packets are not received.

    Since the count of the 'frame' item in the log shown below is increased,
    it seems that the size of the frame of the packets coming into RX is not normal, so communication is not possible.

     


     

     

    - V5808U

    *SWITCH# ./phy_read 1 1 14

    phyaddr1 reg14 : 00000015

    *SWITCH# ./phy_write 1 1 4 0x61    <- Change auto nego setting to speed 10M

    *SWITCH# Oct 13 04:29:29 2017  system: mgmt - Link is Up - 10/Full

    *SWITCH#

    *SWITCH# Oct 13 04:29:39 2017  system: mgmt - Link is Down

    Oct 13 04:29:40 2017  system: mgmt - Link is Up - 10/Full

    *SWITCH#

    *SWITCH# ping 10.56.23.111

    PING 10.56.23.111 (10.56.23.111) 56(84) bytes of data.

    From 10.56.30.11 icmp_seq=1 Destination Host Unreachable

    From 10.56.30.11 icmp_seq=2 Destination Host Unreachable

    From 10.56.30.11 icmp_seq=3 Destination Host Unreachable

    From 10.56.30.11 icmp_seq=4 Destination Host Unreachable

    From 10.56.30.11 icmp_seq=5 Destination Host Unreachable

    From 10.56.30.11 icmp_seq=6 Destination Host Unreachable

     

    --- 10.56.23.111 ping statistics ---

    7 packets transmitted, 0 received, +6 errors, 100% packet loss, time 6030ms

    , pipe 3

    *SWITCH# ifconfig mgmt

    mgmt      Link encap:Ethernet  HWaddr 00:D0:CB:9D:28:72

              inet addr:10.56.30.11  Bcast:10.56.255.255  Mask:255.255.0.0

              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

              RX packets:15 errors:0 dropped:0 overruns:0 frame:9

              TX packets:24 errors:0 dropped:0 overruns:0 carrier:0

              collisions:0 txqueuelen:1000

              RX bytes:1482 (1.4 KiB)  TX bytes:1512 (1.4 KiB)

              Base address:0x8000

    *SWITCH# ping 10.56.23.111

    PING 10.56.23.111 (10.56.23.111) 56(84) bytes of data.

    From 10.56.30.11 icmp_seq=1 Destination Host Unreachable

    From 10.56.30.11 icmp_seq=2 Destination Host Unreachable

    From 10.56.30.11 icmp_seq=3 Destination Host Unreachable

    From 10.56.30.11 icmp_seq=4 Destination Host Unreachable

    From 10.56.30.11 icmp_seq=5 Destination Host Unreachable

    From 10.56.30.11 icmp_seq=6 Destination Host Unreachable

    From 10.56.30.11 icmp_seq=7 Destination Host Unreachable

    From 10.56.30.11 icmp_seq=8 Destination Host Unreachable

    From 10.56.30.11 icmp_seq=9 Destination Host Unreachable

    From 10.56.30.11 icmp_seq=10 Destination Host Unreachable

    From 10.56.30.11 icmp_seq=11 Destination Host Unreachable

    From 10.56.30.11 icmp_seq=12 Destination Host Unreachable

    From 10.56.30.11 icmp_seq=13 Destination Host Unreachable

    From 10.56.30.11 icmp_seq=14 Destination Host Unreachable

    From 10.56.30.11 icmp_seq=15 Destination Host Unreachable

    From 10.56.30.11 icmp_seq=16 Destination Host Unreachable

    From 10.56.30.11 icmp_seq=17 Destination Host Unreachable

    From 10.56.30.11 icmp_seq=18 Destination Host Unreachable

    From 10.56.30.11 icmp_seq=19 Destination Host Unreachable

    From 10.56.30.11 icmp_seq=20 Destination Host Unreachable

    From 10.56.30.11 icmp_seq=21 Destination Host Unreachable

     

    --- 10.56.23.111 ping statistics ---

    24 packets transmitted, 0 received, +21 errors, 100% packet loss, time 23127ms

    , pipe 3

    *SWITCH# ifconfig mgmt

    mgmt      Link encap:Ethernet  HWaddr 00:D0:CB:9D:28:72

              inet addr:10.56.30.11  Bcast:10.56.255.255  Mask:255.255.0.0

              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

              RX packets:15 errors:0 dropped:0 overruns:0 frame:33

              TX packets:48 errors:0 dropped:0 overruns:0 carrier:0

              collisions:0 txqueuelen:1000

              RX bytes:1482 (1.4 KiB)  TX bytes:2520 (2.4 KiB)

              Base address:0x8000

     

    *SWITCH#



    Any advice is welcome.

    TS

  • Please remind that I'm still waiting your answer.
  • Hello TS,

    Before conducting the test, was bit 7 in register 0x16F set to '0'. It is not shown in the command line data dump you have shared above. Please not that 0x16F will need extended memory access as described in the datasheet.

    For future reference, I would recommend opening new thread for new questions so that it gets better visibility.

    -Regards,
    Aniruddha