Controller Area Network - CAN Information

Contents

The Bosch CAN specification version 2.0 can be downloaded from here.

What is CAN?

Controller Area Network (CAN) is a serial network that was originally designed for the automotive industry, but has also become a popular bus in industrial automation as well as other applications. The CAN bus is primarily used in embedded systems, and as its name implies, is the network established among microcontrollers. It is a two-wire, half duplex, high-speed network system and is well suited for high speed applications using short messages. Its robustness, reliability and the large following from the semiconductor industry are some of the benefits with CAN.

CAN can theoretically link up to 2032 devices (assuming one node with one identifier) on a single network. However, due to the practical limitation of the hardware (transceivers), it can only link up to110 nodes (with 82C250, Philips) on a single network. It offers high-speed communication rate up to 1 Mbits/sec thus allows real-time control. In addition, the error confinement and the error detection feature make it more reliable in noise critical environment.

Top of page

History

CAN was first developed by Robert Bosch GmbH, Germany in 1986 when they were requested to develop a communication system between three ECUs (electronic control units) in vehicles by Mercedes. They found that an UART is no longer suitable in this situation because it is used in point-to-point communication. The need for a multi-master communication system became imperative. The first CAN silicon was then fabricated in 1987 by Intel

Top of page

CAN standards

The original specification is the Bosch specification. Version 2.0 of this specification is divided into two parts:

• Standard CAN (Version 2.0A). Uses 11 bit identifiers.
• Extended CAN (Version 2.0B). Uses 29 bit identifiers.

The two parts define different formats of the message frame, with the main difference being the identifier length.

There are two ISO standards for CAN. The difference is in the physical layer, where ISO 11898 handles high speed applications up to 1Mbit/second. ISO 11519 has an upper limit of 125kbit/second.

Part A and Part B compatibility

There are three types of CAN controllers: Part A, Part B passive and Part B. They are able to handle the different parts of the standard as follows:

Most 2.0A controllers transmit and receive only Standard format messages, although some (known as 2.0B passive) will receive Extended format messages but then ignore them. 2.0B controllers can send and receive messages in both formats. Note that if 29 bit identifiers are used on a bus which contains part A controllers, the bus will not work!!!

Top of page

How does CAN work?

Introduction

As stated earlier, CAN is a multi master network. It uses CSMA/CD+AMP (Carrier Sense Multiple Access/Collision Detection with Arbitration on Message Priority). Before sending a message the CAN node checks if the bus is busy. It also uses collision detection. In these ways it is similar to Ethernet. However, when an Ethernet network detects collision both sending nodes stop transmitting. They then wait a random time before trying to send again. This make Ethernet networks very sensitive to high bus loads. CAN solves this problem with the very clever principle of arbitration.

Principle

Data messages transmitted from any node on a CAN bus do not contain addresses of either the transmitting node, or of any intended receiving node.

Instead, the content of the message is labelled by an identifier that is unique throughout the network. All other nodes on the network receive the message and each performs an acceptance test on the identifier to determine if the message, and thus its content, is relevant to that particular node.

If the message is relevant, it will be processed; otherwise it is ignored.

Identifiers & arbitration

The unique identifier also determines the priority of the message. The lower the numerical value of the identifier, the higher the priority. This allows arbitration if two (or more) nodes compete for access to the bus at the same time.

The higher priority message is guaranteed to gain bus access as if it were the only message being transmitted. Lower priority messages are automatically re-transmitted in the next bus cycle, or in a subsequent bus cycle if there are still other, higher priority messages waiting to be sent.

Each CAN message has an identifier which is 11 bits (CAN specification part A) or 29 bits (part B). This identifier is the principle part of the CAN arbitration field, which is located in the beginning of each CAN message. The identifier identifies the type of message, but is also the message priority.

The bits in a CAN message can be sent as either high or low. The low bits are always dominant, which means that if one node tries to send a low and another node tries to send a high, the result on the buses will be a low. A transmitting node always listens on the bus while transmitting. A node that sends a high in the arbitration field and detects a low knows that it has lost arbitration. It stops transmitting, letting the other node, with a higher priority message, continue uninterrupted.

Two nodes on the network are not allowed to send messages with the same id. If two nodes try to send a message with the same id at the same time arbitration will not work. Instead, one of the transmitting nodes will detect that his message is distorted outside of the arbitration field. The nodes will then use the error handling of CAN, which in this case ultimately will lead to one of the transmitting node being switched off (bus-off mode).

Remote frames

There are two kinds of frames in CAN - remote frames and data frames. Data frames are used when a node wants to transmit data on the network, and are the "normal" frame type.

Remote frames can be described as a request for information. A frame with the RTR bit set (see description of the CAN message format) means the transmitting node is asking for information of the type given by the identifier. A node which has the information available should then respond by sending the information onto the network.

Depending on the implementation of the CAN controller the answer may be sent automatically. Simpler CAN controllers (BasicCAN) can not respond automatically. In this case the host microcontroller is made aware of the remote request and has to send the data.

Top of page

Message formats

Format of a CAN message

In a CAN system, data is transmitted and received using Message Frames. Message Frames carry data from a transmitting node to one, or more, receiving nodes.

The CAN protocol supports two Message Frame formats.

The two formats are:

- Standard CAN (Version 2.0A)

- Extended CAN (Version 2.0B)

Most 2.0A controllers transmit and receive only Standard format messages, although some (known as 2.0B passive) will receive Extended format messages but then ignore them. 2.0B controllers can send and receive messages in both formats.

2.0A Format

A Standard CAN (Version 2.0A) Message Frame consists of seven different bit fields:

- A Start of Frame (SOF) field. This is a dominant (logic 0) bit that indicates the beginning of a message frame.

- An Arbitration field, containing an 11 bit message identifier and the Remote Transmission Request (RTR) bit. A dominant (logic 0), RTR bit indicates that the message is a Data Frame. A recessive (logic 1) value indicates that the message is a Remote Transmission Request (otherwise known as Remote Frame.) A Remote Frame is a request by one node for data from some other node on the bus. Remote Frames do not contain a Data Field.

Fig CAN 2.0A Message Frame

- A Control Field containing six bits:

* two dominant bits (r0 and r1) that are reserved for future use, and

* a four bit Data Length Code (DLC). The DLC indicates the number of bytes in the Data Field that follows

- A Data Field, containing from zero to eight bytes.

- The CRC field, containing a fifteen bit cyclic redundancy check code and a recessive delimiter bit

- The ACKnowledge field, consisting of two bits. The first is the Slot bit which is transmitted as a recessive bit, but is subsequently over written by dominant bits transmitted from all other nodes that successfully receive the message. The second bit is a recessive delimiter bit

- The End of Frame field, consisting of seven recessive bits.

Following the end of a frame is the INTermission field consisting of three recessive bits. After the three bit INTermission period the bus is recognised to be free. Bus Idle time may be of any arbitrary length including zero.

2.0B Format

The CAN 2.0B format provides a twenty nine (29) bit identifier as opposed to the 11 bit identifier in 2.0A.

Version 2.0B evolved to provide compatibility with other serial communications protocols used in automotive applications in the USA. To cater for this, and still provide compatibility with the 2.0A format, the Message Frame in Version 2.0B has an extended format.

The differences are:

- In Version 2.0B the Arbitration field contains two identifier bit fields. The first (the base ID) is eleven (11) bits long for compatibility with Version 2.0A. The second field (the ID extension) is eighteen (18) bits long, to give a total length of twenty nine (29) bits.

- The distinction between the two formats is made using an Identifier Extension (IDE) bit.

Fig 4.CAN 2.0B Message Frame

- A Substitute Remote Request (SRR) bit is included in the Arbitration Field. The SRR bit is always transmitted as a recessive bit to ensure that, in the case of arbitration between a Standard Data Frame and an Extended Data Frame, the Standard Data Frame will always have priority if both messages have the same base (11 bit) identifier.

All other fields in a 2.0B Message Frame are identical to those in the Standard format.

2.0A and 2.0B Compatibility

2.0B controllers are completely backward compatible with 2.0A controllers and can transmit and receive messages in either format.

Note, however, that there are two types of 2.0A controllers:

- The first is capable of transmitting and receiving only messages in 2.0A format. With this type of controller, reception of any 2.0B message will flag an error.

- The second type of 2.0A controller (known as 2.0B passive) is also capable of sending and receiving 2.0A messages, but in addition, these devices will acknowledge receipt of 2.0B messages and then ignore them.

Therefore, within the above mentioned constraints it is possible to use both Version 2.0A (with 2.0B passive capabilities) and 2.0B controllers on a single network.

However, because of the lack of full upward compatibility of 2.0A devices with 2.0B devices, only messages in Standard format are meaningful in systems using both types.

The number of unique identifiers available to users, on a single 2.0A network, is 2,032 (2 to the power 11 - 2 to the power 4).

The number of unique identifiers available on a 2.0B network is in excess of 500 million!

Error detection and fault confinement

The error detection, signalling and fault confinement defined in the CAN standard makes the CAN bus very reliable. The built in error detection of the controllers together with the error signalling make sure that the information is correct and consistent. Faulty nodes will go to modes where they do not disturb the traffic on the bus.

The CAN error process

1. The error is detected by the a CAN controller (a transmitter or a receiver).
2. An error frame is immediately transmitted.
3. The message is cancelled at all nodes (exceptions exist - see CAN controller error modes).
4. The status of the CAN controllers are updated (see CAN controller error modes).
5. The message is re-transmitted. If several controllers have messages to send, normal arbitration is used.

Error detection

Error detection is handled automatically by the CAN controller. The detected errors are:

• Bit errors:

1. Bit stuffing error - normally a transmitting node inserts a high after five consecutive low bits(and a low after five consecutive high). This is called bit stuffing. A receiving node that detects violation (more than five consecutive bits will see a bit stuffing violation.
2. Bit error: A transmitting node always reads back the message as it is sending. If it detects a different bit value on the bus than it sent, and the bit is not part of the arbitration field or in the acknowledgement field, and error is detected.

• Message errors:

1. Checksum error - each receiving node checks CAN messages for checksum errors.
2. Frame error - There are certain predefined bit values that must be transmitted at certain points within any CAN Message Frame. If a receiver detects an invalid bit in one of these positions a Form Error (sometimes also known as a Format Error) will be flagged.
3. Acknowledgement Error - If a transmitter determines that a message has not been ACKnowledged then an ACK Error is flagged.

CAN controller error modes

A CAN controller can be in one of three states:

1. Error active - the normal operating mode for a controller. Messages can be received and transmitted. On detecting an error an active error flag is sent (see error signalling).
2. Error passive - a mode entered when the controller has frequent problems transmitting or receiving messages. Messages can be received and transmitted. On detecting an error while receiving, a passive error flag is sent.
3. Bus off - entered if the controller has serious problems with transmitting messages. No messages can be received or transmitted until the CAN controller is reset by the host microcontroller or processor.

The mode of the controller is controlled by two error counters - the transmit error counter (tx_count) and the receive error counter (rx_count). The following rules apply:

1. The CAN controller is in error active mode if tx_count <= 127 AND rx_count <= 127.
2. Passive mode is used if (tx_count > 127 OR rx_count > 127) AND tx_count <= 255.
3. Bus off is entered if tx_count > 255.

Once the CAN controller has entered bus off state, it must be reset by the host microcontroller or processor in order to be able to continue operation. In addition, this is only allowed after the reception of 128 occurrences of 11 consecutive recessive bits.

The counters are updated as follows:

1. When a receiver detects an error, the rx_count will be increased by 1, except when the detected error was a bit error during the sending of an active error flag or an overload flag.
2. When a receiver detects a dominant bit as the first bit after sending an error flag, the rx_count will be increased by 8.
3. When a transmitter sends an error flag, the tx_count is increased by 8.

   Exception 1:If the transmitter is error passive and detects an ack error because of not detecting a dominant ack and does not detect a dominant bit while sending its passive error flag.

   Exception 2: If the transmitter sends an error flag because a stuff error occurred during arbitration whereby the stuff bit is located before the RTR bit, and should have been recessive, and has been sent as recessive but monitored as dominant.

4. If a transmitter detects a bit error while sending an active error flag or an overload flag, the tx_count is increased by 8.
5. If a receiver detects a bit error while sending an active error flag or an overload flag the rx_count is increased by 8.
6. Any node accepts up to 7 consecutive dominant bits after sending an active or passive error flag or an overload flag. After detecting the 14th consecutive dominant bit (in the case of an active error flag or an overload flag), or after detecting the 8th consecutive dominant bit following a passive error flag, and after each sequence of additional 8 consecutive dominant bits every transmitter increases its tx_count by 8 and every receiver increases its rx_count by 8.
7. After the successful transmission of a message (getting ack and no error until end of frame is finished) tx_count is decreased by 1 unless it was already 0.
8. After the successful reception of a message (reception withour error up to the ack slot and the successful sending of the ack bit), rx_count is decreased by 1 if it was between 1 and 127. If rx_count was 0 it stays 0, and if it was greater than 127, it will be set to a value between 119 and 127.

Note: If a node is the only one on the bus (or during start-up the only one that has become active), and it transmits a message, it will get an acknowledgement error, and will retransmit the message. This may lead to that node going to error passive mode, but not to it becoming bus off (due to exception 1 under point 3).

Error signalling

When an error is detected by a node it sends an error flag on the bus. This prevents any other node from accepting the message and ensures consistency of data throughout the network.

The active error flag consists of six low bits, and is used if the node transmitting the error frame is in active error state. As low is dominant all other nodes will detect bit stuffing violation and send their own error flags. After this, nodes that want to transmit (including the one sending the interrupted message) will start to do so. As usual, the node whose message has the highest priority will win arbitration and send its message.

If the CAN controller is in error passive mode the error frame will consist of six passive (high) bits. Since the error flag only consists of passive bits, the bus is not affected. If no other node detected an error, the message will be sent uninterrupted. This ensures that a node having problems with receiving can not block the bus.

All of this advanced error handling is done automatically by the CAN controller, without any need for the host microcontroller to do anything. This is one of the big advantages of CAN.

Bit timing

CAN has advanced features for coping with the time delays found in long bus lengths (in comparison to the bit rate) and coping with differences in clock chrystal frequencies for nodes on the bus.

The choice of bit timing is very important since it decides the bit rate, the sample point and the ability to resynchronise.

Bit segments (as in Bosch standard)

Each bit is divided into four segments - the synchronisation segment, the propagation segment and the phase segments one and two. Each segment consists of one or more time quanta.

A time quantum is a fixed amount of time which is derived from the CAN controller clock with a prescale factor.

Synchronisation segment (Synch_Seg)

The synchronisation segment is used to synchronise the various nodes on the bus. When a bit is sent on the bus, the leading edge is expected to be within this segment.

This segment is always one time quantum long.

Propagation segment (Prop_Seg)

The Propagation Segment is needed to compensate for the delay in the bus lines.

The segment size is programmable between 1 and 8 time quanta.

Phase Segment 1 (Phase_Seg1), Phase Segment 2 (Phase_Seg2)

These segments can be used lengthened or shortened by resynchronisation.

Bit segments (as in implementations like Intel 527 and C167CR)

In most implementations of CAN controllers the segments seem to be implemented in a different way than described in the standard. The synch segment looks as in the standard and consists of one time quantum. The big difference is that the propagation segment and the phase segment 1 in the standard have been combined into one segment, TSEG1. Phase segment 2 is left untouched, but is renamed to TSEG2.

Normally there is only one sample point for each bit. In this case, the sample point is in the edge between TSEG1 and TSEG2. However, some CAN controllers can also sample each bit three times. In this case, the bit will be sampled three quanta in a row, with the last sample being taken in the edge between TSEG1 and TSEG2.

Three samples should only be used for relatively slow baudrates.

Calculation of baudrate and sample point

Baudrate

The baudrate of the bus can be calculated from:

Baudrate = fcrystal / (2*n*(BRP+1))

where n is the number of time quanta for one bit and is defined as :

n = SYNCHSEG+TSEG1+TSEG2

BRP is the value of the BaudRate Prescaler.

Warning: some CAN controllers (like Intel 526) has an other way of calculating the number of time quantas in a bit! Consult your users manual.

Sample point

Quantabeforesample = TSEG1 + 1

Quantaaftersample = TSEG2

Often the sample point is given in percent of the bit time. This is:

(TSEG1+1)/(TSEG1+1+TSEG2)

Warning: some CAN controllers (like the C167CR) use an other way of calculating Quanta_aftersample. Consult your manual!

Resynchronisation

Resynchronisation is done to compensate for bus delays and nodes that have different crystal frequencies. Synchronisation is normally only done on the edge from recessive to dominant bus level.

Hard resynchronisation

When the bus is idle and the controller detects a start bit, it resynchronises itself so that the edge is inside the Synch segment. Hard resynchronisation can only be made for the first bit in a frame.

Resynchronisation within a frame

CAN controllers have the ability to synchronise on bit edges also within a frame. The (re)Synchronisation Jump Width (SJW) decides the maximum number of time quanta that the controller can resynchronise every bit.

• Resynchronisation of a receiver to a slower transmitter is handled as follows:

If a recessive-to-dominant edge appears inside TSEG1 and the edge is less than or equal to SJW quanta inside, TSEG1 is restarted . If the edge was more than SJW quanta inside, TSEG1 is lengthened with SJW quanta.

• Resynchronisation of a receiver to a faster transmitter:

If a recessive-to-dominant edge appears inside TSEG2 , TSEG2 is shortened by the number of quantas necessary to make the edge be outside TSEG2. However, TSEG2 can be shortened no more than SJW quanta.

CAN bus physical layer

The physical layer is not part of the Bosch CAN standard. However, in the ISO standards transceiver characteristics is included.

CAN transmits signals on the CAN bus which consists of two wires, a CAN-High and CAN-Low. These 2 wires are operating in differential mode, that is they are carrying inverted voltages (to decrease noise interference) The voltage levels, as well as other characteristics of the physical layer, depend on which standard is being used.

ISO 11898

The voltage levels for a CAN network which follows the ISO 11898 (CAN High Speed) standard are described in the picture and table below.

Note that for the recessive state, nominal voltage for the two wires is the same. This decreases the power drawn from the nodes through the termination resistors. These resistors are 120ohm and are located on each end of the wires. Some people have played with using central termination resistors (that is, putting them in one place on the bus). This is not recommended, since that configuration will not prevent reflection problems.

ISO 11519

The voltage levels for a CAN network which follows the ISO 11519 (CAN Low Speed) standard are described in the table below.

ISO 115519 does not require termination resistors. They are not necessary because the limited bit rates (maximum 125 kB/s) makes the bus insensitive to reflections.

The voltage level on the CAN bus is recessive when the bus is idle.

Bus lengths

The maximum bus length for a CAN network depends on the bit rate used. It is required that the wave front of the bit signal has time to travel to the most remote node and back again before the bit is sampled. This means that if the bus length is near the maximum for the bit rate used, one should choose the sampling point with utmost care - one the other hand, one should always do that!

Below is a table of different bus lengths and the corresponding maximum bit rates.

Cable

According to the ISO 11898 standard, the impedance of the cable shall be 120 +- 12 ohms. It should be twisted par, shielded or unshielded. Work is in progress
on the single-wire standard SAE J2411.

Top of page

CAN implementations

Different implementations - BasicCAN and FullCAN

There is no standard for how CAN controllers shall be implemented or how they shall communicate with their host microcontroller. There are two main implementation strategies for CAN controllers today. They are called BasicCAN and FullCAN.

The main difference between these strategies is how interesting messages are filtered out, that is how it is decided what messages are interesting and which are not. There are also differences in how remote frames are answered, and on how messages are buffered. The differences will effect how much load is put on the host microcontroller.

BasicCAN

BasicCAN is usually used in cheaper standalone CAN controllers or in smaller microcontrollers with integrated CAN controller.

A BasicCAN controller normally has two receive buffers and one transmit buffer. The receive buffers are arranged in a FIFO structure, and a message can be received into the one buffer while the microcontroller is reading the information from the other buffer. If a message is received while both receive buffers are full, the oldest messages are kept. This means that newer messages might be lost if the host microcontroller does not read the messages fast enough.

A message is sent by writing it to the transmit buffer.

Interesting messages are filtered out using two registers, that operate on the message identifier. Each bit in the identifier are checked against the filter. If the message matches the filter it is stored in one of the receive buffers.

Each bit of the identifier filter can be set to '1', '0' or 'don't care'. Often the filter only operates on eight of the eleven bits in the identifier (standard CAN). This means the three lower bits in the identifier are always 'don't care'.

When BasicCAN is used it is important to choose identifiers with utmost care, so that the window of the filter can be kept as small as possible. All message that is let through the filter must be read and checked by the microcontroller. This means that the final filtering is done in software.

A BasicCAN controller has no support for automatically answering remote frames, which means that the application will have to handle them. This will put extra load on the microcontroller or processor, but will make sure that the value returned is updated.

BasicCAN features

FullCAN

FullCAN is used in more expensive, high performance CAN controllers and microcontrollers. The FullCAN controller has a set of buffers called mailboxes. On initialization, each mailbox is assigned an identifier and is set to transmit or receive.

When the CAN controller receives a message it checks the mailboxes in order to see is there is a receive mailbox with the same identifier as the message. If such a mailbox is found, the message is stored in it and the host controller is notified. Otherwise the message is discarded.

When transmitting a message the message length and data is written to the transmit mailbox with the correct identifier.

If a remote message is received the controller checks the remote identifier against the transmit mailboxes. If a match is found, the controller automatically sends a message with the identifier and data contained in that mailbox. This means that the microcontroller gets a lower load, and that the software does not have to handle remote messages. However, if the mailbox has not been updated in a long time, the information sent to the network will be old. This have to be considered when writing the software.

With a FullCAN controller it is possible to filter out only the exact message types that are interesting. This type of controller will therefore give a lower load on the host microcontroller. However, the number of mailboxes are limited. The largest number of mailboxes present in a CAN controller today is ???.

With some controllers it is possible to reconfigure the mailboxes dynamically. However, that does not completely solve the problem. Therefore some controllers are mixed CAN controllers, that is they have mailboxes, but also BasicCAN buffers.

FullCAN controllers have support for automatically answering remote frames. This will decrease the load on the host microcontroller or processor, but may also mean that old information is sent. It is very important to take this into consideration when writing your application.

FullCAN features

Top of page

FAQ - Frequently Asked Questions

I will update this section as I receive questions from the readers of this page.

Question: The transmitter considers the data / remote frame transfer valid if no error occurs until the end of the corresponding EOF delimiter.
Why does the receiver consider the transfer valid when there is no error until the last but one bit of the EOF delimiter ( why doesn't the receiver check until the end of the corresponding EOF delimiter, like what the transmitter do. ) ?

Answer: If a receiver detects a corrupt frame, it sends an error frame (in the normal case, an active error flag). This will cause all other receivers AND the transmitter to detect a corrupt frame, they all send their error frames and the transmitter resends the frame (normal arbitration is used).

Now assume that the protocol was implemented the way that you suggest, what would happen if the receiver detects an error on the last bit of the EOF? It will start to send its error frame, but the transmitter (and other receivers) may already have have accepted the frame as valid (not having detected any errors up to and including the whole eof). This means that one (or more) receivers have not received a valid frame, but the transmitter thinks that it is sent ok and will not repeat it!!!

The problem is solved in CAN - if a receiver detects an error in the last bit that it cares about (the last but one bit of the eof) it will send an error frame. This will corrupt the last bit that the transmitter cares about (the last bit of the eof) and he will retransmit the message.

Question: Why is the number of unique identifiers available to users, on a single 2.0A network, 2,032 (2 to the power 11 - 2 to the power 4)? What happens to the other 16 identifiers?

Answer: Some old CAN controllers (notably the Intel 82526) could not handle messages where the 7 most significant bits where all set to one. That leaves identifiers 0..2031 for use. If you know that no such old CAN controllers will be connected to the bus, all of the 2048 possible identifiers may be used.

I would like to thank Mike Schofield, for providing much useful information on his site. 

This page has had visits since 1997-06-01

Return to Home

If you have any suggestions on what could be added to this page, or if you found any misinformation on this page, please contact me. I, Staffan Nilsson, can be contacted at publicinfo@staffannilsson.eu