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]

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 

[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.

[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.

[ESawa.1]

Hey @NEdom.1,

i really appreciate your reply and all the suggestions from the people here in the chat. Thanks a lot. Yes you are right, the USART is definetly not the right choise. As the hardware has to stay, we have to workaround it somehow. Either with different baudrates or with additional CRC checking and retries. Interesstingly if the systems runs for some time the USART gets super stable. It really seems to be a startup thing. We are still investigating and I will share all results. 

Best regards,

Eric