Hi

I have a problem with a Ethernet PHY that makes too much noise. We are digging into the problem, iterating on the very poor layout done, but the client is looking for a fix right now with now HW changes.

The problem comes from the RMII communication to the PHY. Seems a 25MHz clock is feeding the PHY (LAN8742), which then in turn creates a 50MHz clock feeding back to the STM32 MAC.

If I remove the clock, the problem is gone. Problem is a radiated emissions +100MHz, so quasipeak detection is used in final measurements.

So have been trying to slow it down, and other tricks but thought about this solution:

Initiate the PHY as normal and let the PHY/MAC get an IP address.

Then disconnect the PHY for let's say 500ms, by removing the 25MHz clock.
After 500ms, activate the clock again.

That would possibly reduce the emissions by 3-4dB due to the quasipeak detector.

But, can an ethernet connection work like this?

How does the line react, will it do preamble communication again, or will it just work again (some packets might be lost, but we can re-transmit those)?

I know from earlier measurements on an ethernet line that it is active all the time even though no data is send.

Cheers

Klaus

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

lørdag den 7. oktober 2023 kl. 13.06.09 UTC+2 skrev Klaus Kragelund:

Hi

I have a problem with a Ethernet PHY that makes too much noise. We are digging into the problem, iterating on the very poor layout done, but the client is looking for a fix right now with now HW changes.

The problem comes from the RMII communication to the PHY. Seems a 25MHz clock is feeding the PHY (LAN8742), which then in turn creates a 50MHz clock feeding back to the STM32 MAC.

If I remove the clock, the problem is gone. Problem is a radiated emissions +100MHz, so quasipeak detection is used in final measurements.

So have been trying to slow it down, and other tricks but thought about this solution:

Initiate the PHY as normal and let the PHY/MAC get an IP address.

Then disconnect the PHY for let's say 500ms, by removing the 25MHz clock. After 500ms, activate the clock again.

That would possibly reduce the emissions by 3-4dB due to the quasipeak detector.

But, can an ethernet connection work like this?

How does the line react, will it do preamble communication again, or will it just work again (some packets might be lost, but we can re-transmit those)?

I know from earlier measurements on an ethernet line that it is active all the time even though no data is send.

Cheers

Klaus

it it the 25MHz or the 50MHz that's the problem?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/7/2023 14:06, Klaus Kragelund wrote:

Hi

I have a problem with a Ethernet PHY that makes too much noise. We are digging into the problem, iterating on the very poor layout done, but the client is looking for a fix right now with now HW changes.

The problem comes from the RMII communication to the PHY. Seems a 25MHz clock is feeding the PHY (LAN8742), which then in turn creates a 50MHz clock feeding back to the STM32 MAC.

If I remove the clock, the problem is gone. Problem is a radiated emissions +100MHz, so quasipeak detection is used in final measurements.

So have been trying to slow it down, and other tricks but thought about this solution:

Initiate the PHY as normal and let the PHY/MAC get an IP address.

Then disconnect the PHY for let's say 500ms, by removing the 25MHz clock. After 500ms, activate the clock again.

That would possibly reduce the emissions by 3-4dB due to the quasipeak detector.

But, can an ethernet connection work like this?

How does the line react, will it do preamble communication again, or will it just work again (some packets might be lost, but we can re-transmit those)?

I know from earlier measurements on an ethernet line that it is active all the time even though no data is send.

Cheers

Klaus

The data clock is always active, at least the one for data out.
But why the RMII clock, is it not like the MII clock I am familiar
with? It is only used to set the PHY up. Thankfully have not had to
wrestle a non-working PHY recently, typically because of tqfp soldering
defects - and once because I was plugging a network cable which was
connected to nothing at the other edn, time and time again after
resoldering... But I am pretty sure the MII clock can safely be
stopped after configuring the PHY.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, 7 October 2023 at 13:37:39 UTC+2, Lasse Langwadt Christensen wrote:

lørdag den 7. oktober 2023 kl. 13.06.09 UTC+2 skrev Klaus Kragelund:

Hi

I have a problem with a Ethernet PHY that makes too much noise. We are digging into the problem, iterating on the very poor layout done, but the client is looking for a fix right now with now HW changes.

The problem comes from the RMII communication to the PHY. Seems a 25MHz clock is feeding the PHY (LAN8742), which then in turn creates a 50MHz clock feeding back to the STM32 MAC.

If I remove the clock, the problem is gone. Problem is a radiated emissions +100MHz, so quasipeak detection is used in final measurements.

So have been trying to slow it down, and other tricks but thought about this solution:

Initiate the PHY as normal and let the PHY/MAC get an IP address.

Then disconnect the PHY for let's say 500ms, by removing the 25MHz clock. After 500ms, activate the clock again.

That would possibly reduce the emissions by 3-4dB due to the quasipeak detector.

But, can an ethernet connection work like this?

How does the line react, will it do preamble communication again, or will it just work again (some packets might be lost, but we can re-transmit those)?

I know from earlier measurements on an ethernet line that it is active all the time even though no data is send.

Cheers

Klaus

it it the 25MHz or the 50MHz that's the problem?

It's a harmonic. I am working on the fix, for the next revision of the board. I was just wondering if we could use a SW fix for now...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/7/2023 4:06 AM, Klaus Kragelund wrote:

I have a problem with a Ethernet PHY that makes too much noise. We are digging into the problem, iterating on the very poor layout done, but the client is looking for a fix right now with now HW changes.

The problem comes from the RMII communication to the PHY. Seems a 25MHz
clock is feeding the PHY (LAN8742), which then in turn creates a 50MHz clock feeding back to the STM32 MAC.

If I remove the clock, the problem is gone. Problem is a radiated emissions +100MHz, so quasipeak detection is used in final measurements.

So have been trying to slow it down, and other tricks but thought about this solution:

Initiate the PHY as normal and let the PHY/MAC get an IP address.

If you are using static addresses, then you already HAVE the IP address.

So, presumably, you expect to issue a DHCP "discover" datagram, hoping
a DHCP server is present on the network segment.

Note that you don't have any guarantees as to how long it will take
the server to respond with an "offer". The NIC must remain operational
while that datagram is "arriving". If you have min and max times for
a window in which you are confident the server will reply, you can power
down the NIC once your discovery request is (completely) on the wire.

Once the offer arrives, you can power down the NIC for a "modest"
amount of time before powering up to issue your "request" datagram.

As above, you can power down until you EXPECT the acknowledge datagram
from the server. Or, if it could possibly arrive at any time, you'd
have to keep the NIC powered up while waiting for it.

Once you have successfully received the lease in the acknowledge datagram, you've got a spot in the address space -- for as long as the lease defines
(so, you may need to consider how the DHCPd is configured as that will determine how lazy you can be in USING your IP!

Note that you can "be impatient" and shutdown the NIC prematurely at
any point in this exchange. You could, conceivably, wait N time units
before giving up. Then, ASSUME that the server won't/can't reply in
LESS than N time units (big assumption) so, reissue your most recent
datagram, power down the NIC for N-- time units and then power up
hoping the server has replied in t >= N (and, possibly, < 2N).

Note that you can be unlucky in these assumptions...

Then disconnect the PHY for let's say 500ms, by removing the 25MHz clock. After 500ms, activate the clock again.

See above.

That would possibly reduce the emissions by 3-4dB due to the quasipeak detector.

But, can an ethernet connection work like this?

The connection can work but the protocol may give you complaints.
Especially if you are shutting off the i/f without regard to
what is happening on the wire.

And, as this inevitably alters throughput, any higher levels in the protocols that expect a particular level of performance may complain. E.g., if you
were expected to complete some transaction in a certain timeframe (or,
with a certain maximum latency), you'd have to carefully reevaluate those constraints.

[You'd also have to explore how a switch would handle the fact that
the destination port suddenly "disconnected" while a datagram was
queued -- or queuing -- for it.]

How does the line react, will it do preamble communication again, or will it just work again (some packets might be lost, but we can re-transmit those)?

I know from earlier measurements on an ethernet line that it is active all the time even though no data is send.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

lørdag den 7. oktober 2023 kl. 16.49.37 UTC+2 skrev Klaus Kragelund:

On Saturday, 7 October 2023 at 13:37:39 UTC+2, Lasse Langwadt Christensen wrote:

lørdag den 7. oktober 2023 kl. 13.06.09 UTC+2 skrev Klaus Kragelund:

Hi

I have a problem with a Ethernet PHY that makes too much noise. We are digging into the problem, iterating on the very poor layout done, but the client is looking for a fix right now with now HW changes.

The problem comes from the RMII communication to the PHY. Seems a 25MHz clock is feeding the PHY (LAN8742), which then in turn creates a 50MHz clock feeding back to the STM32 MAC.

If I remove the clock, the problem is gone. Problem is a radiated emissions +100MHz, so quasipeak detection is used in final measurements.

So have been trying to slow it down, and other tricks but thought about this solution:

Initiate the PHY as normal and let the PHY/MAC get an IP address.

Then disconnect the PHY for let's say 500ms, by removing the 25MHz clock.
After 500ms, activate the clock again.

That would possibly reduce the emissions by 3-4dB due to the quasipeak detector.

But, can an ethernet connection work like this?

How does the line react, will it do preamble communication again, or will it just work again (some packets might be lost, but we can re-transmit those)?

I know from earlier measurements on an ethernet line that it is active all the time even though no data is send.

Cheers

Klaus

it it the 25MHz or the 50MHz that's the problem?

It's a harmonic. I am working on the fix, for the next revision of the board. I was just wondering if we could use a SW fix for now...

but is it the 25MHz from the MAC or the 50MHz from the PHY that causes the problem? I believe the 50MHz can be turned off

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 07-10-2023 19:32, Lasse Langwadt Christensen wrote:

lørdag den 7. oktober 2023 kl. 16.49.37 UTC+2 skrev Klaus Kragelund:

On Saturday, 7 October 2023 at 13:37:39 UTC+2, Lasse Langwadt Christensen wrote:

lørdag den 7. oktober 2023 kl. 13.06.09 UTC+2 skrev Klaus Kragelund:

Hi

I have a problem with a Ethernet PHY that makes too much noise. We are digging into the problem, iterating on the very poor layout done, but the client is looking for a fix right now with now HW changes.

The problem comes from the RMII communication to the PHY. Seems a 25MHz clock is feeding the PHY (LAN8742), which then in turn creates a 50MHz clock feeding back to the STM32 MAC.

If I remove the clock, the problem is gone. Problem is a radiated emissions +100MHz, so quasipeak detection is used in final measurements.

So have been trying to slow it down, and other tricks but thought about this solution:

Initiate the PHY as normal and let the PHY/MAC get an IP address.

Then disconnect the PHY for let's say 500ms, by removing the 25MHz clock. >>>> After 500ms, activate the clock again.

That would possibly reduce the emissions by 3-4dB due to the quasipeak detector.

But, can an ethernet connection work like this?

How does the line react, will it do preamble communication again, or will it just work again (some packets might be lost, but we can re-transmit those)?

I know from earlier measurements on an ethernet line that it is active all the time even though no data is send.

Cheers

Klaus

it it the 25MHz or the 50MHz that's the problem?

It's a harmonic. I am working on the fix, for the next revision of the board. I was just wondering if we could use a SW fix for now...

but is it the 25MHz from the MAC or the 50MHz from the PHY that causes the problem? I believe the 50MHz can be turned off

YEs, you are right. Seems that the 50MHz clock out is just a feature,
not needed for operation of the device. I will check with the SW guys,
if they use that for anything, maybe they feed it back for a reason.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/7/2023 10:26 AM, Don Y wrote:

But, can an ethernet connection work like this?

The connection can work but the protocol may give you complaints.
Especially if you are shutting off the i/f without regard to
what is happening on the wire.

And, as this inevitably alters throughput, any higher levels in the protocols that expect a particular level of performance may complain.  E.g., if you were expected to complete some transaction in a certain timeframe (or,
with a certain maximum latency), you'd have to carefully reevaluate those constraints.

By way of example, I transferred a few TB onto a new NAS I had
assembled. When done, I checked the number of objects present
on the NAS vs. the original server -- identical. BUT, was
surprised that the total storage usage was a fair bit LESS
than the originals!

Looking at the logs, I noticed that the connection had
dropped -- many times (a bug in the Gbe NIC's driver on the
new NAS)! As the protocol kept partial transfers, each dropped
connection still produced AN object... just not a COMPLETE
object. (The Windows client that I was using as an intermediary
didn't throw any errors so it was only the NAS that knew something
had failed)

[You'd also have to explore how a switch would handle the fact that
the destination port suddenly "disconnected" while a datagram was
queued -- or queuing -- for it.]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 09-10-2023 01:45, Don Y wrote:

On 10/7/2023 10:26 AM, Don Y wrote:

But, can an ethernet connection work like this?

The connection can work but the protocol may give you complaints.
Especially if you are shutting off the i/f without regard to
what is happening on the wire.

And, as this inevitably alters throughput, any higher levels in the
protocols
that expect a particular level of performance may complain.  E.g., if you >> were expected to complete some transaction in a certain timeframe (or,
with a certain maximum latency), you'd have to carefully reevaluate those
constraints.

By way of example, I transferred a few TB onto a new NAS I had
assembled.  When done, I checked the number of objects present
on the NAS vs. the original server -- identical.  BUT, was
surprised that the total storage usage was a fair bit LESS
than the originals!

Looking at the logs, I noticed that the connection had
dropped -- many times (a bug in the Gbe NIC's driver on the
new NAS)!  As the protocol kept partial transfers, each dropped
connection still produced AN object... just not a COMPLETE
object.  (The Windows client that I was using as an intermediary
didn't throw any errors so it was only the NAS that knew something
had failed)

Sounds from your experiment that it might be possible to have some kind
of working connection, maybe with some added encapsulation to retransmit
missed packets

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, 9 October 2023 at 23:31:12 UTC+1, Klaus Vestergaard Kragelund wrote:

On 09-10-2023 01:45, Don Y wrote:

On 10/7/2023 10:26 AM, Don Y wrote:

But, can an ethernet connection work like this?

The connection can work but the protocol may give you complaints.
Especially if you are shutting off the i/f without regard to
what is happening on the wire.

And, as this inevitably alters throughput, any higher levels in the
protocols
that expect a particular level of performance may complain. E.g., if you >> were expected to complete some transaction in a certain timeframe (or,
with a certain maximum latency), you'd have to carefully reevaluate those >> constraints.

By way of example, I transferred a few TB onto a new NAS I had
assembled. When done, I checked the number of objects present
on the NAS vs. the original server -- identical. BUT, was
surprised that the total storage usage was a fair bit LESS
than the originals!

Looking at the logs, I noticed that the connection had
dropped -- many times (a bug in the Gbe NIC's driver on the
new NAS)! As the protocol kept partial transfers, each dropped
connection still produced AN object... just not a COMPLETE
object. (The Windows client that I was using as an intermediary
didn't throw any errors so it was only the NAS that knew something
had failed)

Sounds from your experiment that it might be possible to have some kind
of working connection, maybe with some added encapsulation to retransmit missed packets

It may be worth checking the quality of the patch cable that was used for EMC testing. I once had a test failure that was fixed simply by substituting
the patch cable (which was cat5e unshielded.).

John

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/9/2023 3:31 PM, Klaus Vestergaard Kragelund wrote:

On 09-10-2023 01:45, Don Y wrote:

On 10/7/2023 10:26 AM, Don Y wrote:

But, can an ethernet connection work like this?

The connection can work but the protocol may give you complaints.
Especially if you are shutting off the i/f without regard to
what is happening on the wire.

And, as this inevitably alters throughput, any higher levels in the protocols
that expect a particular level of performance may complain.  E.g., if you >>> were expected to complete some transaction in a certain timeframe (or,
with a certain maximum latency), you'd have to carefully reevaluate those >>> constraints.

By way of example, I transferred a few TB onto a new NAS I had
assembled.  When done, I checked the number of objects present
on the NAS vs. the original server -- identical.  BUT, was
surprised that the total storage usage was a fair bit LESS
than the originals!

Looking at the logs, I noticed that the connection had
dropped -- many times (a bug in the Gbe NIC's driver on the
new NAS)!  As the protocol kept partial transfers, each dropped
connection still produced AN object... just not a COMPLETE
object.  (The Windows client that I was using as an intermediary
didn't throw any errors so it was only the NAS that knew something
had failed)

Sounds from your experiment that it might be possible to have some kind of working connection, maybe with some added encapsulation to retransmit missed packets

A lot will depend on how much control you can exert over the other
hosts in the network -- and, the level of performance that you
will consider acceptable.

If you are "off" when some host initiates a transaction, then
you obviously won't "see" those packets (assuming the switch
discards them because "you" don't currently exist -- something
really worth checking!). So, you are then at the mercy of that
host's retransmission policy -- will it try to reinitiate
the transaction? Or, will it just give up? If it *does* make
another attempt, will it's retry algorithm's timing "fit"
into your "up" time? Or, will Murphy reign supreme?

Remember, not all protocols build on TCP.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)