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. > > especially with 1 Mbit/s it's better to use the crystal oscillator clock.
Thanks for the hint! Good to know. >> 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. Here, 1 Mbit/s works. These are the timing values calculates by the automatic algorithm: [frog...@hardanger:berlios-can-utils (master)]$ ./can-calc-bit-timing flexcan -c 66500000 Bit timing parameters for flexcan with 66.500000 MHz ref clock nominal real Bitrt nom real SampP Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP Bitrate Error SampP SampP Error CAN_CTRL 1000000 90 3 4 3 1 6 1007575 0.8% 75.0% 72.7% 3.1% 0x051a0002 800000 180 2 2 2 1 12 791666 1.0% 80.0% 71.4% 10.8% 0x0b090001 500000 105 7 8 3 1 7 500000 0.0% 87.5% 84.2% 3.8% 0x063a0006 250000 285 5 6 2 1 19 250000 0.0% 87.5% 85.7% 2.1% 0x12290004 125000 571 5 6 2 1 38 125000 0.0% 87.5% 85.7% 2.1% 0x25290004 100000 526 7 8 3 1 35 100000 0.0% 87.5% 84.2% 3.8% 0x223a0006 50000 1428 5 6 2 1 95 50000 0.0% 87.5% 85.7% 2.1% 0x5e290004 20000 2631 7 8 3 1 175 20000 0.0% 87.5% 84.2% 3.8% 0xae3a0006 10000 ***bitrate not possible*** >> Patches are, as >> always, welcome. > > Once I know how to do it, than let's see. > 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.) Use printk to check if setting this bit stalls the system. Add a printk to the interrupt handler, too. You have to load "priv->can.clock.freq" with the correct value, in order to let the algorithm calculate sane register values. If using the oscillator clock maybe you're not allowed to turn on the bus clock. Does the oscillator clock require some explicit enabling? Cheers, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions | Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917-5555 | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
