CAN Bus Timing Question

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I'm trying to determine crystal timing accuracy requirements for a CAN
bus application.

One node on the bus (the master) will be using a CAN controller chip
separate from the processor, with an ideal crystal.

The other nodes on the bus (the slaves, up to 10 or so) will be using
the CAN controller built into the DSPs (TI TMS320F2812).  The optimum
crystal for the DSPs (29.4912 MHz) results in a CAN bit time with a
0.31% error.

Other information:  CAN bit-rate 500 Kbps, maximum cable length <= 60
meters.

I note that the latest Bosch CAN spec (1991!) talks about 0.5% timing
accuracy for rates above 125K, and I'm wondering if I'm risking
reliability problems by adding 0.31% on top of the normal crystal
tolerances.

There is nothing else on the DSP boards that is extremely dependent on
the exact frequency of the crystal.  We could go to 30.000 MHz, but
we're reluctant to do that because this is not a standard frequency in
fundamental mode and surface mount.  So there are lead times and
minimum order issues I'd prefer to avoid, unless I am risking a
significant increase in communication errors.

So far the prototype is communicating perfectly directly with a
CANalyzer, but they are the only two nodes on the bus and the cable
length is only a meter or so.

All opinions welcome.

Thanks,

--
Jack Klein
Home: http://JK-Technology.Com
We've slightly trimmed the long signature. Click to see the full one.
Re: CAN Bus Timing Question

Quoted text here. Click to load it

Unless those crystal tolerances are small enough that you don't exceed
the 0.5% in total, I'd say you are.

Quoted text here. Click to load it

Well, make it more challenging, then!  Use 50 meters of non-optimal
cable (say, 50 meters of salvaged 110 Volts power cable with some
silly connectors, piled up in loops close to a flourescent tube, CRT
or other nice generator of EMI), and see what happens.

The first thing you'll lose consistently is maximum cable length for
full-length messages (8 bytes of payload optimized to require a large
number of stuff bits), from the node with the faster clock to the one
with the slower, because the ACK bit sent by the recipient won't
arrive in time for the sender to receive it properly.

What's stopping you from using 29.something MHz on the master, too?
--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: CAN Bus Timing Question
On 17 Oct 2003 10:55:46 GMT, Hans-Bernhard Broeker

Quoted text here. Click to load it

Typical crystals are rated at 0.02%, so adding two of those to the
nominal mis-match yields 0.35%.  Of course I'm aware that this doesn't
include temperature variations.

Quoted text here. Click to load it

The master is using a stand-along controller, separate from the
processor, that only goes up to 25 MHz tops.

--
Jack Klein
Home: http://JK-Technology.Com
We've slightly trimmed the long signature. Click to see the full one.
Re: CAN Bus Timing Question
Quoted text here. Click to load it

Since AIUI CAN guarantees a bit transition after no more than 4 bits,
it seems that you're looking at a 1.24% additional cumulative timing
error before the nodes can resynch themselves.  If I'm analysing that
correctly it doesn't sound very bad to me.

What might be very interesting to try would be to lower the clock
frequency (perhaps using some type of programmable clock chip) until
you start to get failures in your worst-case setup.  That would give
you some clue as to your timing sensitivity.

Mike

Re: CAN Bus Timing Question

Quoted text here. Click to load it

It would work that way if CAN nodes were all resynching themselves on
transitions.  IIRC, by default they don't.  Esp. not at the higher
baud rates.

And that's before you start to worry about those parts of a CAN frame
that don't undergo bit stuffing.

--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: CAN Bus Timing Question
Quoted text here. Click to load it

I thought that was the whole point of bit stuffing, to provide
transitions and guaranteed intervals to resynch on.  I'm no expert in
CAN details, though, so I could very well be wrong.  In that case,
what *is* the point of bit stuffing?
Quoted text here. Click to load it

Are there any fields longer than 4 bits that don't bit-stuff?

Re: CAN Bus Timing Question
Quoted text here. Click to load it

To distinguish between 8 bit data and start/end flags.

Meindert



Re: CAN Bus Timing Question
 >
Quoted text here. Click to load it

Of course there are! The arbitration field for instance. If bit stuffing
would take place the whole identifier method would be useless.
 
Quoted text here. Click to load it

And by the way? Why 4 bit? The longest period without Re-Synchronisation
are 10 bit (5 dominant, 5 recessive), in case of Re-Synchronisation after
error frames it is even 13 consecutive bit of one polarization.

Regards,
Taso



Re: CAN Bus Timing Question
Quoted text here. Click to load it

Well, here's what my spec says (BOSCH 1991):
--------
BIT STREAM CODING
The frame segments START OF FRAME, ARBITRATION FIELD, CONTROL FIELD,
DATA FIELD and CRC SEQUENCE are coded by the method of bit stuffing.
Whenever
a transmitter detects five consecutive bits of identical value in the
bit stream to be transmitted it automatically inserts a complementary
bit in the actual transmitted bit stream.
The remaining bit fields of the DATA FRAME or REMOTE FRAME (CRC
DELIMITER,
ACK FIELD, and END OF FRAME) are of fixed form and not stuffed. The
ERROR
FRAME and the OVERLOAD FRAME are of fixed form as well and not coded
by the
method of bit stuffing.
--------

So the arbitration field is bit-stuffed according to this spec, and I
guess that implies that the controllers are smart enough to figure out
a stuff bit in the arbitration field and ignore it during on-the-fly
arbitration.  Rather surprising, actually!
Quoted text here. Click to load it

The '4' was because I remembered incorrectly -- it's 5 consecutive
bits.  And you're right about the 10 bit period (5 dominant, 5
recessive) as I now see in the spec that only R->D edges are required
to be used for resynch (makes sense).  As usual, a little CAN
experience did not an expert me make! ;-)

Mike

Re: CAN Bus Timing Question

Quoted text here. Click to load it

Yep, you're right. I know that part, but I still don't understand
how it can work. I'll give an example:

Transmitter 1: ID = 0x9

SOF|0|0|0|0|0|Stuff|0|0|1|0|0|1

Transmitter 2: ID = 0x24

SOF|0|0|0|0|0|  1  |0|0|1|0|0

After five consecutive bit the second transmitter sends a recessive
bit due to its defined ID. How is it possible that Transmitter2
assumes a sent stuff bit of Transmitter 1? As one can see, the
bit pattern is odd, i.e. the one ID-field would be one bit longer,
than the second one.

I don't know the stuff bit rule exactly, but imho it must define
that every bit after 5 bit of consecutive polarity is a stuff bit.
Otherwise arbitration cannot work out.
 
Quoted text here. Click to load it

I would really like to know how. Maybe someone can help?
  
Quoted text here. Click to load it

Ack.



Re: CAN Bus Timing Question

Quoted text here. Click to load it



You're forgetting that SOF is a zero, too, so this should actually read:

  SOF|0|0|0|0|Stuff(1)|0|0|0|1|0|0|1

Quoted text here. Click to load it


That's not what Transmitter 2 actually sends -- even setting aside the
SOF==0 issue.  TX2 has sent 5 consequtive zeroes, too, so _regardless_
of what it's next bit to be sent is, it _also_ sends a stuff bit.
I.e.  it'll send:

  SOF|0|0|0|0|Stuff(1)|0|1|0|0|1|0|0

In other words: since the need for bit stuffing is determined only by
the 4 bits sent _before_ the prospective stuff bit, not by the next
bit they're planning to send afterwords, all participants on the bus
have the same information about whether the next bit they'll send/see
is a stuff bit or not.

If there were no differences in the past 5 ID bits, i.e. they were the
same on all sending nodes, then the stuff bit, if any, will be the
same for all sending nodes, too, and as such not introduce any change.

--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: CAN Bus Timing Question
Quoted text here. Click to load it

You're right, of course -- so simple!  Thanks for clearing that up.

Mike

Re: CAN Bus Timing Question

Quoted text here. Click to load it

Yes, I forgot! Thanx.

Quoted text here. Click to load it

Acknowledged! Let's summarize this. The definition is:

Every bit after five consecutive bit of same polarity has to be interpretated
as stuff bit. Right?

Regards,
Taso


Re: CAN Bus Timing Question

Quoted text here. Click to load it

Right --- under the presumption that those five consequtive bits of
same polarity are all in a part of the CAN frame that does use bit
stuffing.
--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: CAN Bus Timing Question
Quoted text here. Click to load it


Just to clear up any residual confusion I may have caused: that bit
about CAN nodes not necessarily all doing resynchronization was bogus
--- they most definitely do.

The scheme is more complicated, really.  The actual sampling frequency
of a CAN line is considerably higher than the bus baud rate ---
between 8 and 25 times as large, per the CAN 2.0 spec.

The spec restricts signal edges to fall within the first sample
interval (called a "time quantum" or 'tq') of a CAN bit time or at
most a certain number of quanta (the SJW, for 'synchronization jump
width) after that.  If it ever falls outside that time frame, you get
synchronization error, and eventually the CAN node will go off-line.

In the end, you get two formulae for the oscillator tolerance (taken
here from a CAN textbook edited by Prof. Wolfhard Lawrenz):

df <= min(Phase_Seg1,Phase_Seg2)/(2 x (13 x BitTime - Phase_Seg2))

and

df <= SJW / (20 x BitTime).

For proper operation, both inequalities have to hold.

[The other issues have already been answered by others.]

--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: CAN Bus Timing Question

Quoted text here. Click to load it

First, I would suggest to use the same oscillator frequency for both
devices. 30 MHz and 29.something won't work! With 29.something it is
not possible to match 2 s = x*tq with x beeing an integer.

Quoted text here. Click to load it

Yes, you migh risk something but there are ways you can avoid these
problems. It is important that the minimal RJW in your system is

2*df <= RJWmin/10*tbit

df = oscillator tolerance
RJW = Re-Synchronization Jump Width
tbit = nominal bit-time (e.g. 2s at 500 kBaud)

According to the formula

(RJWmin/20*2000ns)*100% = 0,31%

=> RJWmin = 124 ns!

If you work at 30 MHz with a BRP of 4 you'll get according to this formula

tbit*fosc/BRP = BTL-cycles

For 500 kBaud

2s*30MHz/4 = 15 BTL-cycles

At 15 BTL-cycles one tq is 133,3 ns long, so programm your RJW in both
controllers to RJW = 1. That equals 133,3 ns. The number of nodes this
method works is -theoretically- infinite. It's all matter of oscillator
tolerances and RJW, but I recommend not to experiment with heteregone
frequencies like 29.something and 30 MHz! The frequencies variate at
0,5 MHz and you would need to do some RJW-tricks for getting the
system working properly.

Quoted text here. Click to load it

Try, this is a deterministic approach of configuring a CAN-network.

Regards,
Taso



Site Timeline