DP83867CR: Not Detecting Magic Packet

Hi Ray,

Here is an FAQ that goes through the setup procedure for DP83867:
https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1163723/faq-dp83867ir-how-to-setup-and-test-wol-feature-of-dp83867?tisearch=e2e-sitesearch&keymatch=dp83867%20magic#

Please try the procedure and share your feedback.

Regards,
Rahul

Hi Rahul,

Good Day. Please see below the response of our customer to your reply. Thank you very much.

We looked at the solution proposed in the documentation you shared with us. We tried implementing the same register configuration as explained in the presentation, but there were some discrepancies that I would like to question.

First, the document explains other sources rather than just the magic packet for wol functionality (unicast, broadcast), but I was wondering whether it is necessary to activate also those, we only want the magic packet for wol. I think we just need the 0x481 value for register 0x134, I only wanted to be sure.

Secondly, if we enable the interrupt to trigger also for unicast or broadcast packets, with this configuration we can see the pin going low and remaining at this level until register 0x13 is read, such behavior is not what we were expecting, given the values for register 0x0134.

Also, I wanted to add that we are monitoring the packet structure with the WireShark utility sent to the DUT and monitoring the registers of the device in real-time, to check for example if on register 0x0135 registering the status of the packet received sets the value related to the magic packet.

So far we were not able to detect any sign of the device addressing the delivery of a magic packet, but as explained previously we were able to trigger the interrupt by different means, even though the result was not the pulse we expected.

Hi Ray,

Did you try assigning the interrupt to a GPIO and test it ? or are you checking this on a software end?

Thanks,
Rahul

Hi Rahul,

Good Day. They are testing the device using the INT pin to signal the wol pulse, with the registers set as explained in the previous messages. They can also sample the GPIO_0 and GPIO_1 if needed setting register 0x0172 to the appropriate value, but they need the INT pin to work as an interrupt on their design.

Hi Ray,

I will have to check with the team or try to replicate this issue in the lab setup. I am currently occupied with some priority interrupts.

I can debug this in the lab and provide you an update, please allow 4-5 working days for me to get to lab and debug this issue.

Thanks,
Rahul

Hi Rahul,

Good Day. I would like to follow up on the customer's query. Thank you very much.

Hi Ray,

Thank you for following up.

I am still waiting on a response from a colleague (currently OoO), should be back by Thursday. Will update you as soon as I hear from him.

Thanks,
Rahul

Hi Rahul,

Good Day. Is there any update on the customer's query? Please advise. Thank you very much.

Hello Ray,

I will be re-directing this thread to other colleagues as Rahul (supporting the thread) is out of office. But I went through the thread myself and noticed a few things that I want to confirm with the customer : 

Ray Vincent Aranzaso said:

Secondly, if we enable the interrupt to trigger also for unicast or broadcast packets, with this configuration we can see the pin going low and remaining at this level until register 0x13 is read, such behavior is not what we were expecting, given the values for register 0x0134.

So customer is seeing interrupt going low on magic packets. Correct?

Ray Vincent Aranzaso said:

So far we were not able to detect any sign of the device addressing the delivery of a magic packet, but as explained previously we were able to trigger the interrupt by different means, even though the result was not the pulse we expected.

Expectation that interrupt pin will have pulse is not correct. Functionality of interrrupt pin is for it to go low when required interrupt is detected and stay low untill the interrupt register is read by host processor. If pulse is desired, then directing the WoL to GPIO (as described in the document shared earlier) is the way to go.

Sorry if I lost something in interpretation of this thread but I hope the above reply is of some help.

--

Regards,

Vikram

Hi Vikram,

Good Day. Please see the latest response of our customer to your reply. Thank you very much.

Your Comment: So the customer is seeing interrupts going low on magic packets. Correct?

Actually, we see the magic packet from OS, but the INT pin does not go low at all (no impulse, no level) when we send the magic packet and check from the UEFI shell. We are checking register 0x135 bit 0 to know if the magic packet is detected anyway, but it never goes to 1.

Your Comment: The expectation that the interrupts pin will have a pulse is not correct. The functionality of the interrupt pin is for it to go low when the required interrupt is detected and stay low until the interrupt register is read by the host processor. If the pulse is desired, then directing the WoL to GPIO (as described in the document shared earlier) is the way to go.

Ok, now this part is more clear, thank you for the explanation. So, if we want impulse mode, it is not supported by the INT pin, and we have to use GPIO. Is that right?

Best Regards,

Ray Vincent

Hi Ray,

I can handle this while Rahul is OoO. Please allow me a day to get up to speed on this discussion.

Sincerely,

Gerome

Hi Ray,

On 12/20/22 you had stated that INT pin does not go low at all when magic packet is seen, while on 12/2/22 you state that you see INT pin go low in similar condition. How can this be?

Sincerely,

Gerome

Hi Gerome,

Good Day.

A similar condition is when we tried to see if the interrupt was able to go low, by enabling unicast and broadcast to interrupt. Of course, this is not a working condition, because when the cable is plugged in, the interrupt is immediately set to low. So, the functionality of the interrupt itself is OK, but it does not work with the magic packet because it is not detected. Of course, we want to interrupt to be set low when the magic packet is received, and not every time the cable is plugged in.

Best Regards,

Ray Vincent

Hi Ray,

In working condition, this interrupt can be risen due to multiple different reasons. Can you read interrupt register to see which is driving this? This will also clear the interrupt register and pin such that when magic packet is sent, only then can interrupt be driven by it if configured correctly.

Sincerely,

Gerome

Please note: TI will be closed 12/26, 12/27. Responses will be delayed until opening on 12/28.

Hi Gerome,

Good Day. Please see the latest response of our customer to your reply. Thank you very much.

We have the possibility of reading the 0x0013 register which stores the various interrupt status at runtime, but when only the magic packet option is enabled for WOL, bit 3 WOL_INT does not change its value. We clear the 0x0013 status by reading it at boot just in case, but it should not matter, since the interrupt pin remains high.

When also unicast or broadcast packets options are enabled for WOL (register 0x0134, bit 4 or 2), then bit 3 of register 0x0013 toggles, and interrupt is asserted, but in our specific case only bit 0 of register 0x0134 is set high, bit 4, bit 2 and bit 1 are all zeros.

During our tests, we did not see the interrupt being asserted except for the aforementioned cases, the other interrupt causes never interfered with the interrupt signal. Anyways, we always performed the tests after clearing the 0x0013 register, since we thought other causes might influence the results.

We also monitored register 0x0135 which detects the arrival of different packet types, bit 0 MAGIC_RCVD was never asserted when sending magic packets to the ethernet controller.

Maybe it would be useful for us to have a register map table with all the needed values to configure and a test magic packet structure to be sure that we are using the right settings. I found some examples online, but nothing was too useful or actually working for us.

Best Regards,

Ray Vincent

Hi Ray,

I will need to check this with the team. Please note that there may be a delay due to the Holiday season. 

Sincerely,

Gerome