Hello, On 08/11/2010 04:45 PM, Heinz-Jürgen Oertel wrote: > Am Dienstag, 10. August 2010 15:23:30 schrieb Marc Kleine-Budde: >> Heinz-Jürgen Oertel wrote: >>> Hello, >>> can please someone confirm that the more stable crystal oscillator >>> frequency can be used to drive the FlexCAN module instead of the 66.5 MHz >>> PLL clock? >> >> According to the datasheet the CLK_SRC Bit of the CTRL reg selects the >> CAN engine clock. I don't know which clock is more stable. > > From the manual: > > 13 This bit selects the clock source to the CAN protocol interface > (CPI) to be either the peripheral clock (driven by CLK_SRC > the PLL) or the crystal oscillator clock. > The selected clock is the one fed to the prescaler to generate > the SCLK (SCLK). In order to guarantee reliable operation, > this bit must only be changed while the module is in disable > mode. See Section 24.4.8.4, "Protocol Timing," for more information. > 0 The CAN engine clock source is the oscillator clock (24.576 MHz) > 1 The CAN engine clock source is the bus clock (66.5 MHz) > > and in "24.4.8.4 Protocol Timing" > > The crystal oscillator clock must be selected > whenever a tight tolerance (up to 0.1%) is required in the CAN bus timing. > The crystal oscillator clock has better jitter performance > than PLL-generated clocks.
I found similar comments for the MSCAN in the MPC5200 manual. > especially with 1 Mbit/s it's better to use the crystal oscillator clock. > > >> However the mainline driver only supports the bus clock. > > and with this clock, if it is 66.5 MHz, one Mbit/s can not be reached. OK. Another problem might be that 66.5 MHz does not give *good* bit-timing parameters as confirmed by my can-calc-bit-timing: $ ./can-calc-bit-timing -c 66500000 flexcan Bit timing parameters for flexcan using 66500000Hz Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP SampP Error 1000000 90 4 3 3 1 6 72.7% 0.8% !! 800000 180 2 2 2 1 12 71.4% 1.0% 500000 105 8 7 3 1 7 84.2% 0.0% 250000 285 8 3 2 1 19 85.7% 0.0% 125000 571 8 3 2 1 38 85.7% 0.0% 100000 526 8 7 3 1 35 84.2% 0.0% 50000 1428 8 3 2 1 95 85.7% 0.0% 20000 2631 8 7 3 1 175 84.2% 0.0% It it's even worse with worse with 24.576MHz: $ ./can-calc-bit-timing -c 24576000 flexcan Bit timing parameters for flexcan using 24576000Hz Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP SampP Error 1000000 40 8 8 8 1 1 68.0% 1.7% !!!! 800000 122 5 2 2 1 3 80.0% 2.4% 500000 284 2 2 2 1 7 71.4% 0.3% 250000 569 2 2 2 1 14 71.4% 0.3% 125000 1139 2 2 2 1 28 71.4% 0.3% 100000 1424 2 2 2 1 35 71.4% 0.3% 50000 1668 7 2 2 1 41 83.3% 0.1% 20000 5004 5 2 2 1 123 80.0% 0.1% 10000 7690 8 2 2 1 189 84.6% 0.0% Marc, what's happened with your optimized version of can-calc-bit-timing? Does it find better values? >> Patches are, as >> always, welcome. > > Once I know how to do it, than let's see. It should be selectable via platform data. > For now it's really difficult to dive into such system internals. > It's difficult to read the hardware manual describing the clocks and even > more > difficult to find and _use_ the already available BSP functions and consider > all side effects. That is may problem. Only setting bit 13 in the clock > control register seems not to be the solution. Doing it, my system freezes > completely (kernel 2.6.32.) Just setting bit 13 is not enough. You also need to provide the proper CAN clock frequency. Nevertheless, real CAN hardware experts are *able* to analyze the CAN signals with an oscilloscope and find proper bit-timing parameters. me == software guy! Wolfgang. _______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
