• State
  • Locked Locked
  • Replies 21 replies
  • Subscribers 33 subscribers
  • Views 1981 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

DP83630: False Carrier Sense Error and Receive Error Latch

Saravanakumar S93
Expert 1300 points
Part Number: DP83630
Other Parts Discussed in Thread: HALCOGEN

Hi All,
Currently, we are trying for the TI example program using Launchpad XL2 RM57 <=> Launchpad XL2 RM57.
This board consists of DP83630 Ethernet PHY Transceiver IC. We are able to establish the physical & Link Layer.
Herewith I have attached my Transmit Code for the reference.

Below are the configurations,
    # ACT & LINK LEDS are blinking
    # VCLK4=40MHz(or)75 MHz=> We are getting the same behaviour for the both the clock
    # Channel 0
    # BROADCAST addressing
    # MAC ADDRESS(Point to Poin.There is no IP address configured as of now. Sending the packets in Broadcast MAC address)
    # Phy address=0x01 for the both the launchpad XL2-RM57
   
Below are the MCU register reading status,
        MACINTMASKSET     0x00000000  
        MACINTSTATMASKED 0x00000000  
        MACCONTROL         0x00000023 
        MACSTATUS         0x80000000                                         
        MACINVECTOR         0x00010001 
        MACEOIVECTOR     0x00000002 
        MACINTSTATRAW     0x00000000  
        MDIO_LINK         0x00000002  
        MDIO_LINKINTRAW     0x00000000  
        MDIO_LINKINTMASKED 0x00000000  
        MDIO_USERACCESS0 0x20A1CDE1                                     
        MDIO_USERPHYSEL0 0x00000000  
        TXINTMASKSET     0x00000001  
        RXINTMASKSET     0x00000001  
        TXINTMASKCLEAR     0x00000001  
        RXINTMASKCLEAR     0x00000001  
        TXINTSTATRAW     0x00000001  
        RXINTSTATRAW     0x00000001  
        TXINTSTATMASKED     0x00000001  
        RXINTSTATMASKED     0x00000001  
        CPGMAC_INTCONTROL 0x00000000  
        C0MISCEN         0x00000000  
        C0MISCSTA           0x00000000

Below are the PHY register(DP83630) reading status,
0x00 BMCR       0x3100
0x01 BMSR       0x78ED
0x04 ANAR       0x01E1
0x05 ANLPAR       0x41E1
0x06 ANER       0x0007
0x07 ANNPTR       0x2801
0x10 PHYSTS       0x2815
0x11 MICR       0x0000
0x12 MISR       0x2F00(First Time Read)
                         0x0300(Second Time Read)
0x13 PAGESEL       0x0000
0x14 FCSCR               0x00FF(First Time Read)
                                    0x00FF(Second Time Read)                
0x15 RECR          0x00FF(First Time Read)
                             0x00FF(Second Time Read)
0x16 PCSR       0x0100
0x17 RBR           0x0001
0x18 LEDCR       0x0000
0x19 PHYCR       0x8021
0x1A 10BTSCR       0x0804
0x1B CDCTRL1       0x0000
0x1C PHYCR2       0x0002
0x1D EDCR       0x6011
0x1F PCFCR       0x0000
                              
 
As per the above register status analysis,
    #We are getting the False Carrier Sense(Packet Error)/Receiver Error Latch. But, the polariy is correct.
    #Even if you reread the register twice(False Carrier Counter), the register is not getting cleared.
    #Even if you reread the register twice(Receive Error Counter), the register is not getting cleared.

Below are the clarifications,   
    # Could you please give your valuable feedback, How can we resolve the False Carrier/Receive Error Latch issue?
    # Do we need to connect any external resistance as per the below link recommendation?
        e2e.ti.com/.../785415
    # Does any one give the Example Code/Sample Code
Thank you.

Regards,
S.Saravanakumar

Ethernet.zip

  • 0
    TI__Genius 11725 points

    Hello S. Saravanakumar,

    What is the desired MAC interface mode (RMII Master or RMII Slave)? What is the input reference clock frequency?

    Thank you,

    Nikhil

  • 0 in reply to Nikhil Menon
    Expert 1300 points

    Hi Nikhil,

    Currently, we are using the MII MAC interface. The input reference clock frequency is 25 MHz.

    Regards,

    S.Saravanakumar

  • 0 in reply to Saravanakumar S93
    TI__Genius 11725 points

    Hi S.Saravanakumar,

    Yes, to use MII mode, the RX_DV strap needs to be set for Mode 0. If the connected MAC has an internal pull-up on this pin, it's possible there is some contention, causing the PHY to latch into RMII mode. In this case, the external pull will be required. Can you provide a schematic? What is the internal pull on the connected device for the RX_DV pin?

    Thank you,

    Nikhil

  • 0 in reply to Nikhil Menon
    Expert 1300 points

    Hi Nikhil,
    As mentioned in the initial clarification query, we are using TI LaunchpadXL2-RM57L board(2 nos).
    Please find the schematics in the below link, Design files-> TMS570LC43x and RM57Lx LaunchPad Schematic — SPRR397.PDF
        https://www.ti.com/tool/LAUNCHXL2-RM57L

    We are using RM57 based microcontroller. Also, we are trying the EMAC example program given in the HALCOGEN Tool.
    By default, both the board has individual PHY address as "00001"

    Regards,
    S.Saravanakumar

  • 0 in reply to Saravanakumar S93
    TI__Genius 11725 points

    Hi S.Saravanakumar,

    Thanks for clarifying the schematic file. It looks like there is a pull-down on RX_DV to correctly set the device for MII Mode, matching the values read from register 0x17.  

    Without connecting the cable, can the MAC be set to generate packets and count errors? If so, can the PHY be set for Internal Loopback mode as described by Section 5.8 in the datasheet? If the MAC can generate packets, and the PHY can loop them back to the MAC without errors, this may help identify the Media Independent Interface as the source of errors. 

    Thank you,

    Nikhil

  • 0 in reply to Nikhil Menon
    Expert 1300 points

    Hi Nikhil,

    We are not checking the Ethernet loopback. As per the attached screenshot, we are checking the point to point communication between 2 nos of Launchpad XL2-RM57 board.  I am attaching the screenshots for your quick reference,.

    I am not getting the below question as usual, what you are trying to say:

    >> "Without connecting the cable, can the MAC be set to generate packets and count errors? If so, can the PHY be set for Internal Loopback mode as described by Section 5.8 in the datasheet? If the MAC can generate packets, and the PHY can loop them back to the MAC without errors, this may help identify the Media Independent Interface as the source of errors" 

    As a part of your daily question, please let me know if you have any more clarifications.

    Regards,

    S.Saravanakumar

  • 0 in reply to Saravanakumar S93
    TI__Genius 11725 points

    Hi S.Saravanakumar,

    I understand that there are two launchpad's connected together across the MDI. 

    To further clarify my comment about MII loopback, I am trying to isolate the MII interface as the source of the error. With a single Launchpad XL2 RM57 board (without connecting the PHYs across the cable) can the PHY on one board be configured for MII loopback, and can the MCU on the same board be configured to generate MII packets to the PHY? The PHY will loop the packets back to the MCU, and if the MCU can count the packets and errors, this will help determine if errors are coming from the MII side. Is this setup possible?

    Thank you,

    Nikhil

  • 0 in reply to Nikhil Menon
    Expert 1300 points

    Hi Nikhil,

    We are able to receive the messages under the following loopback conditions,

             1. EMAC Enable loopback with Auto Negotiation Disabled option. There is no external loopback Ethernet cable connected.

             2. Phy loopback & EMAC enable loopback with Auto Negotiation Disabled option.

                 External loopback Ethernet cable is connected(TX+ --> RX+, TX- --> RX-)

                            >> During the PHY LOOPBACK Condition, the PHYSTS register value=0x0004

    During the point to point connection of Launchpad XL2-RM57(2 nos). We are getting the false carrier sense and Receive Error latch.

    Kindly give your feedback, where could be the problem lying down. How to proceed further.

    Herewith, I have attached the code of EMAC Loopback & Phy Loopback.

    Regards,

    S.Saravanakumar

    emac_loopback1.zip

  • 0 in reply to Saravanakumar S93
    TI__Genius 11725 points

    Hi S.Saravanakumar,

    We are looking into this issue and will provide additional feedback by Thursday latest.

    Thank you,

    Nikhil

  • 0 in reply to Nikhil Menon
    Expert 1300 points

    Hi Nikhil,

    Please let me know, if you have any additional input from my end.

    Regards,

    S.Saravanakumar

  • 0 in reply to Saravanakumar S93
    TI__Genius 11725 points

    Hi S.Saravanakumar,

    Some follow-up questions:

    • Can external loopback be tried on both boards? Connecting a cable that routes TX -> RX on the same PHY?
    • Are false carrier events observed on both boards or just one side?
    • What is the cable length when false carriers are observed?

    Thank you,

    Nikhil

  • 0 in reply to Nikhil Menon
    Expert 1300 points

    Hi Nikhil,

    #External loopback is tried on both the boards connecting cable Tx+ to Rx+ , Tx- to Rx-.

    #During point to Point communication, false carrier failure observed on both the boards.

        Board1=Transmit only

        Board2=Receive only

    #Cable length is 15cm

    I am giving additional below info. Otherwise, you will ask another question and postponed this query to next week, without giving any solution.

    #We are getting the same behaviour for Self made cross cable as well 1:1 cable. The cross cable is made with correct pin configuration. We have tested the cables with ethernet cable tester.

    In case, if u have any working sw, you can attach it here. Just i will import it and check it as it is.

    Regards,

    S.Saravanakumar

  • 0 in reply to Saravanakumar S93
    TI__Genius 11725 points

    Hi S.Saravanakumar,

    15cm is considered a "very short cable" and we have seen link quality issues with such a short cable. This could cause the false carrier events. Can a ~5-10m cable be tried? Will the end application use such a short cable?

    Thank you,

    Nikhil

  • 0 in reply to Nikhil Menon
    Expert 1300 points

    Hi Nikhil,
    Our end application didnt want to use such a short cable.
    Since, Launchpad XL2-RM57 board is not using the external crystal oscillator to generate the ECLK frequency for DP83630.
    Will it drive the such a long Ethernet cable(5 to 10m) ?

    Regards,
    S.Saravanakumar

  • 0 in reply to Saravanakumar S93
    TI__Genius 11725 points

    Hi S.Saravanakumar,

    Yes this distance should be ok. What would be the approximate cable length used in end application?

    Thank you,

    Nikhil

  • 0 in reply to Nikhil Menon
    Expert 1300 points

    Hi Nikhil,

    The approximate cable length will be 2-4 meters in our end applications.

    Regards,

    S.Saravanakumar

  • 0 in reply to Saravanakumar S93
    TI__Genius 11725 points

    Hi S.Saravanakumar,

    Has the 5-10m cable been tested? Any issues with this cable length?

    Thank you,

    Nikhil

  • 0 in reply to Nikhil Menon
    Expert 1300 points

    Hi Nikhil,

    We have tested with 5m cable. We are getting the same False carrier sense and receive error latch.

    Regards,

    S.Saravanakumar

  • 0 in reply to Saravanakumar S93
    TI__Genius 11725 points

    Hi Saravankumar,

    Given you have tested external loopback and have not seen errors, and errors only occur when the two boards are connected together, and a normal cable length is used, this is not a straightforward debug. I will reach out to our Hercules team and provide an update by Thursday of this week.

    Thank you,

    Nikhil