The CAN Protocol

Introduction

This is a brief introduction to the CAN protocol. We do not claim completeness; if you want to know everything you should to view the specification.

The CAN bus

The CAN bus is a broadcast type of bus. This means that all nodes can "hear" all transmissions. There is no way to send a message to just a specific node; all nodes will invariably pick up all traffic. The CAN hardware, however, provides local filtering so that each node may react only on the interesting messages.

The bus uses two different signaling states: dominant (logically 0) and recessive (logically 1). These correspond to certain electrical levels which depend on the physical layer used (there are several.) The modules are connected to the bus in a wired-and fashion: if just one node is driving the bus to the dominant state, then the whole bus is in that state regardless of the number of nodes transmitting a recessive state.

In order to eliminate the DC component on the bus, the CAN messages are bit-stuffed, that is, for every occurrence of five consecutive bits of the same level, the transmitter inserts an extra bit of the opposite level. The receiver removes these extra bits.

The CAN messages

CAN uses short messages - the maximum utility load is 94 bits. There is no explicit address in the messages; instead, the messages can be said to be contents-addressed, that is, their contents implicitly determines their address.

Message Types

There are four different message types (or "frames") on a CAN bus:

• the Data Frame,
• the Remote Frame,
• the Error Frame, and
• the Overload Frame.

The Data Frame

The Data Frame is the most common message type. It comprises the following important parts (a few details are omitted for the sake of brevity):

• the Arbitration Field, which determines the priority of the message when two or more nodes are contending for the bus. The contents of the Arbitration field, which is 11 or 29 bits long, is usually called the Identifier; however, there is no obligation that the Arbitration field really contains any kind of identifier!
• the Data Field, which contains zero to eight bytes of data.
• the CRC Field, which contains a 16-bit checksum calculated on most parts of the message. This checksum is used for error detection.
• an Acknowledgement Slot; any CAN controller that has been able to correctly receive the message sends an Acknowledgement bit at the end of each message. The transmitter checks for the presence of the Acknowledge bit and retransmits the message if no acknowledge was detected.

It is worth noting that the presence of an Acknowledgement Bit on the bus does not mean that any of the intended addressees has received the message, just that one node on the bus has received it correctly.

The Remote Frame

The Remote Frame is just like the Data Frame, with two important differences:

• it is explicitly marked as a Remote Frame (a certain control bit is used for this purpose), and
• there is no Data Field.

The intended purpose of the Remote Frame is to solicit the transmission of the corresponding Data Frame. If, say, node A transmits a Remote Frame with the Arbitration Field set to 234, then node B, if properly initialized, might respond with a Data Frame with the Arbitration Field also set to 234. This can be used to implement a type of request-response type of bus traffic management. In practice, however, the Remote Frame is little used. It is also worth noting that the CAN standard does not prescribe the behaviour outlined here. Most CAN controllers can be programmed either to automatically respond to a Remote Frame, or to notify the local CPU instead.

Sometimes it is claimed that the node responding to the Remote Frame is starting its transmission as soon as the identifier is recognized, thereby "filling up" the empty Remote Frame. This is not the case.

The Error Frame

Simply put, the Error Frame is a special message that violates the rules of CAN. It is transmitted when a node detects a fault and will cause all other nodes to detect a fault. The transmitter can then retransmit the message. There is an elaborate scheme of error counters that ensures that a node can't destroy the bus traffic by repeatedly transmitting Error Frames.

The Overload Frame

The Overload Frame is mentioned here just for completeness. It is very similar to the Error Frame and is transmitted by a node that becomes too busy. The Overload Frame is not used very often, as today's CAN controllers are clever enough not to use it.

CAN Physical Layer(s)

A physical layer defines the electrical levels and signaling scheme on the bus, the cable impedance and similar things.

There are a few different physical layers:

• ISO 11898 defines a two-wire balanced signaling scheme.
• Little-used ISO 11519 for lower speed applications defines another two-wire balanced signaling scheme for lower bus speeds.
• Several proprietary physical layers do exist.
• A modified type of RS485 has been used.

Most CAN transceiver chips are manufactured by Philips; alternative vendors include Siliconix and Unitrode.

A very common type is the 82C250 transceiver which implements the physical layer defined by ISO 11898.

The ISO 11898 prescribes that the cable impedance be nominally 120 Ohms; an impedance in the interval of [108..132] Ohms is permitted.

There are not many cables in the market today that fulfils this requirement. There is a good chance that the allowed impedance interval will be broadened in the future; see CANHUG's proposal.

The maximum speed of a CAN bus, according to the standard, is 1 Mbit/second. At this speed, a maximum cable length of about 40 metres (130 ft.) can be used. This is because the arbitration scheme requires that the wave front can propagate to the most remote node and back again before the bit is sampled. In other words, the cable length is restricted by the speed of light. A proposal to increase the speed of light has been considered but was turned down because of its inter-galactic consequences.

Other maximum cable lengths are (these values are approximate) -

• 100 metres (330 ft) at 500 kbp/s
• 200 metres (650 ft) at 250 kpb/s
• 500 metres (1600 ft) at 125 kbp/s
• 6 kilometres (20000 ft) at 10 kbit/s

Some CAN controllers will handle higher speeds than 1Mbit/s and may be considered for special applications.

CAN connectors

There is no standard at all. Usually, each Higher Layer Protocol (!) defines one or a few preferred connector types. Common types include

• 9-pole DSUB, proposed by CiA.
• 5-pole Mini-C and/or Micro-C, used by DeviceNet and SDS.
• 6-pole Deutch connector, proposed by CANHUG for mobile hydraulics.

Here are a few different connector layouts.

Standard vs. Extended CAN

Originally, the CAN standard defined the length of the Arbitration Field to eleven (11) bits. Customer demand forced an extension of the standard. The new format is often called Extended CAN and allows no less than twenty-nine (29) bits in the Arbitration Field. The standards are formally called -

• 2.0A, with 11-bit Arbitration Field only,
• 2.0B, extended version with the full 29-bit (or the old 11-bit, you can mix them) Arbitration Field. A 2.0B node can be active, i.e. it can transmit and receive extended frames, or passive, i.e. it will silently discard received extended frames.
• 1.x refers to the original specification and its revisions. 2.0A and 1.x are compatible.

New CAN controllers today are usually of the 2.0B type. A 1.x or 2.0A type controller will get very upset if it receives a message with 29 arbitration bits. A 2.0B passive type controller will tolerate them; a 2.0B active type controller can both transmit and receive them.

Controllers implementing 2.0B and 2.0A are compatible as long as the controllers implementing 2.0B refrain from sending extended frames!

Sometimes people advocate that standard CAN is "better" than Extended CAN because there are more overhead in the Extended CAN messages. This is not necessarily true. If you use the Arbitration Field for transmitting data, then Extended CAN may actually have a lower overhead than has Standard CAN.

Basic CAN vs. Full CAN

The terms "Basic CAN" and "Full CAN" originate from the childhood of CAN. Once upon a time there was the Intel 82526 CAN controller which provided a DPRAM-style interface to the programmer. Then come along Philips with the 82C200 which used a queue-oriented programming model. To distinguish between the two programming models, people for some reason termed the Intel way as "Full CAN" and the Philips way as "Basic CAN". Today, most CAN controllers allow for both programming models, so there is no reason to use the terms "Full CAN" and "Basic CAN" - in fact, these terms can cause confusion and should be avoided.

Of course, a "Full CAN" controller can communicate with a "Basic CAN" controller and vice versa. There are no compatibility problems.

Message Arbitration

The message arbitration (the process in which two or more CAN controllers agree on who is to use the bus) is of great importance for the really available bandwidth for data transmission. The message arbitration of the CAN protocol consists mainly of comparing bit for bit of the Arbitration Field.

Any CAN controller may start a transmission when it has detected an idle bus. This may result in two or more controllers starting a message (almost) at the same time. The conflict is resolved in the following way. The transmitting nodes monitor the bus while they are sending. If they detect a dominant level when they are sending a recessive level themselves, they will immediately quit the arbitration process and become receivers instead. The arbitration is performed over the whole Arbitration Field and when that field has been sent, exactly one transmitter is left on the bus. This node continues the transmission as if nothing had happened. No time is lost in the arbitration process.

An important condition for this bit-wise arbitration to succeed is that no two nodes may transmit the same Arbitration Field. There is one exception to this rule: if the message contains no data, then any node may transmit that message.

SInce the bus is wired-and and a Dominant bit is logically 0, it follows that the message with the numerically lowest Arbitration Field will win the arbitration.

Error Handling

Error handling is built into in the CAN protocol and is of great importance for the performance of a CAN system. The error handling mainly aims at detecting errors in messages appearing on the CAN bus, so that the Transmitter can retransmit an erroneous message. Every CAN controller along a bus will try to detect errors within a message. If an error is found, the discovering node will transmit an Error Frame, thus destroying the bus traffic. The other nodes will detect the error caused by the Error Frame (if they haven't already detected the original error) and take appropriate action, i.e. discard the current message.

Each node maintains two error counters: the Transmit Error Counter and the Receive Error Counter. There are several rules governing how these counters are incremented and/or decremented. In essence, the a transmitter detecting a fault increments its Transmit Error Counter faster than the listening nodes will increment their Receive Error Counter. This is because there is a good chance that it is the transmitter who is at fault! When any Error Counter raises over a certain value, the node will first become "error passive", that is, it will not actively destroy the bus traffic when it detects an error, and then "bus off", which means that the node doesn't participate in the bus traffic at all.

Using the error counters, a CAN node can not only detect faults but also perform error confinement.

The CAN controller's habit of automatically retransmitting messages when errors have occurred can be annoying at times. There is at least one controller on the market (the SJA1000 from Philips) that allows for full manual control of the error handling.

The Layout of a Bit

From a programmer's point of view, each bit on the CAN bus is divided into at least 4 quanta. The quanta are logically divided into four groups or segments -

• the Start Segment
• the Propagation Segment
• the Phase Segment 1
• the Phase Segment 2

The bus levels are sampled at the border between Phase Segment 1 and Phase Segment 2. Most CAN controllers also provide an option to sample three times during a bit. In order to adjust the on-chip bus clock, the CAN controller may shorten or prolong the length of a bit by an integral number of quanta. The maximum value of these bit time adjustments are termed the Synchronization Jump Width, SJW.

This site is optimized for Netscape 4.0