DP83867IR: Wake on Magic Packet

Hi Jan,

There are several places you write to reserved bits or read only register. ex. (write 0x82 to reg. 0x1e) (0000 0000 01010 0010)

While bit 4 is reserved, and bit 1 is read-only. 

What is the reason for this? 

Are you able to WoL but only not Wo-Magic Packet? 

write 0x0081 to reg. 0x134 -> again bit 6 is reserved

Otherwise, the writes you perform seem correct to me.

Are you making sure you are using the correct datasheet?

Best,

Alon 

Hi Alan,

register 0x1E returns 0x02 when read, so I write zeros to the reserved bits since zero is the default and a one to RO bit  1. Same with reg. 0x134: bit 6 reads zero, so writing a 0 should be ok.

The datasheet is doc ID SNLS484F, dated february 2015, revised December 2019.

WOL works for all (unicast, broadcast, pattern) except magic packet. So, I'm sure the packet arrives since the Phy wakes if I configure it to trigger on specific bytes of the magic packet.

There's actually a difference between the magic packets I sent and the description of the magic packet on page 15 in the data sheet: the DS states that the magic packet has to have a 4 bytes CRC at the end. This description seems to come directly from the AMD document about the Magic Packet Technology (https://www.amd.com/system/files/TechDocs/20213.pdf). However, none of the tools I tried does generate this CRC, but nevertheless these tools work for other network cards. So, does the TI-Phy actually check this 4 byte CRC? 

I found a similar issue in this forum (https://e2e.ti.com/support/interface-group/interface/f/interface-forum/863908/dp83867cr-magic-packets-over-udp) and the solution there was to adjust PATTERN_START_POINT in reg. 0x161 to 0x30 which is the start of the 16 x MAC block in an USP encapsulated Magic Packet. However, to my understanding this register is only effective for  pattern match, not for magic packet detection. Is this correct?

Thanks&Regards

Jan

Hi Jan,

This is a workaround that should work, so go ahead and try it. We have raised the issue internally and well update if we have come up with an answer.

Best,

Alon 

Hi Alan,

already tried it, with no luck. Meanwhile I found out that the Phy does react on magic packets that are sent unicast instead of broadcast, so below packet with the destination address set to the station address  does wake under Windows:

0000 88 88 88 88 88 88 00 5d 73 19 de 7d 08 00 45 00 .......]s..}..E.
0010 00 82 e5 1e 00 00 7f 11 e3 83 ac 1e 8c 3a ac 1e .............:..
0020 8e 51 f0 ca 00 09 00 6e 01 dc ff ff ff ff ff ff .Q.....n........
0030 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 ................
0040 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 ................
0050 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 ................
0060 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 ................
0070 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 ................
0080 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 ................

The datasheet says:

"A Magic Packet frame must also meet the basic requirements for the LAN technology chosen, such as SOURCE
ADDRESS, DESTINATION ADDRESS (which may be the receiving station’s IEEE address or a BROADCAST
address), and CRC."

So I would expect magic packets send via broadcasts should work as they do with other phys?

Thanks & Regards

Jan

Hi Jan,

I appreciate the effort you are putting in, on my side I have reached out to a previous engineer who had more experience with this topic, as well as trying to learn the difference between broadcast and unicast magic packets.

From the excerpt you wrote in your last reply, I would assume Magic Packets should work via broadcast as you mentioned, it is good to know unicast magic packets work at the very least, but I am pushing to understand why broadcast is not successful on your end.

I will update as soon as I have more pertinent information to assist with.

Best,

Alon

Hi Jan,

I got in touch with someone who had previous experience with this. See E2E link below and let me know if it helps. 

https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1005750/dp83867ir-wol-erratic-operation

I have also received a script for register writes that perhaps could be useful, however I am still trying to understand it myself. 

Please go through the thread I attached, and let me know if it helps, if not, we can keep digging in other directions. 

Best,

Alon

Hi Alan,

not sure whether this issue is really related. They seem to use WOL on pattern match and this did work for me too. It's just that Magic Packets send as a broadcast (i.e. destination address set to  ff ff ff ff ff ff) don't generate a wake event.

Thanks & Regards

Jan

Hi,

just confirm that below broadcast (UDP encapsuled) packet is detected as a Magic Packet and generates a wake event:

0000 ff ff ff ff ff ff 50 81 40 f6 55 b4 08 00 45 00
0010 00 82 8e c1 00 00 80 11 00 00 c0 a8 b2 4a c0 a8
0020 b2 ff ef 37 00 09 00 6e 29 36 ff ff ff ff ff ff
0030 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0040 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0050 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0060 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0070 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0080 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

RXFPMD1-3 has been set to FF-FF-FF-FF-FF-FF. So, magic packet detection works as expected, except that it insist that the packet destination address must match the address given in RXFPMD1-3. That's the reason why below packet (raw ethernet) wont wake with RXFPMD1-3 set to 02-22-33-44-55-66, just because the destination address (Offset 0000, 6 bytes) doesn't match:

0000 ff ff ff ff ff ff f0 b0 14 38 b4 00 08 42 ff ff
0010 ff ff ff ff 02 22 33 44 55 66 02 22 33 44 55 66
0020 02 22 33 44 55 66 02 22 33 44 55 66 02 22 33 44
0030 55 66 02 22 33 44 55 66 02 22 33 44 55 66 02 22
0040 33 44 55 66 02 22 33 44 55 66 02 22 33 44 55 66
0050 02 22 33 44 55 66 02 22 33 44 55 66 02 22 33 44
0060 55 66 02 22 33 44 55 66 02 22 33 44 55 66 02 22
0070 33 44 55 66

Thanks&Regards

Jan

Hi Jan,

Just wanted to update that we are still looking into this, sorry for the longer turnaround however this query is indeed very specific. 

Best,

Alon

Hi Jan,

Could you please try using the following script?

Best, 
Alon

// 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 0033	//Configures GPIO_0 pin for WoL Indication
0134 0082	//WoL on pattern enabled, level Indication, pulse mode

end

Hi Alon,

sorry for the late response, I was on vacation  last week. For which packet should this configuration generate a wake event?  To my understanding, it will wake on packets where destination address is 5F:47:0c:0e:fb:4b, source address[0:1] = 1d:64, byte 60/61 = 49 e6 and byte 62/63 = 54 fb. Anyway, it didn't solve the problem. I wonder if you can reproduce the issue, do you have a hardware setup available?

Thanks&Regards

Jan

Hi Jan,

Okay thank you for trying. I have scheduled a meeting this coming Monday in the lab to try to recreate this. I will update. 

Best, 

Alon

Hi  Alon,

as discussed in the meeting, I routed the WOL signal to GPIO_1 (Reg 0x172 = 0x36, reg 0x134 = 0x1xx for level mode), but it shows the same behaviour: depending on configuration, signal is asserted for BCAST, UCAST, Pattern and unicast Magic Packets, but not for broadcasted Magic Packages.

Best Regards

Jan

Hi Alon,

any news on this issue, where you able to reproduce it in the Lab?

Best Regards

Jan

Hi Jan,

Yes, we have been in the lab, and we have indeed reproduced it. 

I have been waiting to align with Marion as she mentioned she wanted to set up another meeting. 

Currently it seems we will have to find a workaround unfortunately. Lets wait for Marion to setup a meeting?

Best,

Alon 

Hi Alon,

sounds good to me.

Best Regards

Jan