ETH_REF_CLK (PA1) noise / crosstalk on ADC1_IN0 (PA0)?

[######]

Hello,

Has anyone seen ADC noise generated by the 50 MHz RMII clock (PA1) affecting the measurement on ADC1_IN0 (PA0)? (approximately 100 codes in 4096).

If so does anyone had a fix to suppress it?

All other ADC channels used do not have the same level of noise (approximately 10 codes in 4096), and when ETH_REF_CLK is removed, the noise is the same as the other ADC channels.

Part STM32F437 LQFP100.

TIA.

[waclawek.jan]

With a 50MHz clock (with harmonics possibly reaching up to GHz), there's always a significant risk of crosstalk, whether capacitive, common-path (ground) or other; outside or inside the chip.

Questions to contemplate: What's the PA0 signal source's impedance? What's the physical layout of relevant signals and VDD(A)/VSS(A)? How is the ETH clock terminated?

JW

[######]

Thanks, the risk of crosstalk is what we have suspected.

The source impedance of PA0 is directly from a signal conditioning OpAmp output.

VDDA and VSS are in close proximity due to the layout of the package, so the RefClk trace has tried to be routed around and away from the ADC lines (each trace enters at opposite sides of the IC Pins).

VDDA VSSA and VREF have ferite bead and capacitor filtering on them, and the other ADC channels seem stable.

The ETH clock has a series resistor of 33 ohms at the PHY end, on reflection (no pun intended) perhaps this would be better at the Microcontroller end, closer to PA1.

Other solution possibly is to provide an external cap across the ADC input to reject the 50 MHz?

[waclawek.jan]

> Other solution possibly is to provide an external cap across the ADC input to reject the 50 MHz?

That's unlikely to provide lower impedance than the opamp and may bring its own issues. But you can always try it as a last ditch effort, with a 0603 or 0402 cap directly across the pins...

Maybe rerouting grounds with very strict separation of VSSA to VSS, arranging the closest VSS to be a dedicated return to the 50MHz clock etc. might help somewhat, but maybe not even that, if the crosstalk is inside the chip.

Using ADCs in such a heavily digital circuit as the 'F4 is is always a matter of tradeoffs, so maybe you want to consider moving that input to a different pin, use external ADC mux, etc.

JW

[######]

Thanks.

We've perhaps been a bit remiss in our prototyping, and should have checked this earlier...

We require 10 ADC channels, basically we did a lot of initial work testing to get the ADC channels working within desired spec through the PCB design looking at ground separation, experimenting with VREF and Supply filtering etc. 

Each of ADC1 and 2 have 16 channels, but the input pins are duplicated for both ADCs so no option for moving :( Also, the ethernet pins clash with some of the channels, so using 6 pin RMII ethernet interface leaves us at the maximum of 10 inputs left. This seemed suitable "on paper".

Now we have introduced ethernet on one of the PCB variants, one of the ADC pins is now not performing as well as it used to, or when compared with the others.

Seems like we'll have to look at a possible design change / use an external ADC. 

It seems odd that one of the highest frequency external clocks (50 MHz RefClk) is routed directly inbetween the ADC interface, with no pin swap option?

Thanks for your help.

[LCE]

> It seems odd that one of the highest frequency external clocks (50 MHz RefClk)

> is routed directly inbetween the ADC interface, with no pin swap option?

Having routed a H733 in LQFP-144 recently, it seems that many STM32 pin options / placements do not make so much sense...

Sure, this is due to the many options for alternate functions for the GPIOs, but concerning signal quality, I wish they had a few more dedicated pins or thought a little bit more about possible PCB layout issues when designing the chip / package pinout.