DP83867IS: Causes of communication errors

Hi Ishiwata,

Thank you for submitting your query, I will gladly assist with this. To be sure I'm understanding the issue correctly, would you be able to confirm a few items for me?

IoT router → DP83867IS → STB (Set top box)

1. Is the DP83867 part of the IoT router and is it connected to the STB via an ethernet cable?
   1. Essentially: IoT Router[DP83867] <-Ethernet Cable-> STB ?
2. Normally there is no communication issue and everything functions as expected, the problem only occurs when the STB reboots
   1. Does power cycling the Router resolve this issue?
3. What board is the pfe eth0 log from? 
   1. Is this system running Linux?
   2. Do you have access to the PHYs registers?
      1. phytool (if installed) can be used to read the PHY registers

Regards,

Alvaro

Hi Alvaro,

I appreciate your reply and support.

1. Is the DP83867 part of the IoT router and is it connected to the STB via an ethernet cable?
    a. Essentially: IoT Router[DP83867] <-Ethernet Cable-> STB ?
       -->Your understanding is correct.

2. Normally there is no communication issue and everything functions as expected, the problem only occurs when the STB reboots
    a. Does power cycling the Router resolve this issue?
        --->Your understanding is correct.The problem only occurs when the STB reboots.
               I will check with the customer for power cycling the Router resolve this issue.

3. What board is the pfe eth0 log from?
   a. Is this system running Linux?
   b. Do you have access to the PHYs registers?
       phytool (if installed) can be used to read the PHY registers
        --->I will check with the customer.

Best Regards,
Ishiwata

Hi Ishiwata,

Thank your for confirming and for checking with the customer.

Could you also check if this happens with different link partners?

1. If we connect the IoT device to a PC or any other ethernet device, and reboot the link partner, do we run into the same issue? 
2. If we connect the STB to a different link partner, and reboot the STB, do we run into the same issue?

Regards,

Alvaro

Hi Alvaro,

Thank you for your support.

I will confirm the additional information you provided with the customer.

I have confirmed with the customer your previous question and will answer it.

2. Normally there is no communication issue and everything functions as expected, the problem only occurs when the STB reboots
　a. Does power cycling the Router resolve this issue?
　　　　--> This issue will be resolved by power cycling the router.

3. What board is the pfe eth0 log from?
　　　　--> This is the log from the DRX side.

　a. Is this system running Linux?
　　　　--> Yes. I'm using Linux.

　b. Do you have access to the PHYs registers?
　　phytool (if installed) can be used to read the PHY registers
　　　　--> Only the ethtool command is possible.
　　　　　　Currently there is no way to directly check or set the register values.

Best Regards,
Ishiwata

Hi Ishiwata,

Thank you for confirming! Has the customer tried to use different link partners? Could you try the mii-tool that is discussed here in the following FAQ to access device registers?

https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1164499/faq-how-to-read-and-write-ethernet-phy-registers-using-a-linux-terminal?tisearch=e2e-sitesearch&keymatch=how%2520to%2520read%2520registers%2520on%2520a%2520linux%2520terminal#

Regards,

Alvaro

Hi Alvaro,

Thank you for your support.

The customer changed the link partner and confirmed.

1. If we connect the IoT device to a PC or any other ethernet device, and reboot the link partner, do we run into the same issue?
-->If you connect the IoT device to a PC or other Ethernet device and restart the STB, it will work normally.
　PC <--> DP83867IS <--> STB　This configuration is communicating correctly.

2. If we connect the STB to a different link partner, and reboot the STB, do we run into the same issue?
-->Communication is not possible.
　PC <--> DP83867IS <--> Other STB　Communication failure

I have an additional question.
Also, I have an additional question: when using 1000Base, is it possible that the Auto-Negotiation settings could be the cause?
If the Auto-Negotiation settings are incorrect, is it possible that both will be set to MASTER, or both to SLAVE, etc.?

Best Regards,
Ishiwata

Hi Shuji,

Thank you for confirming these results. To quickly answer your question, auto-negotiation should not be causing this issue. 

Shuji Ishiwata said:

PC <--> DP83867IS <--> STB

Shuji Ishiwata said:

PC <--> DP83867IS <--> Other STB　Communication failure

Forgive me but the block diagrams here have me confused, I thought that the DP83867IS was part of the IoT board? Could we re-clarify the customer's board? Which board is the customer designing, and where is our DP83867 on? Would you be able to provide the schematics and a high-level block diagram of the customer's system?

Regards,

Alvaro

Hi Alvaro,

Thanks for your answer.

I understand that auto-negotiation is not the cause.

You are right about the configuration. The IoT router probably has a built-in DP83867IS.

I was wrong.

I am checking with the customer about the correct block diagram, but I think it is probably something like this:

Best Regards,
Ishiwata

Hi Shuji,

Thank you for checking with the customer, the block diagram that you provided is currently what I am understanding.

To reconfirm everything thus far:

Case 1:

IoT <-Ethernet Cable-> STB

When the STB is rebooted, communication fails to recover.

Case 2:

IoT <-Ethernet Cable-> PC

If the PC is rebooted, do we see the same issue?

Case 3:

PC <-Ethernet Cable-> STB

If we reboot the STB box, do we see the same issue?

Regards,

Alvaro

Hi Alvaro,

Sorry for the late reply.
I have confirmed with the customer and will let you know the details.

Case 1
Communication is not possible.

Case 2
Communication is correct.

Case 3
Communication is not possible.

I have an additional question.
The customer would like to know how to check FLP.
Please tell me how to check FLP.

Best Regards,
Ishiwata

Hi Shuji,

Thank you for confirming the details, it seems like the problem only occurs when the STB box reboots, this doesn't seem to be an issue with the DP83867. I would suggest you contact the STB vendor for assistance.

If the customer wants to check the fast link pulses, they can use a differential probe and very carefully probe one of the four differential pair traces before the RJ-45 connector. If the customer has a board that can fan out the ethernet signals, that can be used as well. An example of such a board could be the Tektronix Ethernet Compliance Test Fixture .

Regards,

Alvaro

Hi Alvaro,

Thank you for your reply.

Sorry, Case 3 was incorrect.
Communication is not working properly in Case 3.

Also, I received the DP83867 status register from the customer when communication is successful and when communication is not successful.
Can I send it to you in a private message?

Best Regards,
Ishiwata

Hi Shuji,

Case 3 was between the PC and STB box correct? If this case is also not working after the STB box is rebooted, this leads me to believe that the problem lies with the STB box.

Feel free to share the DP83867 registers directly on the forum.

Regards,

Alvaro

Hi Alvaro,

Sorry, my answer is wrong about case 3.

Case 3 works fine.

Send status register in private message.

Best Regards,
Ishiwata

Hi Shuji,

Thank you for sending the register differences, for full clarity, would you be able to provide me a register dump in the following format? It will help me see the changes and provide better feedback. Register 0x0-0x1F should be sufficient, but if the customer wants to include Registers 0x2D, 0x32, 0x55 as well, it would provide more data. 

Please note that I will be out of office for Thanksgiving, Nov 28th - Dec 4th. Please expect a delay in response.

Regards,

Alvaro

Hi Alvaro,

I've sent you a status register in your private message.
Let me know if you notice anything.

I look forward to hearing from you.

Best Regards,
Ishiwata

Hi Alvaro,

I have an additional question.

I am looking for a measuring device such as a protocol analyzer to check the contents of auto-negotiation communication by FLP.

Does such a device exist? Please let me know if there is one. (Does it have 1000BASE FULL, etc.)

Best Regards,
Ishiwata

Hi Shuji,

Thank you for sending me the registers, please find my feedback in the attached excel file.

The change is Reg 0x17 is the one I'm most curious about.

DP83867IS Causes of communication errors.xlsx

Regards,

Alvaro

Hi Alvaro,

I am very grateful for your reply.

I have some questions about the information you provided, so please check the excel.

DP83867IS Causes of communication errors_20241209.xlsx
Best Regards,
Ishiwata

Hi Shuji,

Thank you for going through the excel table and adding your questions. You are correct, Reg 0x17 is read only. I will need to discuss this with the Design team, please allow me until the end of the week to get a response from them.

I want to re-iterate the problem we are seeing so that I may clearly discuss it with my team, please correct me if any details are missing or incorrect. 

• In the following set up, both devices (IoT and STB) are powered up and communicating normally.
• When the STB box is rebooted, communication fails to recover.
  • What exactly does a reboot mean for the STB device? Does a reboot mean power cycle for the STB device?
  • When experiencing the communication issue, what happens if the ethernet cable is unplugged and plugged in again?

Alvaro (Al-vuh-roe) Reyes said:

Case 1:

IoT <-Ethernet Cable-> STB

When the STB is rebooted, communication fails to recover.

Case 2:

IoT <-Ethernet Cable-> PC

If the PC is rebooted, do we see the same issue?

Case 3:

PC <-Ethernet Cable-> STB

If we reboot the STB box, do we see the same issue?

I also want to triple-confirm the outcome of these tests. Both Case 2 and Case 3 are okay and communication functions as expected? 

Regards,

Alvaro

Hi Alvaro,

Thanks for your reply.

What exactly does a reboot mean for the STB device? Does a reboot mean power cycle for the STB device?
--> This means power cycling the STB.

When experiencing the communication issue, what happens if the ethernet cable is unplugged and plugged in again?
--> It seems that if you unplug and plug the ethernet cable back in (1 to 3 times) it will communicate normally.

Best Regards,
Ishiwata

Hi Shuji,

Thank you for confirming, I will reply again before end of week.

Regards,

Alvaro

Hi Alvaro,

Thank you for your support.
I look forward to your reply.

Best Regards,
Ishiwata

Hi Shuji,

Our design team has looked at this query but have not given me a detailed response. I will keep pushing to get more information, apologies for the delay. Has there been any new updates from the customer side?

Regards,

Alvaro