STMH723 and LAN8742Ai PHY

[sada1400]

Hi,

I am working on a new product. For this I use the STM32H723 µC and the LAN8742Ai PHY from Microchip.

Our schematics looks like this:

We have a 25 MHz crystal connected to the STM32H723 (HSE). The MCO is configured to HSE. The crystal matches the clock requirements of the LAN8742Ai. The LAN8742Ai has a PLL that generates 50 MHz. This frequency is used as the reference clock for RMII communication.

Now I have the following problem. When we run the product in a climatic chamber, sometimes the RMII communication does not work. The TCP/IP connection is broken, because messages sent from the STM32H723 to the PHY are not recognized by the PHY.

So my question is, waht is the frequency for MCO? Is this constelation generally allowed? Where can I make improvements. We used this PHY because it is the same one used on the NUCLEO-H723.

The PHY can be used for industrial applications down to -40 °C. It is not the PHY for consumer applications

 

Best regards,

sada1400

[TDK]

Your architecture should be working fine.

> When we run the product in a climatic chamber

What does this entail exactly? Are you just lowering the temperature? At what point does it fail specifically?

Verifying that MCO remains stable over the temperature range should be doable. This would absolve the possibility of the STM32 of sending a bad clock.

You could always look into improving shielding in general. That and reducing trace length are probably the lowest hanging fruit. Depending on your chamber, there could be a large compressor or other equipment nearby causing electrical interference.

[sada1400]

Hi TDK, 

thank you for your reply.

>> What does this entail exactly? Are you just lowering the temperature? At what point does it fail specifically?

Yes, I lower the temperature to -25°C. The first errors start at -16°C. As the temperature is lowered further and further, the error rate increases. 1 out of 100 messages is lost.

>> Verifying that MCO remains stable over the temperature range should be doable. This would absolve the possibility of the STM32 of sending a bad clock.

I will check this today.

>> You could always look into improving shielding in general. That and reducing trace length are probably the lowest hanging fruit. Depending on your chamber, there could be a large compressor or other equipment nearby causing electrical interference.

It is possible to reproduce the error on my desk with a cold spray ("Cold 75"). So I don't think EMV is a problem, but I will check the schematics again.

 

Thank you very much for the ideas. I'll get back to you when I find something.

 

[LCE]

... and check your crystal! It doesn't help if everything is able to run over the industrial temperature range, but your crystal is >= x ppm off (check PHY requirements for the clock, measure MCO at failing temperature)

[sada1400]

Hi LCE,

thank you for your reply! I will check this today :)

[sada1400]

I have checked the crystal. It is within the specification. I don't see any changes when the device cools down. To be sure, I replaced the crystal and tried other types. I have replaced the capacitor and so on. No improvements.

My next consideration was the supply voltage. But here, too, everything looks good. It is really very difficult to find out where the problem is coming from.

The next step is to check the shielding.

[sada1400]

A short feedback.

We have found the error. Although the quartz looked good on the oscilloscope, it was due to it. We have replaced it with a more stable oscillator. Now it runs without any problems. Apparently it was so close to the limit that sometimes it just wouldn't work.

We are now trying to get the crystal back into the working range.

Many thanks for your help!

[sada1400]

We have tried other things with the quartz and have come to another discovery. We activated FMC to access an external SRAM. The GPIO speed was set to HIGH. Since we are accessing the SRAM cyclically, we noticed that the crystal was catching interference every x ms. By changing the GPIO speed to medium, the firmware can now communicate with the same crystal without interference. Packets are no longer lost at -25 °C. The device has now been running for 4 days without any faults.

So we have to go back to the hardware layout... Thanks again for your help.

[LCE]

Thanks for coming back with more info!