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.