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
How does ethernet work when disconnected and reconnected
Started by ●October 7, 2023
Reply by ●October 7, 20232023-10-07
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 > > KlausThe 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.
Reply by ●October 7, 20232023-10-07
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 > > Klausit it the 25MHz or the 50MHz that's the problem?
Reply by ●October 7, 20232023-10-07
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...
Reply by ●October 7, 20232023-10-07
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.
Reply by ●October 7, 20232023-10-07
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
Reply by ●October 7, 20232023-10-07
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 offYEs, 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.
Reply by ●October 8, 20232023-10-08
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.]
Reply by ●October 9, 20232023-10-09
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
Reply by ●October 10, 20232023-10-10
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 packetsIt 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