CAN and CAN FD bus decoding

CAN bus (Controller Area Network) is a serial data standard originally developed in the 1980s by Robert Bosch GmbH for use in automotive applications. Today it is also widely used in industrial process control and aerospace applications.

It allows microcontrollers and electronic devices to communicate with each other without using a host computer and provides fast and reliable data transfer in electrically noisy environments at low cost and with minimal wiring.

CAN employs differential signaling to provide a high level of immunity to electrical noise.

In 1991 Bosch published the specification for CAN 2.0, which details two formats:

  • CAN 2.0A is the standard format with an 11-bit identifier.
  • CAN 2.0B is the extended format with a 29-bit identifier.

In 1993 ISO (International Organization for Standardization) released the CAN standard ISO 11898, which was later restructured into three parts:

  • ISO 11898-1 which covers the data link layer
  • ISO 11898-2 which covers the CAN physical layer for high-speed CAN (up to 1 Mbit/s).
  • ISO 11898-3 which covers the CAN physical layer for low-speed, fault-tolerant CAN (up to 125 kbit/s)

Bosch subsequently released CAN FD 1.0 or CAN with Flexible Data-rate, which was incorporated into ISO 11898-1:2015. This specification allows for increased data lengths as well as optionally switching to a faster bit rate after the arbitration is decided. CAN FD is reverse-compatible with existing CAN 2.0 networks, so new CAN FD devices can coexist on the same network with existing CAN devices.

Wiring

Many devices can be connected to the CAN bus, ranging from complex electronic control units to simple I/O devices. Each device is called a node.

Each CAN node transmits differentially over two wires: CAN High and CAN Low.

Signalling

CAN transmits differentially over two lines, CAN High and CAN Low. There are two logic states:

  • Dominant – Logic 0
  • Recessive – Logic 1

Voltage levels vary according to the spec. Here we look at High Speed CAN.

During a recessive (logic 1) transmission the bus is not actively driven and rests at around 2.5 V.

During a dominant (logic 0), CAN High is driven towards 5 V (or Vcc) and CAN Low is driven towards 0 V.

Arbitration

CAN data is sent in Frames starting with a dominant 0 followed by an Identifier, which forms the basis of arbitration (Priority) where two or more nodes attempt to transmit at the same time.

Each node is assigned an Identifier which can be 11 bits (CAN 2.0A) or 29 bits (CAN 2.0B) in length.

The table shows three nodes attempting to transmit at the same time, each starting with dominant 0s. When a node transmits a recessive 1 but sees that the bus remains at dominant 0, it realizes there is a contention and ceases to transmit and waits for the next opportunity to transmit.

In this way the node with the lowest value ID wins arbitration and is given priority to transmit the rest of the frame.

CAN frame arbitration logic

Frames

CAN has four frame types:

  • Data frame: a frame containing node data for transmission.
  • Remote frame: a frame requesting the transmission of a specific identifier.
  • Error frame: a frame transmitted by any node detecting an error.
  • Overload frame: a frame to inject a delay between data and/or remote frame.

The RTR bit (Remote transmission request) determines between data frames (0) and remote frames (1)

A CAN network can be configured to work with two different frame formats: the base frame format (CAN 2.0A & CAN 2.0B) which supports 11-bit identifiers, and the extended frame format (CAN2.0B only) which supports 29-bit identifiers by allowing the addition of an 18-bit identifier extension.

An identifier extension bit (IDE) determines if the 18-bit ID extension is being used.

The table shows the format for a CAN Data Frame with Base Format (11-bit) with no bit stuffing

The Data Length Code indicates the length of data in bytes; in this case 1 byte.

CRC stands for cyclic redundancy check, which is used for error detection.

Ack slot bit – All nodes that receive a frame without finding any errors transmit a dominant 0, which overrides a recessive 1 sent by the transmitter. If the transmitter detects a recessive 1, it knows that the frame was not received correctly.

End of frame is confirmed by the transmission of 7 recessive 1s.

CAN frame showing field types.

Complete CAN data frame structure

Bit-stuffing

To ensure enough transitions to maintain synchronization, a bit of opposite polarity is inserted after five consecutive bits of the same polarity. Bit-stuffing does not occur during the CRC delimiter, ACK field and end of frame.

In the fields where bit-stuffing is used, six consecutive bits of the same type (000000 or 111111) are considered an error and an active error flag consisting of six consecutive dominant bits can be transmitted by a node when an error has been detected. 

CAN FD

Bosch followed the CAN standard with CAN FD 1.0 or CAN with Flexible Data-Rate, which later became part of the ISO 11898-1:2015 standard. This specification allows for increased data lengths as well as optionally switching to a faster bit rate after the arbitration is decided.

CAN FD meets the growing need to transfer more data, more quickly, in automotive (and other) systems of increasing complexity.

CAN FD is reverse-compatible with existing CAN 2.0 networks so new CAN FD devices can coexist on the same network with classical CAN devices.

Differences in protocol between CAN and CAN FD

The table shows the structure of a CAN FD frame.

Arbitration and the use of Base and Extended frame formats are identical in both classical CAN and CAN FD.

As CAN FD does not use remote frames, the RTR bit used in CAN is redundant and is replaced with the Remote Request Substitution bit (RRS), which is always transmitted dominant (0).

The IDE bit is used in the same way.

The reserve bit in CAN now becomes the FDF bit (Flexible Data Format) and is a dominant 0 to indicate that the frame is in classic CAN format. Frames sent in CAN FD format are indicated with a recessive 1.

Next is a reserve bit for future use.

Then comes the BRS bit (Bit Rate Switch). If BRS is sent dominant, the bit rate remains the same across the whole frame. If BRS is recessive, a higher bit rate will be transmitted after this bit up to and including the CRC delimiter.

The ESI bit (Error State Indicator) is a dominant transmission for error active, and recessive transmission for error passive.

CAN FD frame structure

Table of CAN FD data length codes

Data Length Code

The number of bytes in the Data Field is indicated by the Data Length Code (DLC). Its coding is different in CAN and in CAN FD. The first nine codes are the same, but the following codes, that in CAN all specify a DATA FIELD of eight bytes, specify longer DATA FIELDS in CAN FD.

CAN FD CRC field

Because of the longer data lengths with CAN FD, more bits are required for the CRC check. If the frame holds 16 bytes or less, a CRC with 17 bits is used; and if the CAN frame holds more than 16 bytes, a CRC with 21 bits is used.

After the CRC field the Ack and end of frame structure is the same as with classical CAN.

CAN bus debugging

Errors can occur due to inductors, coils and power devices which can cause large voltage spikes, noise and ringing.  An increasing number of embedded computers and devices are being added to automobile CAN buses and as more nodes are added the available bus time becomes more occupied. When the traffic reaches around 40% of the bus time, errors can start to occur. At this point an oscilloscope may be required to debug the network.

To monitor and find faults on a CAN bus it is important to have an oscilloscope with deep memory to capture a large time window with multiple frames of data. The instrument can then process the entire acquired waveform and then zoom in to analyze the data packets.

We recommend that the instrument has a bandwidth of ten times the CAN baud rate, to analyze rise times and any fault conditions. 

Step one – probing

CAN is a differential signal, CAN Low being the inverse of CAN High. Viewing the difference between the two removes any common-mode interference encountered by the signal during transmission.

Best results will be achieved by acquiring the signal difference between CAN Low and CAN High using a differential probe or a differential input oscilloscope such as the PicoScope 4444.

The signal can still be acquired using a single-ended probe connected to either CAN Low or CAN high, but any common-mode noise will be displayed and may cause errors in decoding on the oscilloscope which would not affect the CAN receiver.

Step two - acquire the CAN data signal

Set memory length to enough to acquire as many frames as required, and with the resolution required to resolve individual bits.

Or use the buffer memory index to capture short bursts of frames while ignoring any dead time in between.

Protocol decoder selection menu in PicoScope

Step three – set up a decoder

Select Serial Decoding from the Tools menu, click Create, then select CAN.

CAN bus decoder settings in PicoScope

Select Channel > Data > A and Configuration either Low or High if probing single ended, or High if probing differentially.

PicoScope will automatically calculate the optimum threshold, hysteresis and baud rate but these values can be customized if necessary.

In the Display menu tick Graph or Table, or both, and then select the required format—Hex/Binary/Decimal/ASCII—and click OK.

If Graph is selected, a color-coded trace will appear in the graph display, time-correlated with the acquired data.

If Table is selected, all the data will be presented in a table format. There are several useful features available with the table:

  • Double-click a frame in the graph format and the corresponding frame will be highlighted in the table.
  • Select Export to save the table data in .csv format.
  • Set up a Link file so that data in the table can be displayed as meaningful text.
  • Filter on the table to search any field for specific values, for example invalid CRCs.

Summary

CAN and CAN FD decode is a standard feature in the PicoScope software and can be used with all real-time PicoScope oscilloscopes.