Consequences of unstable external oscillator and switching to internal oscillator?

[KVIZK.1]

We have been experiencing dropped bytes during UART communications and have determined the root cause to be an unstable external oscillator.

The external oscillator placement does not follow the recommended guidelines and is resulting in the PLL desynchronization, which in turns leads to a 10-20us transient on the main clock. If this transient occurs while we are reading or writing UART data we will get 'NF' and 'FE' noise/framing errors on the UART bus register and subsequently lose information.

This image shows our bad oscillator placement/design

 

There are several solutions we found to this problem:

1. Switch to the internal oscillator. Accuracy is 1% over temperature range of the STM32F429 MCU. This is in comparison to 30-50ppm of the ATS08ASM-1E external oscillator. This fixes the issue and appears to be working without comm issues.
2. Implement retry logic that allows the bad packets to be re-requested. This works for the most part but it seems that the retry logic will sometimes still fail and we end up never getting the UART data when we are operating from the external oscillator.
3. Removing the load capacitors from the external oscillator prevents the clock instability. This is a strange solution but also appears to work.

Our preferred solution is to switch over to the internal oscillator and use the retry logic. So now two questions:

1. Switching to the internal oscillator or removing the load caps from the external oscillator appear to be similar in effectiveness of solving the hardware issue. Is there any reason why we should choose one over the other? I figure removing the load caps makes the crystal less precise which is the same issue as using the internal oscillator?
2. What other functions should we be concerned with other than UART communications when trying to evaluate a change to the clock architecture?

For reference we are running our MCU at 168 MHz and are communicating UART @ 2 megabaud. The only other thing the board does is run a touchscreen.

Also if anyone has tips on external oscillator design please include since that will be helpful because this board will be redesigned in the near future.

Thanks!

[Peter BENSCH]

The most important document for a successful oscillator design is the AN2867. There are also some PCB layout recommendations and hints in section 7.2, which may help with troubleshooting.

First of all: it seems to me that you have used a normal GND plane for the load capacitances. In such a case, it is not surprising that removing the capacitors will alleviate the problem somewhat for the time being.

Important is indeed the complete decoupling of the crystal and the capacitors incl. (!) the GND connections, as shown in fig. 14 of AN2867.

Cornerstones:

1. use an own GND area under crystal and capacitors, which is only connected to the closest GND pin of the STM32
2. add a separate GND "wall" around these components on the crystal/capacitor side and connect this "wall" to the independent GND area of (1), also it must not be connected to the large area other GND
3. make the crystal connections to the MCU as short as possible

Good luck!

Regards

/Peter

[Uwe Bonnes]

Your design does not look optimal, but sensible. With a normal crystal and about the right load capacitance, the design should work. Are you sure there is no other major disturbance going on, e.g. external EMC, switching of haevy load, unstable supply. Look at those issues too.

[LCE]

Interesting about the decoupled GND, is the STM's crystal input stage THAT sensitive?

I have been designing with all kinds of frequencies for all kinds of MCUs for years, always using connections from the crystal caps to the GND plane(s), never had any trouble with that.

With connections as short as possible and no high frequencies on the signals close to the crystal - MCU connections.

For the design above:

• what kind of signals are directly besides the crystal tracks?
• have you checked the capacitors (we recently had 100 nF instead of 100 pF), and if the crystal is okay?
• what about firmware: HSE and GPIO settings?

[KVIZK.1]

Thanks for the tips. I agree that the grounding likely has something to do with this problem.

[KVIZK.1]

• Next to the xtal are the traces for the FMC_A# RAM bus. There is also an LED backlight driver but I have confirmed that turning it off has no effect.
• The caps are the correct values of 18pF and this is calculated correctly for the manufacturers recommendation of load capacitance. I have experimented with using smaller and larger values and it does not seem to help.
• Clock settings

RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;

RCC_OscInitStruct.HSEState = RCC_HSE_ON;

RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;

RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;

RCC_OscInitStruct.PLL.PLLM = 8;  // 1MHz output

RCC_OscInitStruct.PLL.PLLN = 336; //360; // 336MHz

RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2; // 168MHz SYSCLK

RCC_OscInitStruct.PLL.PLLQ = 7;  // 48MHz

[KVIZK.1]

There's a can of worms behind this question. I spent many days trying to figure out why these clocks are unstable and have come up with no other explanation. For reference we have an identical board to this one where the crystal is in a much better position

These boards rarely show the issue, but still occasionally have the clock transient, which does lead me to think there is something else going on with these boards.

Power supply is stable during transient. External EMI is unlikely because these boards have the issue even when set on a bench away from other equipment. Not sure if the FMC_A# RAM traces nearby could cause something since they are practically touching the xtal....

We have given up on the external xtal for now and are switching to the internal until we can get the time to redesign the board. We are just trying to be sure that we don't run into any unexpected problems by using a clock that is less accurate.

[Peter BENSCH]

If the blue tracks running diagonally across the crystal transmit switching edges and there is no GND or VDD layer between these tracks and the crystal, you will not get a stable clock at the LSE. The LSE input is extremely high impedance and sensitive, so it makes a lot of sense to follow the above recommendations, plus route switching signals in a wide arc around the LSE.

Regards

/Peter