Do I need an external crystal for RS485 or CAN on STM32H533RET6?

[MERSI]

Hi everyone,

I’m currently working with the STM32H533RET6 and I’m wondering whether an external crystal oscillator is required (or at least recommended) for reliable communication over RS485 and CAN.

From my understanding, even at the highest baud rates, the internal clock (HSI) should be accurate enough for both interfaces, since the STM32’s internal oscillator is fairly precise and stable.

So my questions are:

• Is the internal clock sufficient for high-speed RS485 and CAN communication?

• Under what conditions would it be better or necessary to use an external crystal (HSE)?

Thanks in advance for any insights or practical experience!

[mƎALLEm]

Hello,

It's recommended to use a crystal for CAN and I think it's not recommended for RS485..

Some of our customers are facing issues when using internal oscillators with CAN/FDCAN especially when the temperature is changing. 

[Andrew Neil]

---

@mƎALLEm wrote:

I think it's not recommended for RS485..

---

Really?

Surely, RS485 is just a transport - like RS232 ?

For any async serial (ie, UART-based) comms (whatever the transport) a crystal is recommended - especially at higher baud rates

https://community.st.com/t5/stm32-mcus-wireless/stm32wb55-lpuart-baud-rate-issue/m-p/845733/highlight/true#M26640

 

[mƎALLEm]

---

@Andrew Neil wrote:

---

---

Really?

Surely, RS485 is just a transport - like RS232 ?

 

---

I said "I think" ;) but I'm sure for CAN!

[Ozone]

Concerning the signal seuences and baudrates, RS485 is identical to RS232, the same tolerance restrictions apply.
RS485 is current-driven (current source) and thus allows multiple nodes, unlike RS232.

For both CAN and RS485 you might get away without a quartz a low speeds and a limited temperature range. Which basically means a lab setup.
However, both busses are intended for industrial and outdoor usage, which implies a wider temperature range and high baudrates. And in my experience you quickly run into trouble in such an environment without a proper clock accuracy.

[Andrew Neil]

Indeed.

Even in a lab setup, I've had a case where UART comms "worked" at 9600 but not at 115200 when running from an internal RC oscillator (not an STM32).

 

TBF, internal RC oscillators do often have calibration capabilities, so can be made to work quite well - the question is whether that effort is worth it... 

[Ozone]

> TBF, internal RC oscillators do often have calibration capabilities, so can be made to work quite well - the question is whether that effort is worth it... 

In practice, how you are going to do a calibration when the MCU is enclosed in a (usually black) casing in a outdoor machine at -10°C ?
Or, turning it on after standing in the blazing sun for a few hours ?