Home>Failure Analysis Test Center>Test How-To

Debugging automotive serial buses: CAN, LIN and FlexRay exposed

Gregory Davis, Tektronix- July 26, 2012

It used be that that automobile buyers cared more about horsepower and styling when it came to figuring out what car to buy. Now it’s all about efficiency, and lately with the growth of consumer electronics, showroom battles are often won or lost based on gadgetry and electronic sophistication. In fact, it has been estimated that electronics account for approximately 25 percent of the value of today’s automobile. This figure is estimated to increase to nearly 40 percent in the future. Under the covers, all those electronics are linked together via multiple serial buses that must interact with the environment and communicate vital information throughout the entire vehicle.

Debugging and testing this type of network topology can be challenging and time consuming. It is therefore critical that electronics engineers working in the automotive industry become proficient at troubleshooting and debugging the serial bus architectures commonly used in automotive designs. These buses include CAN (controller area network) for mainstream powertrain communications, LIN (local interconnected network) for lower-cost electronics and FlexRay for higher-end applications.
This article will compare and contrast these three buses and then provide examples for debugging common problems that require the ability to decode the various network protocols and time-correlate network communication data with external events.

Understanding and working with CAN
CAN was originally developed in the 1980s by Robert Bosch GmbH, and in 1994 it became an international standard (ISO 11898).  Today, almost every automotive manufacturer uses ISO11898 controllers and networks to control a variety of devices in the automobile. While the newer LIN has displaced CAN in a number of applications, CAN is still the primary bus used for things such as engine timing controls, anti-lock braking systems, and power train controls. (Due to its electrical noise tolerance, minimal wiring, excellent error detection capabilities, and high speed data transfer, CAN is also gaining acceptance in other applications such as industrial control, marine, medical and aerospace.)

The CAN bus is a balanced (differential) 2-wire interface running over a shielded twisted pair (STP), un-shielded twisted pair (UTP), or ribbon cable. Each node uses a male 9-pin D connector. Non-return-to-zero (NRZ) bit encoding is used with bit stuffing to ensure compact messages with a minimum number of transitions and high noise immunity.

The CAN bus interface uses an asynchronous transmission scheme where any node may begin transmitting anytime the bus is free. Messages are broadcast to all nodes on the network. In cases where multiple nodes initiate messages at the same time, bitwise arbitration is used to determine which message is higher priority. Messages can be one of four types: data frame, remote transmission request (RTR) frame, error frame, or overload frame. Any node on the bus that detects an error transmits an error frame which causes all nodes on the bus to view the current message as incomplete and the transmitting node to resend the message.

Overload frames are initiated by receiving devices to indicate they are not ready to receive data yet. Data frames are used to transmit data while remote frames request data. Data and remote frames are controlled by start and stop bits at the beginning and end of each frame and include the following fields: arbitration, control, data, CRC and ACK.

A number of different data rates are defined, with 1Mb/s being the fastest, and 5 kb/s the minimum rate. All modules must support at least 20 kb/s. Cable length depends on the data rate used. Normally, all devices in the system transfer information at uniform and fixed bit rates. The maximum line length can be thousands of meters at low speeds although 40 meters at 1 Mb/s is typical. Termination resistors are used at each end of the cable.

For working with a CAN bus application, the preferred tool is a mixed signal oscilloscope (MSO) with the ability to support CAN bus triggering and analysis.  A MSO enables an engineer to simultaneously look at signals in both the digital domain and analog domain.  Triggers make it possible to isolate faulty messages that occur infrequently, say just once a day or even less.

Consider the need to make timing measurements associated with the latency from when a driver presses the passenger window down switch to when the CAN module in the driver’s door issues the command and then the time to when the passenger window actually starts to move. By specifying the ID of the CAN module in the driver’s door as well as the data associated with a “roll the window down” command, you can trigger on the exact data frame you’re looking for.
By simultaneously probing the window down switch on the driver’s door and the motor drive in the passenger’s door this timing measurement becomes simple, as shown in Figure 1.



Now imagine performing this task without these capabilities. Without the CAN triggering, the engineer would have to trigger on the switch itself, capture a hopefully long enough time window of activity, and then begin manually decoding frame after frame after frame on the CAN bus in order to find the right one.  Needless to say, for efficient CAN debug, having the right trigger types on hand is critical to success. Here is a summary of the CAN triggers that will be useful for virtually all debug scenarios:
•    Start of Frame (SOF) – trigger on the SOF field
•    Frame Type – choices are data frame, remote frame, error frame, and overload frame
•    Identifier – trigger on specific 11 or 29 bit identifier values with read / write qualification
•    Data – trigger on 1-8 bytes of user specified data
•    ACK – trigger anytime the receiving device does not provide an acknowledge
•    End of Frame (EOF) – trigger on the EOF field

In addition to triggering, troubleshooting will often require inspecting message content both before and after the trigger event. One way to view the contents of multiple messages in an acquisition is with an event table as show in Figure 2. The event table shows decoded message content for every message in an acquisition in a tabular format with timestamps. This makes it easy to not only view all the traffic on the bus but also enables easy timing measurements between messages.