Content brought to you by Motor Age. To subscribe, click here.
What You Will Learn:
• Communication issues can be caused by Nodes, bus circuit faults or even voltage/ground supplies
• Referencing topology diagrams is a great initial step before approaching the vehicle
• Using DTC to help triangulate the source of the fault will create a focal point for diagnostics.
Although I don’t spend near the amount of time in the shop as I used to, I’m always pleasantly eager to visit and offer a helping-hand to a fellow technician when a second set of eyes is requested. This subject vehicle is a 2007 Suzuki XL7 (Figure 1). It comes to us from a really good friend of mine, Susan Sweeney of Al’s Auto, located in Upper Darby, PA. Susan was faced with the challenge that we all face from time to time. She inherited this vehicle from another local shop, that was attempting to fix a driveability complaint. It left that shop (on the hook) with a “no-crank/no communication” situation.
Just the facts, please
I look at someone’s ability to be a diagnostician from a few perspectives. First and foremost, the ability to draw an accurate conclusion. I believe this to be most important, for obvious reasons. Getting there requires multiple skillsets. However, one of them is greatly under-utilized and I know this from speaking with hundreds of technicians across the world. It’s the art of interrogation.
As I was saying, being able to properly diagnose the fault is one thing, but to do so efficiently is another task entirely. We must consistently evaluate our performance on each job and ask ourselves how we could’ve been more efficient. Is there any additional information that could’ve been grabbed easily, before investing more time in a particular arena? Questions like that are key to improvement and to further polish your diagnostic approach.
There is another type of interrogation I’m referring to though. It’s the questions that must be directed toward the customer. In almost any situation, the customer knows a lot more about the nature of the fault or (more particularly) the conditions present, when the fault occurs. Unfortunately for both Susan and I, this interrogation was not possible.
What we would’ve liked to have known was the kinds of repair attempts that were carried out just before the vehicle lost communication. She would’ve simply focused her attention in that area and would’ve easily and efficiently solved the problem. This information would’ve likely saved us an hour’s time. All we knew was how the situation described above and that a donor PCM had been installed in attempt to fix the lack of communication. We don’t know if any testing was performed, or if it was a simple case of the technician emptying the parts cannon. Neither of us had the information we so desired.
From our initial conversation on the phone, Susan had told me that she could only establish communication with the BCM. Keep in mind, the aftermarket scan tool she was using might not have the same capabilities as another scan tool. Meaning, the lack of communication could be a lack of functionality with the scan tool itself and nothing wrong with the vehicle. This is likely not the case here because all scan tools must be able to communicate with the PCM on any car as mandated by the ODBII standards.
She then provided me with some screenshots from her scan tool, displaying some DTCs indicating a lack of communications (Figure 2). I referenced a wiring diagram pertaining to how this vehicle was networked (Figure 3). I had to re-draw it, so it was viewable. There is some very important information that has to be factored in when referencing a diagram like this. The reason is due to the different available options for any vehicle under multiple trim packages. Misidentifying the vehicle at this point could grossly shift your diagnostic approach in the wrong direction and enable you to inadvertently condemn some very expensive components.
For that reason, I chose to identify the vehicle by VIN. This factored in the options for this platform and at the same time, may have eliminated some clutter from the wiring diagram. This can make analysis much easier, when available. Realize, that not every wiring diagram is drawn in this fashion. Some include all the options on one diagram and have you sift through the ones that don’t apply as you are navigating the diagram. It can be quite overwhelming.
The communication-network diagram like the one being referenced here, provides us with "the lay of the land”. It lets us see all the players involved in each system. We need to know this because, at any given point in time, many tasks are being executed and depending on the “lay of the land” and the players involved, these tasks can be carried out differently.
Show me, don’t tell me
Let me share an example and explanation here to demonstrate what I’m stating:
The typical, classic horn control circuit has the driver (through the horn pad) provide the intent to sound the horn. This is carried out by he/she completing the path to ground for the controlled side of the horn relay. This enables the relay to function which provides the current to sound the grounded horn (Figure 4). In the end, all the driver knows is when the horn pad is depressed, the “BEEP-BEEPs” begin.
However, the same result occurs but in quite a different manner when we reference the horn circuit for a different vehicle. This horn circuit has a totally different “lay of the land,” along with many more players to accomplish the same goal (Figure 5). In this configuration, the horn switch once again provides the input of driver intent. However, rather than control the horn relay coil directly, the grounded horn pad only provides an input to the instrument cluster. The IPC than reaches out on the CAN_B data network to relay the message to the Front Control Module (located within the underhood fuse box). Once the message is received and processed, the Front Control Module directly controls the horn relay by providing the ground path. Again, the horn sounds, milliseconds after the horn pad is depressed. In the end, all the driver knows is the car “BEEP-BEEPs.”
So, as you can see, not having a lay of the land could have you off in the weeds as far as your diagnostic approach goes. This is a mistake many technicians still make. Never assume you know the system’s configuration, or the players involved. The engineers can structure them any way the wish.
The task to be tackled
So, back to our subject vehicle. According to the network diagram, this vehicle communicates on two different networks. One of which is a proprietary network called GM-LAN (Highlighted in GREEN). The scan tool accesses this network on terminal #1 of the DLC. I don’t seem to have any issues at all communicating with the nodes on this network. I can communicate just fine with them (Figure 6). Perhaps this was an issue with Susan’s scan tool of choice.
The second network is one which is required by law to be there. It is found at terminals #6 and #14 of the DLC and is known as High-Speed CAN. It is a 2-wire twisted pair network which is relatively fast. This is where all mission-critical communication takes place. Systems like ABS, SRS and Powertrain share messages here because these messages have to be processed almost instantly. More importantly, this is the network in which the fault has taken place. I cannot communicate with any other nodes on this network. In fact, the BCM is the gateway in this network. It serves as an interpreter between both communication networks and is the only one I can communicate with.
So, what have we learned so far?
- The GM-LAN network is functional and will not likely be our area of focus
- We can speak to the BCM on CAN_HI
- this tell us that the communication lines are not open/shorted to voltage/shorted to ground
- this tells us that the communication lines are not shorted to each other
- this tells us that a node (an ECU) is not shorted internally and pulling the network down
Think about the power in the statements listed above. This was derived simply by accessing a wiring diagram and using the scan tool to triangulate an area where a fault may exist. It means our next move in the diagnostic approach will be based off of what was deduced here.
Referencing the network diagram again shows how the DLC is connected to the CAN_HI network. Messages from the scan tool do not pass through the BCM to establish communication with the other nodes on the network. They splice off from common connectors (encircled in ORANGE, in Figure 3). That one observation takes the BCM off the list of potential faults. Had the circuit been of a pass-thru design (daisy chain configuration), the BCM could be a potential root cause of the communication fault.
We now have to figure out why three separate nodes lack communication. The diagram shows the EBCM and the TCM as a daisy chain configuration so if there were an open circuit internal to either, it would indeed cause the fault. Logic would have me test for communication (with a lab scope) at the EBCM or TCM, but both are buried beneath the battery (and I’m inherently lazy). The ECM is very accessible and if the communication network signal measured healthy at that location, it would certainly have to be healthy at the inaccessible EBCM and TCM (Figure 7).
Justified pinpointed testing
As mentioned above, the next logical test would be for proper communication signal at the ECM. Remember, we are dealing with multiple nodes lacking communication. It's assumed at this point that the network must be open. Testing was conducted using a simple lab scope with 2 channels. The signals were obtained by sampling from the back of the ECM connector terminals and were found to be quite healthy.
I recognize them as such because I took the time to familiarize myself with waveforms I will encounter quite often. Since CAN is here to stay, and applies to all OBD2 compliant vehicles after 2008, I’ve invested the time. When CAN_HI is at rest (or Recessive) it will ride at approximately 2.5v. When communication begins (dominant), the voltage will toggle between 2.5v and 3.5v.
Regarding CAN_LOW, it too will be recessive at 2.5v and will begin to toggle when dominant. It will toggle between 2.5v and 1.5v. This will happen at a rate up to about 500,000 times per second, and each waveform (HI and Low) will mirror each other. That is exactly what we are seeing here (Figure 8). So, let's step back and digest what we just discovered so we can maintain a logical approach and determine our next test:
- The available CAN activity at the ECM says the bus is healthy up to that point. ECM likely has a fault or reason for lack of communication.
- All nodes require four basic necessities to communicate on a heathy bus network:
- *Voltage supply
- *Ground supply
- *Ignition supply voltage (or wake-up signal)
- *Voltage reference circuit free from shorts-to-ground
- Without these four necessities, the node cannot be condemned.
- We will not pursue the communication faults with the other nodes at this time.
My hope is, if the fault causing the lack of ECM comm is located, it will lead us to the cause of the other nodes’ lack of communication as well.
The next logical step in the diagnostic process is to verify the PCM has what it needs to function and communicate on the network. If those four necessities can be verified, and connector pin fitment is acceptable, we can be confident that the PCM is “dead” and will then have to pursue the other nodes’ inability to communicate, as separate issues.
Focusing our sights
Again, I want to remind you that this approach is being carried out from a logical angle. It’s done so by studying the network configuration and using input from the scan tool to determine or triangulate the area of the fault. Focusing on the ECM and verifying the bus integrity to it, the PCM is either faulted internally or it can’t function because it lacks one of the four necessities listed above. Using a solid diagnostic approach saves time and avoids missed steps. This of course, will eliminate a misdiagnosis.
What I like to do to leave no stone unturned is to print out the views of each of the node’s connectors. In this case, the PCM has a 96-way connector as well as a 58-way connector. Once the diagram is printed, I highlight each of the pertinent terminals with an appropriate color:
- Battery-supply voltage (RED)
- Ignition-supply voltage (ORANGE)
- Ground-supply (GREEN)
- Reference-voltage (BLUE)
This keeps me from overstepping one of the test locations and reduces test time drastically. Rather than carry out the test with the connectors removed, I leave the circuits in their natural state and test from the backside of the connector. I do this (rather than a loaded voltage drop test) because it's testing how the circuit functions normally. If there isn’t enough supply available to allow the PCM to function, I will surely see it testing in this fashion, when the fault is present.
Referring to the ECM power distribution diagram, I anticipate seeing battery supply voltage on circuit #1540, as it is indicated to be "hot at all times". This was not present when testing was conducted. This led us to investigate how the battery supply voltage is supposed to get there — the ECM BATT fuse #33 of the underhood fuse block.
Testing showed voltage available on both sides of the fuse. So, voltage is available at the source but can’t find its way to the ECM. There is less than two feet of harness and none of it appears to be disturbed in any way. What I mean by that is I don’t see a reason to assume an open wire due to a damaged harness. My next course of action will be to inspect for an open in the fuse box or a spread/damaged terminal at the underside of the fuse box, connector C1/Terminal #31.
Upon removal of the underhood fuse box, two of the three connectors simply fell out into my hands. They were not properly secured. There are connector position assurance latches that didn’t have the proper fitment and would not allow for proper terminal mating. Upon proper installation, not only did the PCM reestablish communication, but so did the rest of the nodes on the vehicle. It seems one root-fault took multiple nodes off the network.
Slow and steady wins the race
Tackling faults like this isn’t rocket science. In fact, it’s quite easy. All it takes is an understanding of how the vehicle network is configured using the wiring diagram, a capable scan tool to indicate which nodes lack communication, and a logical approach. Analyses like this one are truly developed at the workbench and away from the vehicle.
When we approach the vehicle, its simply to ask some questions and get some answers. Those answers (along with the logic we acquire over our career’s experience) will naturally lead us to the next test. These network issues are not a fluke; they occur quite often. With more and more features implemented into today’s vehicles, its only logical to understand that more data will be shared over these networks through these virtual systems. Develop a logical game plan and see it through. Techniques like the ones shared above will increase your productivity, polish your reputation as a problem-solver…but most-importantly, boost your confidence as a diagnostician.
