DP83822H: DP83822 send unwanted "next page" bit on the ethernet Auto-Negotiation Advertisement

Hi Jiri,

Is there a functional issue that this is affecting? Is communication working between MACs?

Sincerely,

Gerome

Yes, we have a compatibility issue. When autonegotiation is enabled, our device with the DP83822 is unable to establish a link. With some devices, it works fine, but with others, it does not.

For example, it is unable to connect to the Intel(R) Ethernet Connection (23) I219-LM on DELL laptops. It only works when autonegotiation is disabled.

Therefore, we are trying to find the root cause of the problem. The schematic follows the recommendations from the datasheet, and the measured signals look perfect compared to the datasheet.

We found only one deviation from the expected state: the "next page" bit.

Hello,

Jiri Dobry said:

With some devices, it works fine, but with others, it does not.

Is "it" referring to a device that isn't DP83822? Or are you saying that DP83822 is not able to connect to Intel PHY on Dell Laptop?

Sincerely,
Gerome

Hello,

The issue was caused by our software, which did not wait long enough for the auto-negotiation to complete and attempted to restart it prematurely. As a result, the DP83822 started transmitting auto-negotiation data via Fast Link Pulses (FLP) in an inconsistent state. It appears that the PHY's internal state machine continues running independently, and if it is reconnected to the link at an arbitrary point, it may send truncated or invalid advertisement data, making the situation worse.

I am attaching an image illustrating how the auto-negotiation data gets truncated when the PHY is reconnected mid-sequence.

Here is an example:
* Only the last 3 bits from auto-negotiation data were transmitted.


The first 12 bits of the next auto-negotiation frame are incomplete.

Now it works, but there are still two open questions:

1. Why does the DP83822 send "Next Page bit" = 1, when the configuration register is set to "0"?
2. Why can the DP83822 transmit invalid/incomplete auto-negotiation data?

Best regards,
Jiri

Hi Jiri,

I would focus less on the specifics of the auto-negotiation process, as the Ethernet communication is working. It could be that when the PHY is properly configured without getting restarted in-between auto-negotiation convergence, this behavior is not present, or is not related to the overall functionality of the communication.

Sincerely,

Gerome

Gerome, I appreciate your response, but I believe you are missing the core concern here.

In today's world, requirements for safety, security, compatibility, and reliability are critical. It is not enough for me to confirm that something "works" in my specific conditions—I need to ensure that it works consistently, under all operational conditions, now and in the future.

Whenever I observe a discrepancy between expected and actual behavior, I am obligated to assess whether this deviation could impact any of these key aspects of our product's functionality. Ignoring such discrepancies just because "it works" is not an acceptable approach in a professional engineering environment.

Sincerely,
Jiri

Hello,

If the PHY were not restarted abruptly, would this behavior still be present? Can you please provide a screenshot of the FLP for this codeword in this behavior? Is all codewords showing next page when in normal communication? The abrupt reset may be putting the PHY into an unknown state.

How is the PHY getting reset? Is it via HW pin or via register? How long is the reset asserted for if via pin? My expectation would be that communication ceases upon a reset in order for the PHY to properly reset.  

Sincerely,

Gerome