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.

DP83867IR: Result of the register in WOL Interrupt Processing

Part Number: DP83867IR

Hi Team,

The last question as I posted had not been resolved. And this development had been pended because of the customer side reason.

https://e2e.ti.com/support/interface/f/138/p/733624/2742975#pi320995=1

Now the customer have restarted this development and they have still same issue. So , I would like to ask again.

The background;

- The customer confirmed "Wake-up" at Magic Packet reception, but the status is not the expected value.

- The status is as bellow,

① The result of reading the ISR register is "0x0000"

 ⇒ ISR register Bit 3: WOL_INT does not become "1"

② After executing ①, the reading result of the RXFCFG register is "0x1181", the reading result of the RXFSTS register is "0x001c"

 ⇒ RXFSTS register Bit 0: MAGIC_RCVD does not become "1"

③ In WIP_INT is not "1", but after setting the RXFCFG register WOL_OUT_CLEAR → "1"

Read result of RXFCFG register is "0x1181", reading result of RXFSTS register is "0x0000"

Also,

They had confirmed the register of 0x0136~0x0138. 

 0x0136 : 0x2202

 0x0137 : 0x4433

 0x0138 : 0x6655

 (MAC: 02:22:33:44:55:66)

As you asked before,

>Are you configuring INT/PWDN pin to be interrupt output? This pin is Power Down Input pin by default. This can be changed via bit 7 of register 0x1E.

(customer answer)

They changed the bit 7 of register 0x001E. But INT/PWDN is still high. (It does not changed.)

We still don't understand why the register(status) does not changed.

What should we check next?  

Best Regards,

Koji Hamamoto

  • Hi Hamamoto-san,

    1. Can you write 0x81 to register RXFCFG (0x134) and see if the WOL interrupt is triggered?

    2. How do you send the magic packet into the device? From Ethernet test equipment or from a link partner? I just want to make sure the link partner is correctly sending the magic packets. Is there any way you can confirm it?

    Regards,

    Hung Nguyen

  • Hi Hung-san,

    Thank you for your prompt reply.

    I will ask about your question to our customer and let you know.

    Best Regards,

    Koji Hamamoto

  • Hi Hung-san,

    I got new information for your question.

    1. Can you write 0x81 to register RXFCFG (0x134) and see if the WOL interrupt is triggered?

    >> They wrote 0x81 to register RXFCFG(0x134) but WOL was high and read data of RXFSTX was 0x001c.

    2. How do you send the magic packet into the device? From Ethernet test equipment or from a link partner? I just want to make sure the link partner is correctly sending the magic packets. Is there any way you can confirm it?

    >> They just connected PC to the board and tested. So,the magic packet should be sent from PC.
    >> They don't have any confirmation. We already asked again that. We appreciate your patience as it might take some time.

    Best Regards,
    Koji Hamamoto
  • Hi Hung-san,

    I am sorry for the delay in my reply.

    I got the data exported by "Wireshark" application from the customer.

    Does this help for your question?

    WOL.zip

    Best Regards,

    Koji Hammoto

  • Hi Hamamoto-san,

    The file is password protected. If you don't mind sharing it in this forum, please provide it.

    Regards,

    Hung Nguyen
  • Hi Hung-san,

    I apologized I didn't tell you the password. But the pssword is the customer name.

    So that,I unziped and reziped without a password.

    Please refer the following file.

    WOL PCAPNG file.zip

    Best Regards,

    Koji Hamamoto

  • Hi Hamamoto-san,,

    The captured packet is not the magic packet. It looks like the packet they use is broadcast packet.

    Please refer to datasheet section 8.3.1.1 for more details. Basically, the magic packet should have 16 consecutive 6-byte DA in the payload.

    Regards,

    Hung Nguyen

  • Hi Hung-san,

    I appreciate your prompt reply.

    I will ask to the customer how they checked the magic packet on their configuration.

    Best Regards,
    Koji Hamamoto
  • Hi Hung-san,

    I got the answer from the customer regarding your question.

    They changed the packet sending soft to another soft then confirmed as bellow. Please see the following Wireshark data and the expected sent packet data.

    There are no [SecureOn Password] but it looks the expected the magic packet data.

    Magic packet.zip

    Could you check the above data?

    Also which is the broadcast data that you mentioned at the last post?(Which data you pointed on the last Wireshark data?)

    Best Regards.

    Koji Hamamoto

  • Hi Hung-san,

    Could you follow this?

    Best Regards,
    Koji Hamamoto
  • Hi Hamamoto-san,

    As I mentioned in earlier post, your packet does not have magic packet structure. It should have 16 consecutive DAs in the payload after synchronization stream (6 bytes of FF).

    The packet you provided has DA = FF FF FF FF FF FF which is a broadcast packet.

    I see you have 16 repetitive 02 22 33 44 55 66 in the payload. If that is the intended DA, it has to be in the DA field of the packet, which is the 1st 6 bytes. Your magic packet should be something like this:

    02 22 33 44 55 66 ===> DA
    34 3d c4 9a 03 67
    08 00 45 00 00 82
    59 52 00 00 80 11
    00 00 c0 a8 01 0a
    c0 a8 01 ff f9 63
    00 01 00 6e d4 8a
    ff ff ff ff ff ff ===> sync
    02 22 33 44 55 66 ===> DA
    02 22 33 44 55 66 ===> DA
    02 22 33 44 55 66 ===> DA
    02 22 33 44 55 66 ===> DA
    02 22 33 44 55 66 ===> DA
    02 22 33 44 55 66 ===> DA
    02 22 33 44 55 66 ===> DA
    02 22 33 44 55 66 ===> DA
    02 22 33 44 55 66 ===> DA
    02 22 33 44 55 66 ===> DA
    02 22 33 44 55 66 ===> DA
    02 22 33 44 55 66 ===> DA
    02 22 33 44 55 66 ===> DA
    02 22 33 44 55 66 ===> DA
    02 22 33 44 55 66 ===> DA
    02 22 33 44 55 66 ===> DA

    Hope it helps.

    Regards,

    Hung Nguyen