CAN Bus - Internal Oscillator
Every time I needed CAN, I had just put external crystal and didn't think about it after that. It worked fine.
I am wondering however whether the precisions of MCU internal oscillator is sufficient for up to 1Mbit/s and could I perhaps prove that on paper.
Internal Clock Specification
PLL Specification
The desired frequency at the PLL's output should be 48 MHz.
I've read the above-given data that the internal clock before going to the PLL could be anywhere between 7.848 and 8.184 MHz. I would ignore the PLL's jitter because it's in the ps range and it shouldn't matter much.
Firstly, am I correct in assuming that the PLL's output should then be anywhere between 47.088 and 49.104 MHz?
CAN Peripheral inside of the MCU is being connected directly to the 48MHz clocked bus and derives the output baud rate based on the value of the PRESCALER register.
If we assume a perfect prescaler then the clock supplying the CAN should be in the range of 981kHz to 1023kHz. Let's say that we want to cover max. frequency of 1MBit/s on the bus, which is 1000ns(in other words, the minimum time between 2 consecutive bits). Due to the error of the internal MCU clock, my period should be anywhere between 977ns and 1019ns which given the eye diagram of the CAN that I've seen shouldn't be a problem.
Is my logic right? Basically every resource I've found online claims "You have CAN! Better by external crystal!"
The calculation above actually has quite a decent margin of error if valid.
What's the catch? Is everyone being paranoid, have I missed something or the manufacturing process of the MCU is not that reliable so I would end up having 70% of devices working and 30% not for a "mysterious" reason :)
3 answers
You are making this too complicated. The only thing that matters is the percentage mismatch between any two clocks on a CAN bus.
You seem to imply that you are willing to guarantee the -10 °C to +85 °C temperature range, so the oscillator will be within -1.9% to +2.3%. Any two devices could therefore be off by 4.2% from each other.
The question then becomes whether CAN works with 4.2% clock mismatch between devices. To answer that, you look at the CAN spec to see how clock mismatch is handled.
Various things happen within each bit time on a CAN bus. This is handled by transmitters and receivers breaking each bit into multiple time quanta. Usually for robust implementations, there are 8 to 20 time quanta per bit. You can use less for specialized implementations, especially if you know that only your specific devices will be on the bus. In theory the upper limit is much higher, but most hardware can't be configured for more than 20.
The first quanta in a bit is the sync segment. If the bit transition occurs outside this segment, then the bit is either shortened or lengthened by the synchronization jump width. This is almost always set to 1.
If you allow arbitrary nodes to connect to the bus, then you should assume they have as many as 20 time quanta per bit, and can't adjust by more than 1 time quanta per bit.
The above implies up to 5% clock mismatch can be tolerated, but it's not that simple. What if successive bits are the same value? Then there isn't a transition to measure the start of new bits with. CAN deals with this by using bit stuffing. A bit of the opposite polarity is inserted whenever the previous 5 bits were the same polarity. This means a receiver might only see an edge, and thereby be able to adjust itself to the bit phase, every 5 bits. What sounded like a generous 5% mismatch budget now becomes just 1%.
There are some other things going on, so I'd not want to push it right to the edge with 1% clock mismatches. If you control all the nodes on your CAN bus, you can have them tolerate more clock mismatch with careful time quanta and synchronization jump width configuration. However, in the general case, you want to stay below 1%. That means each node should be better than 0.5%.
In practice, this generally rules out internal RC oscillators, and pretty much requires a ceramic resonator at least. Crystals are even more accurate, and pretty much any crystal will do accuracy-wise.
So to answer your question, no, don't use the internal oscillator that you show, at least not in the general case. Fortunately, ceramic resonators are cheap and readily available.
0 comment threads
CAN is asynchronous and, if you receive a string of consecutive zeros, the UART mechanism that turns raw CAN data into "a byte" might have to wait a great deal longer than 1 bit of data before it can re-sync.
If data is coming 101010101010 then that's great but, if data is 010000000010 then you have to freewheel across all those zeros and still be able to reliably detect the next 1 without over-counting the number of steady bits you have received in the interim period.
By the way, 1 Mbps is a maximum frequency of 500 kHz because there are two symbol slots in one cycle.
Check out What are the most common causes of CAN bus communication errors?
As stated there, CAN requires a clock accuracy of 1.58% or your CAN node is non-compliant. I would recommend to use <1% however, which usually means external quartz. Some MCUs have good enough internal RC oscillators, your does not. You must use a crystal oscillator/ceramic resonator for CAN if sticking with this MCU.
0 comment threads
0 comment threads