Internal vs External clock source for CAN Bus in STM32 - Page 1
Forum section: electronics / projects

author: Red_Micro
author_rank: Regular Contributor
timestamp: July 16, 2021, 01:18:00 pm
content: Is it reliable to use the internal 16 MHz RC with PLL option (±1 %) for CAN bus communication at 250 kbps in STM32? Considering that the reference manual of the chip I'm using claims to have a clock recovery system (CRS) it may be worth it to get away without external clock. The RM says:QuoteMy application is not as critical as vehicles. It's a small network with few sensors and actuators.

author: thm_w
author_rank: Super Contributor
timestamp: July 16, 2021, 11:12:25 pm
content: There are some calculations here which have examples of 0.5 to 1.5% oscillator tolerance:https://www.nxp.com/docs/en/application-note/AN1798.pdfDo you absolutely need those pins for IO? Or can you leave a footprint for a crystal if you run into any issues?CRS might work, depending on how you set it up. I think you'd have a "master" device that the slaves sync their clock to, and start off at a low baud rate to ensure the CAN signal is received ok. But then you get into temperature drift, etc. hopefully the 1% is within the error budget given above.Quote

author: viperidae
author_rank: Frequent Contributor
timestamp: July 17, 2021, 12:12:49 am
content: My first result for "canbus timing error tolerance" was NXPs AN1798 which explains this subject, including calculating timing tolerance.Most controllers have automatic time sync to deal with these timing issues between nodes. Have a read of the data sheet and application notes for your specific MCU/controller

author: Red_Micro
author_rank: Regular Contributor
timestamp: July 17, 2021, 01:04:44 am
content: Quote from: thm_w on July 16, 2021, 11:12:25 pmI can perfectly leave a footprint for a crystal. I'm just trying to see how much I can reduce HW and cost.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 17, 2021, 09:45:14 am
content: +/- 1% clock tolerance is marginal for CAN bus. If the usage of RC oscillator is a must due to size or power reasons, at least try to calibrate it to perform better, what, maybe 0.5%?I vaguely remember reading an article about the CAN protocol having a poorly understood feature which makes it require more accurate clock than the standard says, but I'm sorry I can't find more details and didn't find that article anymore. It probably had something to do with the resynchronization jump mechanism not being able to work in all corner cases. In any case, it made sense and it made me always just use a crystal oscillator. You don't need the full performance of the crystal, but something better than the cheapest 1% internal RC, AFAIK.Testing "if it works" is unnecessary. It will work on your lab table anyway, I'm sure. But even on a hobby projects, it's awkward when it fails randomly when the full Moon's out and relative humidity happens to be at 42%. Reallytestingthe reliability of a marginal system is way more expensive and difficult than just designing with ample margins. So just place the crystals on the footprints.

author: Niklas
author_rank: Frequent Contributor
timestamp: July 17, 2021, 07:48:56 pm
content: Check the frequency stability over operating temperature for the internal oscillator. The 1% stated on the front page is typically only valid at room temperature. Some of the STM32L0 parts have horrible drift, which could cause problems even with USART if used with fixed baudrate.Also note that the frequency tolerance in the datasheet may not guaranteed by design, instead it could be taken from sampling of parts and it can change when a new silicon revision is released.