What are the basic settings you should check first when experiencing communication problems? - Three things to suspect first when it comes to in-vehicle Ethernet - | NEXTY Electronics, a trading company for electronic components and semiconductors

When evaluating or debugging Ethernet communications, it is not uncommon to encounter communication problems such as "link not up," "unstable communications," or "packets not flowing."

Even after completing physical checks of the wiring, POWER SUPPLIES, clock, etc., it is not uncommon for the cause to remain unidentified, leading to deep register and packet analysis.

However, in reality, in many cases the cause can be identified simply by checking the basic settings.
In this article, we will use in-vehicle Ethernet (100BASE-T1/1000BASE-T1) as an example to outline the basic configuration checks that should be checked first when communication problems occur.

Why is "checking basic settings" important?

When it comes to analyzing Ethernet communication problems,

Detailed register analysis
Checking auto-negotiation state transitions
Packet capture with Wireshark

We tend to think of detailed analyses such as:
However, these analyses are only valid if the correct assumptions are made.
Even if you proceed to detailed analysis when the preconditions are broken,

I can't get information
State is indeterminate
reach the wrong conclusion

This can easily lead to situations like this, and analysis takes time.
So what's important is that there are three minimum settings you should look at first.

Three basic settings to check first when communication is poor

If you experience communication problems, simply check the following three points:
Many basic defects can be found in a short time.

1. Communication speed setting (100BASE-T1/1000BASE-T1)

One of the most common causes is mismatched internet speeds.

Local side: 1000BASE-T1
Remote side: 100BASE-T1

In this state, communication will not be possible even if CABLES is physically connected.
In particular, in the evaluation environment, there are many OTHERS settings, and problems are likely to occur where the communication speeds of each device suddenly become different.

First,

What speed is your PHY configured to operate at?
What speed does the other party support?

It is important to clarify.

2. Master/Slave settings

In automotive Ethernet, the roles of Master and Slave must be determined when establishing a link.
If this setting is incorrect, the following will occur:

The speed conditions are correct but the link won't work
At first glance, the auto-negotiation process appears to be progressing.

Of particular note is the

Both are fixed as Master
One side is fixed, the other side is auto-negotiation setting

The settings are asymmetrical.

In case of poor communication,

Is the Master/Slave setting based on auto-negotiation?
If manually set and fixed, check if there are any conflicting roles.

It is necessary to check the following.

3. Auto-Negotiation Settings

The third setting is to enable or disable auto-negotiation.
Auto-negotiation is a convenient mechanism for automatically determining communication conditions, but it can cause problems if settings are mixed.

A typical example is:

Myself: Auto-negotiation enabled
Partner: Auto-negotiation disabled (fixed setting)

The important thing is,
Rather than whether auto-negotiation is enabled or disabled, the key point is whether the settings on both sides are consistent.

Although none of these cases link up, it is important to note that the changes in the MDIO register are clearly different for each case. Understanding these differences is the first step in actually analyzing the problem.

What will change if you just check these three things?

When communication is poor,

1. Communication speed

2. Master/Slave

3. Auto-negotiation Enable/Disable

By first checking these three points,

Eliminate basic configuration mistakes instantly
No need to go through unnecessary register analysis
The scope of the problem can be narrowed down at once

This has the following major advantages.

Only after I confirmed that all of this was correct,

Detailed analysis of auto-negotiation
Digging deeper into register values
Packet-level behavior check

You can proceed to the next step.

Auto-negotiation is "one of the first things to isolate"

Auto-negotiation is one of the important mechanisms in Ethernet communication.
If you are using this function, it is necessary to analyze its behavior in detail in order to verify its operation.
However, when analyzing initial communication problems, detailed analysis of auto-negotiation should not be performed from the beginning.
First of all, you should at least check that the auto-negotiation settings are set to Enable/Disable.

When you experience communication problems, it is important to first check that the following basic settings are correct.

Do the communication speeds match?
Are there any conflicts in the Master/Slave settings?
Is the auto-negotiation enabled/disabled setting correct?

If these prerequisites are not met correctly, even if you check the auto-negotiation results and behavior in detail, it will not help you isolate the root cause.
Only after ensuring that the basic configuration is in place can we move on to the "why did auto-negotiation fail" discussion.

Summary: The "order" is important in analyzing communication failures

In analyzing communication failures in automotive Ethernet,
The most important thing is not to jump straight into difficult analysis.

First,

communication speed
Master / Slave
Auto-Negotiation Settings

Just check these three basic settings:
Many basic communication problems can be discovered in a short time.

In addition, if necessary
By proceeding to detailed analysis of auto-negotiation and register analysis,
This enables efficient and reproducible failure analysis.