DP83867IR: WoL erratic operation

Hi, 

We are currently looking into your issue and I hope to get back to you by the end of business tomorrow. 

Kind Regards,

Joe

All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and is subject to TI’s Important Notice (http://www.ti.com/corp/docs/legal/important-notice.shtml)

Hi Joe,

Did you have a chance to look into this issue? With the starting position for the WoL pattern to 42 from the frame start, the setup that we have is still running without any erratic WoL for more than 8 days.

Looking forward for your answer,

regards,

Miki

Hi Miki,

We are still trying to reproduce this behavior in lab to better understand the root cause. What is your specific configuration setup?

Are you configuring any registers to anything other than default values and what are your strap settings?

Kind Regards,

Joe

All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and is subject to TI’s Important Notice (www.ti.com/.../important-notice.shtml)

Hi Miki,

We are still trying to reproduce this behavior in lab to better understand the root cause. What is your specific configuration setup.

Are you configuring any registers to anything other than default values? What are your strap settings?

Kind Regards,

Joe

All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and is subject to TI’s Important Notice (www.ti.com/.../important-notice.shtml)

Hi Joe,

Our card has a 1000 Ethernet port with default configurations, except for the WoL, for which I presented the setup. The strapping is as follows:

from the data sheet:

To speed up the erratic WoL there should be frequent communications with the card . Without communications with the card, it took us about a week to get a erratic WoL with the pattern positioned at 62.

thank you.

Regards,

Miki

Hi Miki,

Thank you for the information you provided. I will try to reproduce what you are experiencing and update you.

Kind Regards,

Joe

All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and is subject to TI’s Important Notice (www.ti.com/.../important-notice.shtml)

Hi Miki,

I was re-reading your initial post and I would like to double check something.

For the register writes you provided, you have 2 register writes to 0x015B which makes me think this was a typo. Please see the image I inserted below to see what I think you meant. 

Can you also kindly confirm that the Bytes 8 to 59 are all 0's?

Kind Regards,

Joe

All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and is subject to TI’s Important Notice (www.ti.com/.../important-notice.shtml)

Hi Joe,

You are right, this is a typo. Sorry. The script used to set the PHY registers is correct and sets Ok all the 64 byte of the pattern. The masking bits are all zero.

thank you.

best regards,

Miki

Hi Joe,

One more clarification: the WoL pattern is not all zero, it is a specific  pattern. We verified that , when sending the proper pattern, at the correct position related to the frame start, it does generate the WoL signal. We also checked that a change of even one bit , in the sent pattern , does not activate the WoL.

regards,

Miki

Hi Miki,

Thank you for the additional information and clarification. I will hopefully get back to you by the end of business Thursday (6/10).

Kind Regards,

Joe

All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and is subject to TI’s Important Notice (www.ti.com/.../important-notice.shtml)

Hi Miki,

I am still in the process of replicating your results and I hope to get back to you by the end of business Thursday (6/17).

Apologies for the delay and thank you for your patience.

Kind Regards,

Joe

All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and is subject to TI’s Important Notice (www.ti.com/.../important-notice.shtml)

Hi Miki,

I ran some initial testing and I am in contact with other team members to ensure I am properly replicating this link-down while using the pattern matching feature.

I will keep you updated and thank you for the patience.

Kind Regards,

Joe

All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and is subject to TI’s Important Notice (www.ti.com/.../important-notice.shtml)

Hi Joe,

Do you have any update?

thank you.

regards,

Miki

Hi Miki,

I have verified the WoL functionality with the pattern starting at byte 62. I have included the script I used when writing to the DP83867. For further verification, I captured the WoL pulse on the GPIO_0 Pin after configuring register 0x0172. I also configured register 0x0134 to 0x0082, configuring the WOL_OUT_MODE for pulse. 

// Title: DP83867 WoL Test
// Company: Texas Instruments
// Location: Santa Clara, CA
// Developer: Joe Vanacore
// Date: June 8, 2021
// Customer Debug for WoL
// Texas Instruments

begin

//delay 100
//0000 2100	// force 100Mbps, full-duplex
013C 475f	//Pattern Bytes 0 and 1
013d 0e0c	//Pattern Bytes 2 and 3
013e 4bfb	//Pattern Bytes 4 and 5
013f 641d	//Pattern Bytes 6 and 7
0140 0000	//
0141 0000	//
0142 0000	//
0143 0000	//
0144 0000	//
0145 0000	//
0146 0000	//
0147 0000	//
0148 0000	//
0149 0000	//
014a 0000	//
014b 0000	//
014c 0000	//
014d 0000	//
014e 0000	//
014f 0000	//
0150 0000	//
0151 0000	//
0152 0000	//
0153 0000	//
0154 0000	//
0155 0000	//
0156 0000	//
0157 0000	//
0158 0000	//
0159 0000	//
015a e649	//Pattern Bytes 60 and 61
015b fb54	//Pattern Bytes 60 and 61
015c 0000	//Byte Mask 0 to 15
015d 0000	//Byte Mask 16 to 31
015e 0000	//Byte Mask 32 to 47
015f 0000	//Byte Mask 48 to 63
0161 0000	//Pattern start point (62 decimal)
0172 0003	//Configures GPIO_0 pin for WoL Indication
0134 0082	//WoL on pattern enabled, level Indication, pulse mode

end

I then configured SmartBits with the following pattern for generation:

Please let me know if you need any further clarification and thank you for your patience.

Kind Regards,

Joe

All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and is subject to TI’s Important Notice (www.ti.com/.../important-notice.shtml)

Hi Joe,

The problem that we have is not related to the "normal" response of the PHY when the correct pattern is being send, but with erratic pulse WoL generation without receiving the preset pattern. 

Did you reproduce this behavior ?

thank you.

regards,

Miki

Hi Miki,

I did not see this behavior when I tested this setup. I will continue to test this throughout the week to see if I can reproduce this behavior. I will provide my findings on Tuesday of next week. 

Kind Regards,

Joe

All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and is subject to TI’s Important Notice (www.ti.com/.../important-notice.shtml)

Hi Miki,

I have a couple of follow-ups:

1. Are you sending any packets when observing these WoL pulses or is the line silent?
   1. If you sending packets, are you sending random packets (not the specified magic packet)? Or are you sending packets similar to the magic packet?
2. Lastly, do you anticipate any of the packets sent to match the magic packet?

As of now, I have left the lab setup overnight while leaving the scope on "single" to see if a WoL pulse is generated after a long period of time. I am currently not sending packets on the line but I would like to confirm the setup with you.

Kind Regards,

Joe

All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and is subject to TI’s Important Notice (www.ti.com/.../important-notice.shtml)

Hi Joe,

When observing the WoL we were just communicating with the card via the PHY; we did not send any similar packets to the magic packet or to the set WoL packet. Actually we monitored the line using Wireshark and we are pretty sure that no WoL pattern reached the PHY prior to getting the erratic WoL detection. Please note that it may take some time till the erratic WoL happens ( sometimes it may take a week depending on the amount of communication traffic). 

Thank you.

regards,

Miki

Hi Miki,

I set up the WoL setup and smartbits is transmitting a predefined packet that does not match the WoL magic pattern.

I will let it run overnight with the scope in "single" capture mode and triggering at 1.7V to see if I get a WoL pulse. I will share my results tomorrow and we can discuss next steps.

Kind Regards,

Joe

All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and is subject to TI’s Important Notice (www.ti.com/.../important-notice.shtml)

Hi Miki,

I performed the test as I explained above and there was no WoL pulse overnight. The pattern that I was sending to the PHY was similar to the magic pattern except the data pattern Bytes were replaced with "FF".

Please see the screen capture below from this morning. (Scope settings on single capture and triggering at 1.7V)

I would suggest you ensure that there is no randomization in the data because when I used the random sequence function on smartbits, I did see WoL pulses. The less you byte mask in the magic packet (bytes that are "00"), the lower the probability that the sequence will match random data and send a WoL pulse. 

Kind Regards,

Joe

All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and is subject to TI’s Important Notice (www.ti.com/.../important-notice.shtml)

Hello Joe,

Since the PHY is exposed to all the LAN traffic, not necessary restricted to the one addressed to it, there is no way to guarantee that the data will not be random. therefore, the fact that you noticed WoL pulses means that you succeed to reproduce the problem that I encountered. 

The question is, did the random pattern that generated an WoL contain the expected WoL pattern? What we found is that even when it was not, we still received WoL pulses.

regards,

Miki

Hi Miki,

I was not able to reproduce your issue. I generated a sequence that I confirmed did not match the WoL magic packet. 

I want to reiterate the importance of having a very specific sequence so that it won't match any sequence from the PRBS generator. I ran some initial testing and saw pulses, however, the packet being used is not very specific and it is possible that the random sequences match. I would urge you to confirm that the random data does not contain the magic packet. Once I confirmed that the sequence I was generating did not contain this magic packet, I saw no false WoL pulses overnight.

If you can confirm that the sequence is never generated from your PRBS generator, then I would proceed with further testing.

For example in smartbits, you can transmit a custom packet or all 1's or all 0's. 

Kind Regards,

Joe

All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and is subject to TI’s Important Notice (www.ti.com/.../important-notice.shtml)

Hi Joe,

Please note that we are using the pattern option and not the magic packet. Secondly, I can assure you that we did not send the specific pattern in all the random WoL reported cases. When these undesired resets happened , the PHY was exposed to standard communications packets. We used a communication software that was periodically polling the card (on which the PHY was part of) asking for some OIDs values. We monitored the communications with the card using Wireshark and we checked that the specific pattern was not received accidently. It may take sometime ( even a week) until a random WoL is generated, but it always happen. Only when we changed the pattern starting point to 42 instead of 62 the problem disappeared.

Please advise.

thank you.

regards,

Miki

Hi Miki,

The last three bytes could be the same as some of the random bytes that you are sending since the starting point is 62.

Another sequence could match the last three bytes with differing 61 initial bytes.

For a weeks worth of data, it is possible that some sequences match.

Changing the pattern start to 42 makes sense because there is less masked data and this leads to higher system stability. The less you byte mask in the packet (bytes that are "00"), the lower the probability that the sequence will match random data and send a WoL pulse.

What made you decide on moving the pattern start to byte 42? Did you iterate and measure performance?

Kind Regards,

Joe

All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and is subject to TI’s Important Notice (www.ti.com/.../important-notice.shtml)

Hi Joe,

To my understanding the pattern starting point does not reduce the length of the pattern that is checked: there are always 64 bytes of data unless we chose to mask part of them, which in our application is not the case. Changing the starting point should only specify to the PHY where to start to look for the WoL pattern. Changing to 42 the starting point for the WoL sequence was based only on the fact that the TI examples provided worked that way, so I supposed that we should try this before giving up on this part. 

regards,

Miki

Hi Miki,

Based on our testing, we are not able to see this behavior. We have illustrated the PHY is behaving as defined. Can you capture the packets you are sending? This way we can try to better replicate your issue.