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.

DP83822I: interrupt questions

Part Number: DP83822I

I have questions regarding a couple interrupts that are being observed at run-time in this post.

False Carrier Sense interrupt (MISR1, bit 9)

  • What are the causes?
  • Can you confirm that reading MISR1 and reading FCSCR is the correct way to clear the interrupt?

MDI Crossover Change interrupt (MISR2, bit 11)

  • What are the causes?
  • How do I clear it?
  • Hi Brad,

    The MDI crossover change interrupt is a notification from the PHY that auto-MDIX resolution determined a change from MDI to MDIX was needed. This interrupt should clear after it is read from the status register.

    False Carriers are defined as carrier event packets not beginning with /S/. /S/ denotes the Start_of_Packet delimiter; /S/ = /K27.7/ and is used to delineate the starting boundary of a data sequence.

    To clear the interrupt, read the MISR1 register and to reset the False Carrier sense counter, read the FCSCR register.

    Regards,
    Justin 

  • Thanks for the info.  The only data point that doesn't coincide with observations is how to clear the MDI crossover change interrupt (MISR2 bit 11).  Either reading the register is not sufficient to clear the underlying interrupt, or else for some reason we continually are getting a flood of these interrupts. Given that MDI state isn't changing more than once, I would not expect more than one of these interrupts.

    We saw similar behavior regarding the false carrier interrupt, e.g. we were continually getting reinterrupted until we added the read of the FCSCR.

  • Hi Brad,

    Does the MDI crossover change interrupt ever clear after being read? Is the link interrupted or auto-negotiation being rerun after the register is read?

    Regards,

    Justin 

  • Hi Justin,

    MDI crossover change interrupt is not getting cleared after reading it -- this interrupt keeps coming approx 5-10 times per seconds. This interrupt keeps coming only when cable is not connected (no link).

    Link condition in not "changed" and no auto-negotiation after the register is read.

    It is also observed that this interrupt also keeps coming for PHYs for which cable is never connected after device reset.

    Thanks,

    Paritosh

  • Hi Paritosh,

    How are you able to confirm the interrupt is occurring 5-10 times per second if the interrupt is not cleared? The Auto-MDI/MDIX protocol takes about 1-2 seconds to complete so I do not expect the crossover change to occur so fast, so often. If the crossover change interrupt is disabled, please confirm that no interrupts are being detected. 

    Can you provide some more information about the configuration of the phy? Are you using auto-negotiation or Auto-MDI/MDIX or forcing speed and cable connection? 

    Regards,

    Justin 

  • Hi Justin,

    As you can see here , interrupts occurring at that rate (see section under "Without patch ..").

    Do you want to see if interrupts keep occurring if driver does not read MISR2 ?

    If the crossover change interrupt is disabled, this interrupt is not detected. See here.

    PHY Configuration in DTS: https://e2e.ti.com/support/processors/f/791/p/888389/3285564#3285564

    I am using a Gigabit Ethernet switch for testing. Not forcing speed and any other settings using Linux tools. These are default as in Driver dp83822.c of SDK 6.02 and , possibly, as auto-negotiated.

    I am testing using connecting and disconnecting cable.  Crossover change interrupt keep occurring even on PHYs that I am not using in testing and that never had link up (this device has 4 PHYs).

    Please let me know any other specific configuration you need, and how can I access it ?

    Thanks,
    Paritosh

  • Hi Paritosh,

    I apologize for the delay, I needed input from our design team. The MDI crossover change interrupt will toggle before the device is linked since MDI resolution is in progress. Once a stable link is established the interrupt should be cleared on read and not be triggered again. 

    Regards,
    Justin 

  • Justin Lazaruk said:
    Once a stable link is established the interrupt should be cleared on read and not be triggered again. 

    What is expected to happen when the link is lost (e.g. cable unplugged)?  The observation is that we get never-ending interrupts.  Is this expected?  It is not the desired behavior...

  • Hi Brad,

    When the cable is disconnected it will go back to toggling, any condition that causes link drop will make the interrupt toggle.

    Regards,
    Justin 

  • Justin,

    I'm trying to figure out an appropriate way of using this interrupt.  At a minimum it needs to be disabled when we don't have a link, otherwise we get an interrupt flood.  However, if I wait to enable it after a link has already been established, would I already have missed the MDIX interrupt at that point?  Perhaps I can't even use the interrupt at all and should simply read the status as part of the link interrupt?

    Brad

  • Hi Brad, 

    I do not believe this interrupt is functioning the way it was intended, so I am not sure there is an intelligent way to use this interrupt. Register 0x0B[5] will provide the information about whether the PHY resolved to MDI or MDIX mode. In determining the status of the part, Link Status interrupt will behave the same without flooding the interrupt manager.

    Regards,
    Justin 

  • Justin,

    Do you have any further details about the timing of the MDI/MDIX mode?  Would that happen in very close proximity to the link completion?  I'm wondering if the status can simply be checked when we get the link interrupt,

    Thanks,

    Brad

  • Hi Brad, 

    Auto-MDI/MDIX will resolve before Auto-Negotiation is completed. 

    Regards,
    Justin