Introductory notes about 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 micro controllers. 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.

On more great advantage with CAN is that the protocol has been in the market for so many years and hence very advanced controllers have been developed for CAN.

The CAN controller (h/w) will take care of the following:

1.      Arbitration on the bus
2.      Bit synchronization
3.      Error Handling.

Hence, I recommend all you guys working in DCX not to spend more time on understanding the intricacies in CAN like bit-timing calculations, error handling etc.. It is

Multi-Master Network

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.

Content based addressing

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.

This mode of operation is known as multi-cast.

How Arbitration Works on the CAN Bus

In any system, some parameters will change more rapidly than others. For example - parameters that change quickly could be the RPM of a car engine. Slower changing parameters may be the temperature of the coolant of a car engine. It is likely that the more rapidly changing parameters need to be transmitted more frequently and, therefore, must be given a higher priority.

To cater for real-time data communication, this requires not only a fast data transmission rate, but also a rapid bus allocation mechanism to deal with occasions when more than one node may be trying to transmit at the same time. To determine the priority of messages, CAN uses the established method known as Carrier Sense, Multiple Access with Collision Detect (CSMA/CD) but with the enhanced capability of non-destructive bitwise arbitration to provide collision resolution, and to deliver maximum use of the available capacity of the bus.

Non-Destructive Bit wise Arbitration

The unique identifier also determines the priority of the message. The lower the numerical value of the identifier, the higher the priority.

The numerical value of each message identifier (and thus the priority of the message) is assigned during the initial phase of system design.

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

The bus access mechanism of CAN is implemented as a non-destructive, bitwise arbitration. Non-destructive means that the winner of the arbitration - the message with the higher priority - must not re-start the message from the beginning.

The identifier with the lowest numerical value has the highest priority. Any potential bus conflicts are resolved by bit wise arbitration in accordance with the wired-and mechanism, by which a dominant state (logic 0) over writes a recessive state (logic 1).

For example, assume that three nodes are trying to transmit at the same time, as shown in Figure 2.

In this example, the competition for the bus is won by node 2 because its dominant bits overwrite in turn recessive bit 7 of node 1, and then recessive bit 3 of node 3.

The overall result is the same as if the highest priority message, in this example from node 2, was the only message being transmitted. As soon as any lower priority transmitter loses, it automatically becomes a receiver of the message with the highest priority (as indicated by the change from solid to dotted lines in Figure 2) and will not attempt re-transmission of its own message until the bus becomes available again.

Message Frames

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)

The meaning of the bitfields for Standard CAN messages are the following:

· Start Bit = 1 Bit = low (dominant)
Marks the start of a message. After a idle-time (bus not used) the falling edge of the Start Bit is used for a synchronization of the different network nodes.
· Identifier = 11 Bits
Logical address and priority of the message; the less the value the higher is the priority (0 -> highest priority)
· RTR Bit = 1 Bit
The RTR Bit (Remote Transmission Request) is used by a receiver to request a remote transmitter to send his information. If this bit is set to 1 (= recessive) the frame contains no data field even if the data length code defines something other. In this case all the other network nodes can check whether there is the corresponding transmitter defined or not. The request and the possible answer are 2 complete different frames on the bus. This means the answer can be delayed due to messages with higher priorities.
Control Field = 6 Bits
The first bit in the Control Field is the IDE Bit (Identifier Extension). If this bit is transmitted as logical 0 (dominant) the meaning is that there are no more identifier bits are sent (Standard CAN Frame). Bit r0 is reserved. The next four bits contain the data length code for the following data field.
Data Field = 0 to 64 Bits (0 to 8 Bytes)
Contains the application data of the message.
CRC Field = 16 Bits (including CRC Delimiter = high (recessive))
Contains a checksum for the preceding bits of the message. The CRC checksum will be used for error detection only. It is not used for error correction. The Hamming Distance of this CRC code is 6. With this it is possible to detect up to 6 single bit errors which are scattered about the message or so called burst errors up to a length of 15 bits.
ACK Field = 2 Bits (including ACK Delimiter = high (recessive))
Every active network node that detects the message to be correct on the bus overwrites the recessive level (driven by the transmitter of the message) by a dominant level in the ACK Slot. This bit is also read back by the transmitter of the message. If he reads back no dominant level in this ACK Slot this treated as an error.
Note: If the transmitter detects an acknowledgment he can not be sure that the message is received by the corresponding applications. The only thing he can be sure is that the message was correct transmitted (coded) on the CAN bus.
EOF Field = 7 Bits = high (recessive)
The EOF (End Of Frame) is marked by coding violation. The Bit Stuffing rule of the coding technique is violated. Under normal circumstances after the 5th bit with equal polarity an additional bit with reverse polarity is stuffed into the bit stream. This Bit Stuffing is switched off while the EOF is active. The EOF marks the end of a CAN frame.
IFS = 7 Bits = high (recessive)
The IFS (Inter Frame Space) marks the space of time that is necessary for the CAN controller to transfer a correct received frame from the bushandler to the corresponding place in the message buffer area.
Idle >= 0 Bit = high (recessive)
Bus it not used. Every bus node is allowed to start a message transfer.

The Extended CAN messages differ from Standard CAN messages in the following positions:
SRR = 1 Bit = high (recessive)
The SRR (Substitute Remote Request Bit) replaces the RTR Bit that would be sent in a Standard CAN message. There is no further meaning.
IDE = 1 Bit = high (recessive)
In Extended CAN messages the IDE Bit (Identifier Extension) is set to high to indicate that there will follow more identifier bits.
Control Field = 6 Bits
The first two bits in the control field of an Extended CAN frame are reserved (r0 and r1). The rest of this field (and the following parts of the message) have the same meaning than in Standard CAN messages.

Valid data length code values are 0..8. Data length codes greater than 8 are not allowed according to the CAN specifications.

The distinction between the two formats is made using an Identifier Extension (IDE) bit. If IDE = 0, the frame is standard frame. If IDE = 1, the frame is extended.

Note: In KWP2000, it is strongly recommended to use only standard frames and to maintain the data size of each frame as 8 data bytes. If the length of data in a frame is less than 8 bytes, the other bytes have to be “padded” with some pre-defined pattern.

Can we have both types of frames at a time on the network?

It is possible to use Standard (Part A) and Extended (Part B) CAN messages in one network.

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:

Message format \ CAN chip type
Part A
Part B Passive
Part B
11 bit ID
29 bit ID
tolerated on the bus, but ignored

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.

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.

Error Handling

The error management has the ability to detect five different errors

Bit Error
A node that is sending a bit on the bus also monitors the bus. A bit error is detected at that bit time, when the bit value that is monitored differs from the bit value sent.
Bit Stuffing Error
A stuff error is detected at the time of 6 consecutive equal bit level in a frame field that should be coded by the method of bit stuffing.
CRC Error
The CRC sequence received is not identical to the CRC sequence calculated.
Form Error
A form error is detected when a fixed-form bit field (CRC delimiter, ACK delimiter, EOF field) contains one or more illegal bits.
Acknowledgment Error
An acknowledgment error is detected by a transmitter whenever it does not monitor a dominant bit during the ACK slot.


There are two main implementation strategies for CAN controllers today. They are called BasicCAN and FullCAN.

The main difference between these strategys is that FULL CAN controller will have additional intelligence for the configuration of CAN controller to receive specific identifiers. The set of required identifiers will be configured at start up or on special conditions. Whenever a new frame is received over CAN bus; the identifier of the frame is compared with the list of supported identifiers. If the identifier matches, the message will be copied and the CPU will be informed about the reception.

In Basic CAN chips, this kind of intelligence won’t be present. Hence, whenever a CAN frame is received, it indicates the CPU for further action. Hence, the load on CPU will be more.

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

FullCAN is used in more expensive, high performance CAN controllers and microcontrollers.

1 comment: