---

The History of CAN

CAN (controller area network) is a serial bus protocol created in 1986 by the German company Bosch. This protocol was created to address the growing need for devices to effectively communicate over longer distances within automobiles. CAN is optimized for sending small amounts of data between multiple nodes, or devices, on a single line without the need for a centralized host computer; and while the CAN bus can only support signaling speeds up to 1 Mbps, this allows the bus to span over longer distances and remain reliable against electrical noise. Additionally, CAN eliminates the need for excess wiring due to its single multiplex architecture.

The CAN specification does not define standard CAN voltages or connector interfaces, but standards organization, including the International Organization for Standardization (ISO), have defined multiple physical standards for CAN. In 1993, the ISO released the CAN standard ISO 11898, which has since undergone multiple revisions, including ISO 11898-1 which describes the CAN data link layer, ISO 11898-2 which standardizes the “non-fault-tolerant” CAN physical layer, and ISO 11898-3, which is defines the “fault-tolerant” CAN physical layer.

Physical Layer Standards

High Speed CAN

High-speed CAN, or ISO-11898-2, is one of the most common types of CAN standards and uses two dedicated wires for communication, which allows the bus to support transfer rates up to 1 Mbps. This standard is commonly used in applications including antilock brake systems, engine control modules, and emissions systems.

Low Speed/Fault Tolerant CAN

Low Speed/Fault Tolerant CAN, or ISO-11898-3, supports lower bus speeds and fault tolerance, reaching signaling rates of 40 kbps up to 125 kbps. Due to its two-wire balance scheme for lower speeds, it is able to continually operate in the event of a faulty wire. This standard is frequently used in applications such as opening and closing doors.

Single Wire CAN

Additionally, for network applications with low bit rate and bus length requirements, the SAE J2411 single-wire specification uses just one bus line with a data rate of 33.3 Kbps, and is designed for vehicles.

Higher Layer Protocols

CANopen

The CAN protocol defines several higher layer protocols (built on CAN). One example includes a widely used protocol called CANopen. The objective of CANopen was to develop control architectures and devices to enable flexible and modular combinations of existing manufacturing cell units. In 1993, CiA, or CAN in Automation, published the very first version of the CANopen specification: CiA 301. Over the years, there have multiple published revisions of CiA 301, many of which are still used in applications today.

Today CANopen is used in industrial applications including medical equipment, automated building machinery, railway applications, and much more. These applications benefit from its configurability and standardized embedded network.

CAN Protocol Extensions

CAN-FD

Over the years, CAN has also introduced extensions to the CAN protocol, with one being CAN-FD. CAN-FD, or CAN flexible data-rate, was introduced in 2012 as an extension of the CAN protocol. Using dual-bit rates, this new extension offers the ability to transmit data up to 5 Mbps, five times greater than the initial 1 Mbps supported by the classical CAN protocol. CAN-FD also extends the bit length of a message from 8 bytes to 64 bytes, and includes improved error detection using extra bits in the CRC frame to improve the performance of the CRC-algorithm, better protecting the data content.

CAN-FD was initially created to address the bus limitations in automobiles, but has quickly been adopted by other industries as well, including industrial. This protocol allows for a larger payload, which is a major benefit in operating machinery as it results in reduced overhead and allows the bus to operate more efficiently.

CAN Bus Applications

When CAN was first introduced, it was initially designed for use in vehicles, but has since grown to be widely implemented in many industrial applications due to its various advantages, including its robustness and flexibility.

For use in vehicles, including passenger cars, trucks, boats, and spacecrafts, CAN is the preferred protocol for many reasons. For one, CAN functions over minimal wiring using a twisted pair system. This greatly reduces the overall weight of the vehicle. Additionally, CAN uses arbitration methods as a form of CAN bus negotiation that allow devices to prioritize messages for safe and efficient communication. In cases where multiple devices are trying to access the bus at once, the message with the highest priority will be transmitted while the other devices go into “listening” mode. This can be helpful for applications including power steering or brake controllers.

CAN is also heavily used in other industries, including industrial and factory automation, and medical, mining, and laboratory equipment. These industries often produce equipment that benefit from CAN’s fault and electromagnetic noise tolerance, as well as its ability to operate over longer distances while maintaining error checking mechanisms. For instance, many applications like hospital rooms use CAN in many devices, including cameras and x-ray machines. Even industrial applications including elevators often use CAN for these reasons.

How Does the CAN Protocol Work?

Nodes

CAN allows multiple nodes, or devices, to connect to the bus on a single line, where each node can operate as a transmitter or receiver at any time.  CAN nodes do not have strict master/slave roles and can operate without the need for a centralized host; instead, data messages are broadcasted across the bus and each node determines if the message is relevant based on the frame “identifier”, which describes the message’s contents.

CAN Bus Negotiation: Collision Detection and Arbitration

CAN bus negotiation includes collision detection and bus arbitration methods to address when multiple nodes transmit data simultaneously. During collision detection, nodes are able to detect data collision on the bus, at which point they are required to stop transmitting data. Arbitration is then used to prioritize messages sent on the bus and uses recessive and dominant bit states to determine which messages are handled first. Messages with a dominant bit are considered to be a high priority message, while messages with a recessive bit are least prioritized. As soon as the bus becomes available again, low-priority messages will start a new arbitration, ensuring a non-destructive bus arbitration.

CAN Frame Types and Format

There are four different message types, or frames, on a CAN bus:

1. Data Frame: carries 0-8 bytes of data, along with an identifier and CRC check
2. Remote Frame: requests a data frame transmission with a certain identifier node
3. Error Frame: transmitted when an error is detected
4. Overload Frame: provides extra delay between data and remote frames

 

Data Frame

CAN 2.0A is the standard CAN format that uses an 11-bit identifier, while CAN 2.0B is the extended CAN format which uses a 29-bit identifier. In CAN 2.0B messages, both standard and extended frames are supported and may exist on the same bus.

A Standard CAN Data Frame uses an 11-bit identifier and is composed of the following fields:

An Extended CAN Data Frame uses a 29-bit identifier (two identifier fields (A & B) combine to form a 29-bit identifier) and is composed of the following fields:

Remote Frame

A remote frame is broadcasted by a transmitter to request data from a specific node. It is only available in Classical CAN and has the same field structure as the data frame, but without a data field. Remote frames also have an RTR bit, but it is set to recessive.

Overload Frame

If a CAN node receives messages faster than it can process them, an overload frame is used to inject an additional delay between data or remote frames. An Overload Frame has two fields, including an overload flag consisting of six dominant bits and an overload delimiter consisting of eight recessive bits.

Error Frame

If a transmitting or receiving node detects an error, this will cause the node to stop transmission and broadcast an error frame on the network, subsequently causing all other nodes on the bus to send error frames as well. An error frame consists of two fields, including an error flag field, with a maximum of 12 bits (six dominant and 6 recessive bits) and an error delimiter consisting of 8 recessive bits.

Types of CAN Bus Errors

CAN Bit Errors

A CAN bit error occurs when the monitored value is different than the value being sent. For instance, if a node is transmitting dominant (0) to the bus and recessive (1) is detected, this will cause a bit error. A bit error can also be detected by stuffing.

CAN Bit Stuffing Error

To help ensure synchronization of the bus, bit stuffing is performed. Meaning, after 5 consecutive identical bits have been transmitted, a 6th opposite bit will be inserted by the transmitter into the bit stream. If any node detects that the 6^th consecutive bit remains of the same level, this will cause an error to be broadcasted on the bus.

CAN ACK Error

During proper CAN transmission, a receiving node will write a dominant bit into the ACK slot and the transmitting node will acknowledge this message. However, if perhaps the receiver has failed, and the transmitting node doesn’t monitor a dominant bit and doesn’t acknowledge the message, an ACK error is flagged.

CAN Form Errors

In CAN, the End of Frame, ACK Delimiter, and CRC Delimiter are all fixed format fields that are always recessive. If a node detects a dominant bit in any of these, a form error will be flagged.

CAN CRC Error

The transmitting node calculates a 15-bit CRC value and then transmits this value in the CRC field. All nodes will receive this message, calculate a CRC itself, and compare the values to determine if they are indeed the same. If not, this will produce a CRC error.

Which Tools Can Debug and Develop CAN Applications?

Developers looking to debug CAN data can do so using a few different tools, including protocol analyzers, CAN interfaces, or oscilloscopes.

Debugging and Developing CAN Devices Using an Oscilloscope

Oscilloscopes allow engineers to monitor and analyze waveforms on electrical signals. Many oscilloscopes can monitor and decode the CAN bus, providing visibility into CAN bus traffic and CAN bus errors. This is generally performed by acquiring the CAN High and CAN Low lines with single-ended probes on separate oscilloscope input channels. The differential waveforms can be determined by subtracting CAN Low lines from CAN High lines.

Oscilloscopes can decode CAN bus data using a bus signal, and can often filter for specific criteria relating to the bus traffic. These tools also provide hardware triggering capabilities, capable of performing triggers on specific CAN bus errors including ACK errors and CRC errors.

The eye diagram function on an oscilloscope provides visibility into any signal integrity issues on the CAN bus that stem from voltage and/or timing issues. They are useful in detecting jitter, glitches, reflections, crosstalk, noise, and more.

Debugging and Developing CAN Devices Using a CAN Bus Interface

CAN Bus Monitor (CAN Bus Sniffing)

A protocol analyzer, or bus monitor, is a tool commonly used by hardware, software, and firmware developers to analyze and debug embedded systems in all stages of the product lifecycle. Protocol analyzers connect between the host computer and peripheral devices to capture and decode raw bus data and events into human readable format, often flagging bus errors for easier troubleshooting.

There are a variety of protocol analyzers, each specific to analyzing certain data protocols, including I2C, SPI, USB, CAN, and eSPI. A CAN protocol analyzer, also known as a CAN bus sniffer or CAN bus monitor, will specifically capture and decode CAN communication, allowing developers to visualize the CAN bus and more easily debug CAN bus data.

A CAN bus monitor can analyze messages being shared between network nodes and provide the user with specific information occurring on the bus at a high level. Users can view the various nodes/devices on one or more CAN buses, as well as CAN bus data including decoded CAN data, the record or frame type, and bitrate. CAN bus monitors also provide insight into error frames, so finding the source of the bus error and gathering the statistical error rate can be easily performed.

Additionally, some CAN bus monitors can provide triggers to create specific responses to network events and filtering capabilities to more easily pinpoint certain data events, frame types, or error types.

CAN Adapter for Active CAN Transmission

CAN development tools such as host adapters can act as CAN node devices, allowing developers to read and write to the CAN network. This provides a way to test the validity of each individual node and verify that the bus is operating correctly. CAN development tools can include active CAN transmission capabilities as well as bus monitoring capabilities that allow users to actively send and receive CAN data on the bus while also monitoring these messages simultaneously.

Overview of Total Phase’s Komodo CAN Solo/Duo Interface

Total Phase offers CAN development tools that include the Komodo CAN Solo Interface and Komodo CAN Duo Interface.

Komodo CAN Solo Interface

The Komodo CAN Solo Interface is a powerful USB-to-CAN adapter and analyzer. It offers one configurable CAN channel to perform active CAN data transmission or non-intrusive CAN bus monitoring. This interface supports high-speed and fault-tolerant CAN bus speeds up to 1 Mbps and includes 8 GPIOs to connect external logic. This tool also provides real-time data capture and filtering capacities.

Komodo CAN Duo Interface

The Komodo CAN Duo Interface is a powerful USB-to-CAN adapter and analyzer that includes two configuration CAN channels. It is an all-in-one tool capable of simultaneous active CAN data transmission and non-intrusive CAN bus monitoring.  It can also be configured to allow users to monitor multiple independent CAN buses at once. This interface supports high-speed and fault tolerant CAN bus speeds up to 1 Mbps, and includes 8 GPIOS to connect external logic. This tool also provides real-time data capture and filtering capabilities.

For more detailed key features and abilities of the Komodo CAN Interface, please visit the Komodo CAN Interface Datasheet.

Additionally, for a demonstration on how to use the Komodo CAN Duo to write to a device and monitor CAN activity, please visit our video Using the Komodo GUI Software to Interface with the CAN/I2C Activity Board Pro.