The Bosch CAN specification version 2.0 can be downloaded from here.
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.
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
The original specification is the Bosch specification. Version 2.0 of this specification is divided into two parts:
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!!!
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.
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).
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.
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.
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
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!
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
Error detection is handled automatically by the CAN controller. The detected errors are:
A CAN controller can be in one of three states:
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:
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:
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).
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.
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
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.
Quantabeforesample = TSEG1 + 1
Quantaaftersample = TSEG2
Often the sample point is given in percent of the bit time. This is:
Warning: some CAN controllers (like the C167CR) use an other way of calculating Quantaaftersample. Consult your manual!
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.
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.
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.
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.
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.
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.
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
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 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.
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.
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
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
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
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