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: DP83867 - WoL interrupt on pattern match

Part Number: DP83867IS

I have a few questions on WoL interrupt generation on DP83867

1. There is little said in the datasheet about how destination address DA (regs 0x136-0x138 and pattern regs 0x13C..0x15B) interact. Do both DA AND pattern have to match to issue an IRQ?).

2. Pattern Match Data Registers has MAC address bits defined as [15..0], [31..16], [47..32]. I have the following MAC address 01:00:5E:00:01:81 and write those registers as 0x0001 -> 0x136, 0x005E -> 0x137, 0x8101 -> 0x138. Have I correctly understood the datasheet that lower byte needs to be written to lower byte of RXFPMDx and upper byte into the upper byte?

3. Description of RXFCFG (0x134):

Are bits WAKE_ON_BCAST and WAKE_ON_UCAST independent of WAKE_ON_PATTERN and WAKE_ON_MAGIC?

Can I use just two of them to cause an interrupt?

If I set WAKE_ON_BCAST is interrupt asserted on any broadcast packet or only one that matches pattern?

 

4. I set interrupts in the following way:

     // enable enhanced receive features

    write_phy_DP83867_reg(baseaddr_miim, phyid, MIIM_DP83867_CFG2, MIIM_DP83867_CFG2_INTPOL); // negate polarity

    write_phy_DP83867_reg(baseaddr_miim, phyid, MIIM_DP83867_CFG3, MIIM_DP83867_CFG3_INT_OE); // enable driving INTZ line

    write_phy_DP83867_reg(baseaddr_miim, phyid, MIIM_DP83867_RXFCFG,

                                      MIIM_DP83867_RXFCFG_ENH|          // enable WOL

                                      MIIM_DP83867_RXFCFG_WAKE_PATTERN| // wake on pattern

                                      MIIM_DP83867_RXFCFG_WAKE_UCAST|   // unicast

                                      MIIM_DP83867_RXFCFG_WAKE_BCAST|   // broadcast

                                      MIIM_DP83867_RXFCFG_WOL_STRETCH(3));

 

write_phy_DP83867_reg(baseaddr_miim, phyid, MIIM_DP83867_MICR, MIIM_DP83867_MICR_WOL);  // Enable WOL interrupt

If I assert interrupts on purpose, i.e.:

            write_phy_DP83867_reg(baseaddr_miim, phyid, MIIM_DP83867_CFG3, MIIM_DP83867_CFG3_INT_OE|MIIM_DP83867_CFG3_INT_ASSERT);

and

           write_phy_DP83867_reg(baseaddr_miim, phyid, MIIM_DP83867_CFG3, MIIM_DP83867_CFG3_INT_OE);

 I can see interrupt is asserted on INTN/PWDN line (pin 44), but not upon receiving a packet.

 

 And the last one about RXFSTS (0x135) – when I read it I always read 0 from it. When I read back RXFCFG (0x134) I read exactly the bits I set up.

According to the datasheet (March, 2017) the following bits are defined:

 UCAST_RCVD

BCAST_RCVD

PATTERN_RCVD

 I see MAC receives packets and SFD line on GPIO pins show it but I never read back those bits from RXFSTS. Can I get WoL interrupt on non-matching broadcast packet?

Thanks!

  • Hi Alex,

    Sorry that there is not much information in the DP83867IS datasheet about this feature.
    It is also found in the DP83822. I have made an application note detailing WoL for use with the DP83822, but it is interchangeable with the DP83867IS.
    Please see this document for your review:
    www.ti.com/.../snla261.pdf

    Kind regards,
    Ross
  • Thanks, Ross,

    I went thru the datasheet and AN for DP83822 and your examples.

    I reassigned WOL into GPIO1 line instead of TXSFD signal:

        // configure MUX_CTRL
        write_phy_DP83867_reg(baseaddr_miim, phyid, MIIM_DP83867_GPIO_MUX,
                              MIIM_DP83867_GPIO0_RXSFD|
                              MIIM_DP83867_GPIO1_WOL);

    When I done that I can see WOL pulse following the end of the RXSFD pulse which is as expected.

    Unfortunately, I cannot get WoL interrupt on INTN line. I understand that WoL can cause an interrupt

    To set up interrupt I write in the following order:

    INTERRUPT_POLARITY (bit 13) into CFG2 register (0x0014)

    INT_OE (bit 7) into CFG3 register (0x001E)

    WOL_INT_EN (bit 3) into MICR register (0x0012)

    and finally:

        write_phy_DP83867_reg(baseaddr_miim, phyid, MIIM_DP83867_RXFCFG,
                              MIIM_DP83867_RXFCFG_WOLCLR|       // clear WOL line
                              MIIM_DP83867_RXFCFG_ENH|          // enable WOL
                              MIIM_DP83867_RXFCFG_WAKE_PATTERN| // wake on pattern
                              MIIM_DP83867_RXFCFG_WAKE_UCAST|   // unicast
                              MIIM_DP83867_RXFCFG_WAKE_BCAST|   // broadcast
                              MIIM_DP83867_RXFCFG_WOL_STRETCH(3));

    0x696 into RXFCFG (0x0134) register

    What else do I need to write to cause interrupt line to issue pulse equivalent to WOL on GPIO1 line?

    It looks like if I don't set MIIM_DP83867_RXFCFG_WOL_MODE (bit 8) into 0x0134 I see both INTN signal in level mode (i.e. I have to write WOL Clear (bit 11) into 0x0134 to de-assert it).

    If I set MIIM_DP83867_RXFCFG_WOL_MODE (bit 8) into 0x0134 both INTN and WOL routed to GPIO1 disappears.

    My goal is to be able to measure TXSFD on GPIO1, RXSFD on GPIO0 and WOL on INTN lines. Do you have any notes on how to handle INTN line in pulse mode?

    Thanks,

    --Alex

  • Hi Alex,

    Have you confirmed the INT pin is operating as you expect?
    Can you try a test run on the INT pin by using the force interrupt bit[6]?

    Also, can you try an interrupt on a different function (i.e. enable link change) to see if the INT pin is changing state.

    Kind regards,
    Ross
  • Hi Alex,

    Also, please keep in mind that the INT pin is an open drain.
    You need a pull-up on this pin to VDDIO.

    Kind regards,
    Ross
  • Yes, I confirmed - a read from ISR (0x0013) clears interrupt line. It's counter-intuitive because WOL_INT is the only bit in the ISR which is not stated "is cleared by the current read". Instead I was under impression that I need to use WOL_CLEAR in RXFCFG 0x0134 to clear it in level mode or do nothing in pulse mode.
  • It is pulled-up: 4.7k to 2.5V and also 4.7k weak pull-up in FPGA to 2.5V
  • Hi Alex,

    Did Ross resolve your issue? If so, I will close this thread.

    Thanks,
  • The issue is resolved. Thanks!