STM32H750I USART1 Baudrate differs under cold temperature

[ESawa.1]

Hello ST Forum,

We are using an STM32H750I in a current project. This STM communicates via the USART1 with another STM32H750V at a baud rate of 512kBaud. The clock of the STM32H7 runs via an 8MHz HSE (external quartz) at 480MHz. The clock of the USART1 is obtained from the PCLK2.

We have now noticed the following phenomenon. Every now and then we have problems with the UART transmission between the two processors when starting the system. We connected a logic analyzer and found that in these cases "framing errors" and sometimes incorrect characters are sent on the UART. This case occurs particularly when the system was very cold beforehand, for example the device had been standing outside for a while. To test this case, we sprayed the CPU with ice spray to provoke it and then started it. The incorrect transmissions are clearly visible.

Since the UART is supplied via the PLL and we classified the "cold" PLL as a potential source of error, I had the PLL1Q output to the MCO1 while we read the UART. The nominal frequency should be 16MHz here. You can see that the frequency of the MCO1 also fluctuates, especially in the "framing error" places. That would mean that the frequency of the PLL is fluctuating slightly. You can see on the right side of the image that the frequency of the MCO1 sometimes increases to 18MHz. This also explains the “framing errors”.

However, this phenomenon only occurs when the CPU is running at full load. If you switch off some of the processing, especially peripherals such as FPU other UARTs and so on, it is no longer as pronounced. Of course, cooling down with cold spray is not a normal use case, but as I said, it also sometimes occurs when the device has been outside at 5°C. So our question to you:

- Are you familiar with such behavior?

- Is it possible that because the CPU is running at full load, the temperature increase is too extreme and the PLL therefore adjusts too much?

Interestingly, the phenomenon does not occur at all if you use the HSI as the source for the USART1. Here, however, we are concerned that this may become too inaccurate over time. Or do you think this is a suitable workaround?

Brief additional information:

- If you cool down the 8MHz quartz in isolation, these errors do not occur. Really only if you choose the PLL as the source of the UART.

Best regards and thank you in advance,

Eric

[AScha.3]

Hi,

1. to check the internal clock on mco : try a DSO , to see what the clock doing. (LA is no good idea, because its sampling /compressing the signal, so you never know for sure.)

2. Try a PLL setting with DIVM1  2 and DIVN1 240 ; (giving same 480M , but PLL more in "middle" of its range.)

[ESawa.1]

Hey @AScha.3 ,

thanks a lot for your fast reply. I will directly check your suggestion and reply the result. 

Best regards,

Eric 

[Ozone]

Not that I'm too deep into hardware specifics of M7 cores here ...

But perhaps a link with SPI would have been a more stable approach. The bus concept if SPI is different (master / slave), but by default it provides its own clock line, and is thus much more tolerant in regard to frequency variations.
Just saying.

[ESawa.1]

Hi @AScha.3 ,

I tried your suggestion. This has no effect. The USART is still sensitive against temperature changes. But what seems to help a bit is reducing the speed of the clock source to the USART1. In the initial configuration this clock was set to PCLK2 with 120MHz. When I change it to PLL2Q and 10MHz it is way more stable. Still with ice-spray you can force the UART to fail on some characters but way less then with PCLK2 120MHz. This is super strange. Never experienced such a behaviour before. 

Best regards,

Eric

[ESawa.1]

Hey @Ozone,

you are right, in this situation a SPI would be more robust. But as the hardware is at it is we have to workaround this missing clock somehow :D. Thanks for your suggestion. 

Best regards,

Eric 

[AScha.3]

And did you check the MCO with a scope?

Because you see a very strange behaviour here and at first we need to find the root cause: 

The crystal, the pll, Vos setting , bus or ahb speed settings, UART itself (very unlikely, did you check the errata sheet for CPU you have? ) .

Next try running at a modified setting: other crystal, other pll setting, lower bus and main clock - depends, on what the MCO test shows: is the pll clock out of lock - or something else?

[ESawa.1]

Hey @AScha.3,

Our hardware guy is checking the MCO with a high bandwidth DSO today or tomorrow. I will repor the result here. 

Crystal: 

Seems not to be the root cause, as cooling it isolated down does not trigger the issue. 

The PLL: 

Until now this is the best candicate for the problem. As the problem changes a bit when we modify the prescalers. Also the problem disapperas completly when we source the USART directly from the HSI. No PLL in between. 

The USART itself:

As mentioned above, the problem disappears when the USART is sourced from the HSI, so the USART itself seems to be fine. 

Errata:

There is no, or we didnt found an entry about this behavior. 

I will activate the PLLRDY IRQs as next step to see if they trigger when we see the USART failing. After we have measured the PLL output on MCO we will output HSE on the MCO to compare if we can see a movement of the clock. 

[NEdom.1]

In my experience, the USART is only used for some low baud rate communications except that the MCU is very powerful with the TTL connections is short and in good condition.

If you can't change your hardware, try a rather lower baud rate and your application allows.

You could also use can bus or synchronous clock bus such as I2C or SPI if you are going to change your hardware to make the comm stable, or try to add flow control to USART. In anyway, you will spend more pins in cost to implement these.

[Ozone]

As suggested below already, perhaps lower baudrates would improve the issue.
Or at least lower baud rates for startup.

Perhaps it is a silicon issue. In general, it takes several minutes until electronics reach equilibrum temperature, drift issues most likely appear during startup. If it is not the quartz itself, perhaps the input threshold values, or the PLL.
I'm no hardware guy, to be honest.