DP83TC813S-Q1: RMII can work but RGMII can not work

Part Number: DP83TC813S-Q1

Hi team,

We use two board, each board has a MCU and DP83TC813S.When two DP83TC813S uses RMII to connect with MCU, two DP83TC813S can ping successfully. But when using RMGII, connection can not be successful.

The only difference of register between RMII and RGMII is 16h.

mmexport1785761604529.png

When they use TI DP83TC813EVM to connect their own board, it can not ping successfully.

Can you point out some directions to solve it?

  • Hi Gary,

    Please help share schematic. Please also share a block diagram for customer's system which is failing ping. 

    RGMII protocol has timing constraints that need to be met: Skew should be introduced between CLK and data on TX and RX side:

    Please see 812 troubleshooting guide for debug guidance.  

    Best,

    Charles 

  • Hi Charles,

    Thanks for your reply.

    Please see schematic:

    Schematic_ethercat_over_t1_071.pdf

    I’d also like to add a bit more information: I tested the RMII link using iperf3 yesterday, and there was about 20% packet loss.

    Receive end:

    root@OK3588-C-buildroot:~# ethtool -S eth1 | grep rx

        mmc_rx_framecount_gb: 325389065

        mmc_rx_octetcount_gb: 780139506

        mmc_rx_octetcount_g: 335341243

        mmc_rx_broadcastframe_g: 0

        mmc_rx_multicastframe_g: 7

        mmc_rx_crc_error: 66430081

        mmc_rx_align_error: 0

        mmc_rx_run_error: 0

        mmc_rx_jabber_error: 0

        mmc_rx_undersize_g: 0

        mmc_rx_oversize_g: 0

        mmc_rx_64_octets_gb: 0

        mmc_rx_65_to_127_octets_gb: 0

        mmc_rx_128_to_255_octets_gb: 0

        mmc_rx_256_to_511_octets_gb: 0

        mmc_rx_512_to_1023_octets_gb: 0

        mmc_rx_1024_to_max_octets_gb: 0

        mmc_rx_unicast_g: 0

        mmc_rx_length_error: 0

        mmc_rx_autofrangetype: 0

        mmc_rx_pause_frames: 0

        mmc_rx_fifo_overflow: 0

        mmc_rx_vlan_frames_gb: 0

        mmc_rx_watchdog_error: 0

        mmc_rx_ipc_intr_mask: 708979299

        mmc_rx_ipc_intr: 0

        mmc_rx_ipv4_gd: 259238812

        mmc_rx_ipv4_hderr: 1752307

        mmc_rx_ipv4_nopay: 0

        mmc_rx_ipv4_frag: 0

        mmc_rx_ipv4_udsbl: 0

        mmc_rx_ipv4_gd_octets: 0

        mmc_rx_ipv4_hderr_octets: 2586560231

        mmc_rx_ipv4_nopay_octets: 0

        mmc_rx_ipv4_frag_octets: 0

        mmc_rx_ipv4_udsbl_octets: 0

        mmc_rx_ipv6_gd_octets: 0

        mmc_rx_ipv6_hderr_octets: 0

        mmc_rx_ipv6_nopay_octets: 0

        mmc_rx_ipv6_gd: 3

        mmc_rx_ipv6_hderr: 0

        mmc_rx_ipv6_nopay: 0

        mmc_rx_udp_gd: 0

        mmc_rx_udp_err: 63726728

        mmc_rx_tcp_gd: 0

        mmc_rx_tcp_err: 1

        mmc_rx_icmp_gd: 0

        mmc_rx_icmp_err: 0

        mmc_rx_udp_gd_octets: 0

        mmc_rx_udp_err_octets: 2591802760

        mmc_rx_tcp_gd_octets: 0

        mmc_rx_tcp_err_octets: 69

        mmc_rx_icmp_gd_octets: 0

        mmc_rx_icmp_err_octets: 0

        mmc_rx_packet_assembly_err_cntr: 274832

        mmc_rx_packet_smd_err_cntr: 688093

        mmc_rx_packet_assembly_ok_cntr: 0

        mmc_rx_fpe_fragment_cntr: 0

        rx_desc: 0

        rx_collision: 0

        rx_crc_errors: 0

        rx_length: 0

        rx_mii: 0

        rx_multicast: 0

        rx_gmac_overflow: 0

        rx_watchdog: 0

        da_rx_filter_fail: 0

        sa_rx_filter_fail: 0

        rx_missed_cntr: 0

        rx_overflow_cntr: 0

        rx_vlan: 0

        rx_split_hdr_pkt_n: 0

        rx_overflow_irq: 0

        rx_buf_unav_irq: 0

        rx_process_stopped_irq: 0

        rx_watchdog_irq: 0

        rx_early_irq: 41

        rx_pkt_n: 258958984

        rx_normal_irq_n: 258957761

        mmc_rx_irq_n: 0

        mmc_rx_csum_offload_irq_n: 0

        irq_rx_path_in_lpi_mode_n: 0

        irq_rx_path_exit_lpi_mode_n: 0

        no_ptp_rx_msg_type_ext: 258958984

        ptp_rx_msg_type_sync: 0

        ptp_rx_msg_type_follow_up: 0

        ptp_rx_msg_type_delay_req: 0

        ptp_rx_msg_type_delay_resp: 0

        ptp_rx_msg_type_pdelay_req: 0

        ptp_rx_msg_type_pdelay_resp: 0

        ptp_rx_msg_type_pdelay_follow_up: 0

    PHY register:

        ptp_rx_msg_type_announce: 0

        ptp_rx_msg_type_management: 0

        ptp_rx_msg_pkt_reserved_type: 0

        mtl_rx_fifo_fill_level_full: 0

        mtl_rx_fifo_fill_above_thresh: 0

        mtl_rx_fifo_fill_below_thresh: 0

        mtl_rx_fifo_fill_level_empty: 0

        mtl_rx_fifo_read_ctrl_flush: 0

        mtl_rx_fifo_read_ctrl_read_data: 0

        mtl_rx_fifo_read_ctrl_status: 0

        mtl_rx_fifo_read_ctrl_idle: 0

        mtl_rx_fifo_ctrl_active: 0

        mac_rx_frame_ctrl_fifo: 0

        mac_gmii_rx_proto_engine: 0

        q0_rx_pkt_n: 258958984

        q0_rx_irq_n: 258957761

    eth1 RX receive muc CRC error frames

  • Hi Gary,

    Please read packet counters in sequence 0x639-0x63e. The results you show above are valid but if packet counters are read out of sequence, they will not increment until cleared with 0x639-0x63e read. 

    You can take these steps for debug: 

    PHY functionality check: 

    • Probe CLKOUT (pin 16). Expect 50 MHz buffered oscillator CLK.
    • Read 0x01: Expect 0x01[2] = 1 for MDI link-up
    • Check sampled strap register 0x45D matches strapping in schematic

    MDI side check: 

    MAC side check: 

    After performing these 3 tests, you will be able to isolate where packet drops are occurring. Please let me know if you have any questions. 

    Best,

    Charles