TCAN4550-Q1: About the External crystal oscillator: When applying CAN communication, i must use external crystal oscillator？

Hello qinlei,

Generally the TCAN4550-Q1 will need a dedicated clock source such as a crystal oscillator and it uses this both to run the digital core as well as for the MCAN controller to generate the CAN communication.  But it may be possible to use an output clock from the MCU, but this would depend on the quality of the clock coming from the MCU and whether it meets the timing requirements for reliable CAN communication. 

The ISO 11898-1:2015 standard defines the tolerance range for the oscillator frequencies and it depends on the length of the time quantum, the segments of the bit time, and the synchronization jump width you are using in your application.  There are 5 equations given in this document that will determine what the maximum frequency tolerance can be. Slower data rates have a larger clock tolerance than faster data rates, so it is difficult to say whether your MCU can generate a clock that meets your CAN communication requirements.

Regards,

Jonathan

Hello,Expert 

thank you for you reply,and  i have another question, If I plug in a crystal oscillator to the MCU, for an example ,it is 8Mhz, But if  can not  meet my CAN communication rate requirements, Do I need to replace it with a 16MHZ external crystal? Is it possible to double the frequency of the crystal oscillator through the PLL function of MCU? Will there be a difference between the two methods?

thank you

best reagrds 

Hello qinlei,

Typically a clock frequency of either 20MHz or 40MHz is used for CAN communication due to how the CAN bit timing is defined.  Each clock cycle from the external clock is equal to a "Minimum Time Quantum or Quanta (mtq)" which corresponds to the finest resolution of time that the device can use for anything due to it being equal to a single clock cycle.  Each CAN bit is made up of some integer number of Time Quanta's (tq) and therefore the frequency tolerance is important.

20MHz and 40MHz are common frequencies that result in integer ratios for most common CAN bit times.  8MHz and 16MHz are not a common, and therefore you will need to determine if you can achieve your desired bit rate.  In CAN FD applications that have bit rate switching, it is even more critical that all nodes on the CAN bus have the same bit timing configuration settings to prevent sampling errors.

It is possible to use a PLL to double the frequency, but this usually reduces the quality of the clock, so you would likely need to restrict the CAN bit rates so there is more tolerance for lower quality clocks.

One additional requirement the TCAN4550-Q1 has with using a clock frequency less than 20MHz, is that the max SPI Clock rate must be at least 2MHz less than the external clock rate to prevent SPI errors.  The TCAN4550-Q1 datasheet specifies a min supported clock frequency of 20MHz, and a max supported SPI clock rate of 18MHz.  It is possible to use a clock slower than 20MHz, but the max SPI clock rate must also be reduced as well.

Any watchdog or failsafe timers such as the SWE timer are also based on either a 20MHz or 40MHz clock frequency.  If you use a different clock frequency, these times would also have to be scaled according to the difference in clock frequencies.

You will need to determine whether your application and CAN bus can support using a 16MHz clock frequency, and then you will need to determine if the quality of this clock coming from the PLL will meet the clock tolerance requirements specified in the ISO 11898-1:2015 document.

Regards,

Jonathan

hello,Expert 

thank you for your explain,i got it, I think what you mean is that the frequency after applying PLL may not be an integer multiple of TQ, so it will introduce clock error,right？So whether PLL frequency division can meet the requirements of CAN communication still needs to be confirmed with TQ，right?

thank you

best regards  

Hi qinlei,

I'm sorry if I am not being clear, or understanding your fundamental question.  But there are a couple of different concerns.

The first concern is whether a 16MHz clock will generate the correct number of TQ for your desired bit rate and also be compatible with other devices on the CAN bus that are using TQ generated off of a different clock frequency such as 20MHz or 40MHz.  Because each data bit is made up of multiple TQ's, there can be communication errors if the TQs of the different devices are of different lengths and quantity.  It is recommended that all devices on a CAN bus use the same bit timing configuration and sample point which is set based on how many TQs are allocated before and after the sample point.  A difference in TQs can result in different sample points among the different devices and lead to communication errors.  If all the devices on your CAN bus will also use 16MHz as a clock frequency, then this is not a concern.  But if other devices will use a different clock frequency, then this is a possible concern.

The next concern is with the quality of the clock signal itself coming out of the PLL.  Because PLL's will try to track the input clock's phase, they will vary slightly in frequency and create a jitter or distortion of the signal.  Therefore, the length of time for a single TQ will vary slightly from other TQs depending on the PLL.  This is not a concern in the "long term" frequency because the PLL should lock to the fundamental 8MHz clock signal and produce a 16MHz clock output.  But in the "short term" the cycle-to-cycle variance or jitter will be passed onto the CAN timing.  If this variance is too large, the CAN bits can be sampled incorrectly, or be seen by other CAN nodes as incorrect which may lead to communication errors. 

The following paper discusses this topic in detail which is what is included in the ISO 11898-1:2015 standard for clock tolerance requirements.

Robustness of a CAN FD Bus System – About Oscillator Tolerance and Edge Deviations (Link)

Regards,

Jonathan

hello,Expert  

i think i can Understand the first one you said.

and about the PLL, i have more questions, Do you mean that using PLL for frequency multiplication or frequency division may cause waveform distortion? Do you have any relevant information for reference?

thank you

best regards 

Hi Qinlei,

Jonathan is out of the office this week. Are you able to wait until he gets back for his reply? If not, I can try to reassign this thread to someone else on the team to see if they can look at this.

-Bobby

hello, i  think I can wait for him, thank you 

Qinlei,

For tracking purposes, please allow us to be the last reply in the thread. Jonathan will be back next week.

Regards,

Eric Hackett 

Hi Qinlei,

qinlei said:

and about the PLL, i have more questions, Do you mean that using PLL for frequency multiplication or frequency division may cause waveform distortion? Do you have any relevant information for reference?

I'm talking about both of these issues.

The first possible issue is the distortion and slight frequency variation that comes from a Phase Locked Loop (PLL) when it tries to track the source clock waveform.  This comes from how a PLL will wander above and below the source signal's frequency and make adjustments in the phase of the output signal's waveform to try to maintain an output waveform that is "locked" in frequency to the source waveform.  This results in a small distortion or variance in frequency as the PLL makes the phase adjustments during it's tracking of the source signal and this is usually referred to as a form of Jitter and each individual clock cycle in the output signal can have a slightly different period with some cycles being larger or smaller than other clock cycles.  Because a CAN application will use these individual clock cycles as equal to a single Time Quanta (TQ), the CAN bit timing will also contain this jitter.  Therefore to avoid bit timing and sampling errors, this jitter must be small and within the specifications defined in ISO 11898-1:2015.

The second possible issue is with error introduced by additional multipliers and dividers and sometimes this comes in the form of a duty-cycle distortion and the output waveform is no longer a 50%-50% duty cycle between the high and low portions of the waveform.

The exact quality of the clock generated from your MCU's PLL will need to be measured to see how much cycle-to-cycle jitter and what the exact frequency it has to determine whether it will meet the clock tolerance requirements as defined in ISO 11898-1:2015.  These tolerance is dependent on the bit rate and timing settings, therefore lower bit rates will have a larger tolerance (or can work with a lower quality clock) as compared to a faster bit rate that requires a better quality clock to handle the shorter bit periods of the data.

Regards,

Jonathan