By Larry Carley
Whether you like it or not, Controller Area Networks (CAN) have taken over. CAN technology has been steadily creeping into more and more new vehicles since it first appeared in 1992 on certain Mercedes-Benz models. Thanks to federal emissions rules, it is now required on all 2008 model year vehicles, and will be forevermore.
What exactly is CAN? It’s basically a communications protocol (ISO 15765) that onboard modules use to share data and interact with one another. Think of it as a sort of digital Morse Code that the modules use to talk to each other. The communication rules are defined by the CAN standards, which cover the length and coding of messages, that messages get priority over other messages, and even the speed at which the messages are sent and received.
Why do we need CAN? The onboard electronics that regulate everything from engine performance to gear shifting to opening a power window have become more complicated than ever, with more and more modules being used throughout the vehicle for almost every conceivable function. In addition to the “big” modules like the Powertrain Control Module (PCM), Body Control Module (BCM) and antilock brake/traction control/stability control module, some vehicles now have more than 50 other modules scattered here and there behind panels, under seats, under the instrument panel, in the engine compartment and trunk.
This “modulization” of functions allows cars to be smarter than ever before, and to do things that were heretofore impossible, like using steering, braking and engine torque inputs to improve vehicle handling, calling OnStar if a fault occurs in any monitored system or in the event of an accident, etc. These are great features to have in a vehicle, but it’s debatable whether or not we really need all of this technology to drive a vehicle from point “A” to point “B.” The engineers who dream up this stuff certainly seem to think so.
Personally, I think the more complexity they build into a vehicle, the more potential problems they are creating down the road. Mercedes certainly knows that. As the time and mileage add up, so does the likelihood that problems will occur with the onboard electronics and modules. Modules are certainly not bullet-proof, nor are the wiring connectors that tie them together on a CAN network, or the power and ground circuits that feed them voltage. Loose or corroded connections, shorts to open or ground, or quirky modules can cause intermittent problems that can drive anybody nuts. That’s potentially bad news for motorists who keep their new cars for more than a few years, and for the second and third owners who will eventually get stuck with all the repair bills. But it’s great news for our readers because it guarantees a steady influx of repair work as these late-model CAN cars age.
The assumption, of course, is that aftermarket techs will be able to access the OEM service literature and get the latest OEM scan tool software to diagnose and repair these vehicles. We are also assuming that replacement modules will be available. Many of the modules that are proliferating in vehicles today are “dealer only” parts, and may never be aftermarket parts because of limited volume or demand. Many OEMs also discontinue many parts once a vehicle is more than eight to 10 years old. Then where do you get parts if the parts aren’t available from a dealer or an aftermarket parts supplier? Some vehicles may be unfixable if replacement modules cannot be found at any price.
Can You Understand CAN?
I’ve been an automotive technical editor for almost 30 years, and my reaction when reading the OEM service literature about CAN systems is, “Who writes this stuff?” It’s unintelligible gobbledygook, probably written by some computer engineer who speaks English as a second language. It’s horrible, incomprehensible and of little value to the average technician.
If I’m trying to read up on a CAN system in a late-model vehicle, I want to see descriptive information written in plain English so I can understand how the system works. Once I understand it, hopefully I can diagnose it and fix it. But the OEMs aren’t making it easy for us.
Here’s an example of what I’m talking about. I copied the following paragraph verbatim about “Data Link Communications Description and Operation” for a 2007 Cadillac XLR from the General Motors service literature:
“The high speed GMLAN is a differential bus. The high speed GMLAN serial data bus (+) and high speed GMLAN serial data (-) are driven to opposite extremes from a rest or idle level. The idle level, which is approximately 2.5 volts, is considered a recessive transmitted data and is interpreted as a logic 1. Driving the lines to their extremes adds 1 volt to high speed GMLAN serial data bus (+) and subtracts 1 volt from high speed GMLAN serial data bus (-) wire. This dominant state is interpreted as a logic 0. GMLAN network management supports selective start up and is based on virtual networks. A virtual network is a collection of signals started in response to a vehicle event. The starting of a virtual network signifies that a particular aspect of the vehicle functionality has been requested. A virtual network is supported by virtual devices, which represent a collection of signals owned by a single physical device. So, any physical device can have one or more virtual devices. The signal supervision is the process of determining whether an expected signal is being received or not. Failsofting is the ability to substitute a signal with a default value or a default algorithm, in the absence of a valid signal. Some messages are also interpreted as a heartbeat of a virtual device. If such a signal is lost, the application will set a no communication code against the respective virtual device. This code is mapped on the Tech 2 screen as a code against the physical device. Note that the loss of serial data DTC does not normally represent a failure of the module that set it.”
Huh? If this is the language that GM uses to describe the operation of the CAN system on its Cadillac XLR, Heaven help the poor technicians who have not taken a GM training class and are trying to diagnose a CAN problem on a late-model GM vehicle.
The way a CAN system works is that each module is assigned a unique address number, just like house numbers on a street or telephone numbers in a telephone directory. It’s a three-digit number. On the 2007 GM Cadillac XLR, the engine control module is 017, the transmission control module is 024, the body control module is 064, and the electronic brake control module is 040. This is important to know because if one of these modules quits talking to the other modules, the onboard diagnostics will set a diagnostic trouble code (DTC) starting with the letters “U1,” followed by the three-digit code for the module that went silent. So if the malfunction indicator lamp (MIL) is on and your scan tool displays a DTC U1040, it would tell you there is a communication fault with the electronic brake control module. More on fault diagnosis in a minute.
Like most other vehicles with CAN networks, there are actually two separate CAN networks. The first is a really fast network for important stuff that requires real-time communication (engine and transmission control modules, cruise control module, electronic brake control module, electronic suspension control module, body control/airbag module and the OnStar communications interface module). The second is a slower network for less urgent functions (radio control module, power door lock and window modules, HVAC control module, power seat modules, power top module, instrument panel cluster, keyless entry system, etc.).
On the Cadillac, the fast CAN network is called the GMLAN network (General Motors Local Area Network), and the slower one is called the “Class 2” network. The faster GMLAN network operates at 500 kilobytes per second (Kbps), while the slower Class 2 network pokes along at 10.4 Kbps.
The two different CAN systems operate at different voltages (2.5 volts for the GMLAN network and 7 volts for the Class 2 network). As such, the two networks are separate and cannot talk directly to each other. So they are joined via the body control module, which acts as the “gateway” module for messages that have to be sent from one network to the other.
As stated earlier, CAN protocols define how messages are structured, how they are addressed and the priority assigned to some messages over others. Each module listens for messages addressed to itself, and it also monitors messages from all the other modules (nodes) on its network.
The modules send out a “node alive” message every two seconds. This is sort of a wake-up call that lets their neighbors know they are still alive and functioning. This is called “state of health” monitoring. If no node alive message is received from a particular module for five to 10 seconds, a DTC U1xxx communications error code is set where xxx corresponds to the three-digit identification code for the module that went silent.
NOTE: Here’s probably the most important point of this article. If you find a fault code for a particular module, keep in mind that “U” codes are communications error codes. The code does not necessarily mean the module has failed. The problem may be loss of power or ground to the module, an intermittent or open circuit in the network wiring connections to the module, or an internal problem in the module itself.
Also, DO NOT replace any modules until you have checked out the power, ground and network wiring connections to that module. If all the wiring connections are good, but the module is not communicating when it is sent a message by another module or your scan tool, or the module responds erratically or sends the wrong response, then you can assume the module is bad and it needs to be replaced.
Many of these modules cost hundreds of dollars, so make sure you have diagnosed the fault accurately before you replace any parts.
Use aerosol electronics cleaner to clean module wiring connectors. Don’t use any other type of cleaner. Cleaning the module connector will often clear up many intermittent problems that set communication error codes.
Using a Scan Tool
A simple code reader or basic scan tool that has the software to read “U” codes as well as “P” powertrain codes can give you the DTCs for most CAN communications errors. But it usually takes a factory scan tool or an aftermarket scan tool with OEM-equivalent software to interact with the CAN networks and to check the response of individual modules on these networks.
GM says when more than one loss-of-communication codes are set for one module or several modules in a CAN network, you should diagnose the codes in the following order:
1. Look at current codes before viewing history codes, unless the service literature tells you to do otherwise. Note: A history code will clear from memory when the ignition cycle counter reaches a certain number (usually 50) if the fault has not recurred.
2. Start with the code that is reported the most times.
3. Work from the lowest code number toward the highest code number.
Also, if the vehicle has any other codes (“P” or “B” codes), diagnose these first before proceeding with any “U” codes.
After repairs have been made, remember to clear all codes with your scan tool.
If there is a voltage problem on the network bus itself, you may find a DTC U0001 or U2100 in the history codes. On the Cadillac GMLAN network, there are two 120 ohm resistors at each end of the circuit, one inside the ECM and the other inside the body control module. When testing for a short between the two wires in the CAN network, a reading of 60 ohms is normal. A lower reading would indicate a short. If the reading between the GMLAN wires is 120 ohms, there is an open circuit.
GM says any of the following can cause a total loss of communication on the high-speed GMLAN network:
A short between the two GMLAN wires;
A short to ground or voltage anywhere in the GMLAN network;
A short or ground in any of the modules on the GMLAN
An open circuit in any of the GMLAN serial data circuits.
Let’s say you have a communications error code for the BCM module (U1064). This could mean the BCM module has failed, there is a wiring fault at the BCM connector, a short, open or voltage problem on the GMLAN or Class 2 networks, or one of the other modules on the GMLAN network has a problem that is affecting the BCM.
Start your diagnosis by turning the key on and checking the GMLAN serial data circuits for grounds, shorts and opens using a digital multimeter. Also make sure the base voltage is 2.5 volts.
If no faults are found, turn the key off, unplug the BCM connector, turn the key back on and check the BCM connector circuits for opens or grounds.
If no faults are found, turn the key off, reconnect the BCM and unplug one of the other modules that are on the GMLAN network (TCM, ECM, ESC, etc.). Plug in your scan tool, turn the key back on and attempt to communicate with the BCM. If the BCM is now communicating, there is a short or open in the other module you just disconnected that is causing a communications problem on the network. Replace that module, not the BCM.
If there is no change (still no communication with the BCM module), repeat this same procedure for each of the other modules on the network. If the BCM starts talking after unplugging a module, the fault is in the other module.
If there is no change after unplugging all of the other modules one-by-one, and no wiring faults were found, you’ve confirmed a bad BCM that needs to be replaced.
Yes, it takes time to do all of these checks, and it might be faster just to assume the BCM is probably bad and replace it. But imagine what your customer will be thinking if you replace their BCM for several hundred dollars and it doesn’t solve the problem? Spend the diagnostic time up front. Pinpoint the fault without a doubt, then you won’t have to do the job over again later.