Have you ever noticed how time itself seems to have a large influence on one’s misfortune? What I mean is, it seems as if the probability of something unusual happening is directly and inversely proportional to the amount of free time you’ve allowed for a particular task. The less free time, the more likely something will go wrong. In addition, the severity of complications has the same inverse relationship to time. The less free time, the worse the complication becomes. Can you relate?
One of Murphy’s Laws says, “If something can go wrong, it will, and at the wrong time.” It seems like no matter what you do to prevent anything from going wrong, something still goes wrong. If whatever it is that goes wrong happens while you’re attempting to program an Electronic Control Unit (ECU), then it’s entirely possible you won’t be very happy either. I’ll outline in this article the procedures I follow before, during and after programming, most of which are done to prevent something from going wrong in the process. I’ll also present one technique I use to remedy the situation(s) when things do go awry.
Only a few strands remained intact on the PCM ignition feed wire.
In addition to being a technical article contributor, I also am a mobile automotive diagnostic technician; one who travels from shop to shop helping them diagnose problem vehicles. I have a service area that is larger than the state of Rhode Island, therefore it is very important for me to diagnose efficiently. I’d better be well organized in order to fulfill my promises, because I might have many shops scheduled to visit in one day.
Don’t you have similar needs (excluding travelling, that is)? Don’t you have to diagnose vehicle problems efficiently in order to fulfill the rest of your scheduled jobs? The problem is we can’t always know how long it will take to determine the cause of a customer’s complaint ahead of time. Coining a phrase that my buddy Sam might say, “We don’t know what we don’t know,” so we can’t always accurately estimate how long it will take to come to the conclusion of what’s causing the problem.
In all cases there is a certain amount of work that should be done to determine the causes of the previously unknown culprit (some call them gremlins). I ask my customers to do as much of the diagnostics they can themselves, whatever they are comfortable with, before enlisting my services. I prefer to not be the one actually diagnosing a vehicle, so in most cases I’ll work with my customers (mostly the technicians) over the phone to help them confirm their findings prior to lending a physical presence if it’s needed. Sometimes they aren’t familiar with the vehicle or the system they’re working on. Sometimes they lack the confidence in their tools or in their own abilities or sometimes they just want to “bounce something off” another person who may have a different perspective.
With the inner fender removed for service, the harness support was lost and the broken wiring strands were no longer contacting one another, leaving just the few to carry the current load.
I define diagnostics as the process of elimination. We verify what’s working correctly and eliminate those as causes of what’s not right. Some diagnostic routines used to include the statement “install a known-good part.” Most professional technicians and shop owners have found the “part substitution” method of diagnostics just doesn’t work these days and even might cause more problems than the vehicle originally came in with. Also, it’s gotten expensive condemning a part in modern vehicles.
Some of the expense can be calculated in non-billable labor hours because installing parts to see if the problem’s solved might be wasted time. Therefore, one must be sure a replacement part will solve the problem before ordering it. In addition, part substitution is not what I call diagnosing; it’s guessing.
Reflash First or Last?
If it’s determined that a reflash (or a module replacement that also requires programming) is in order, then we are at the point where we have eliminated all other possibilities of the cause. In other words, I use programming as a last resort instead of a “try it first and see if it fixes anything” choice. Part of my reasoning is the unknown. For example, we don’t have X-ray microscopic vision. Therefore we can’t say that there is not a pre-existing condition inside a module. We cannot say beforehand that there isn’t a bad solder joint, a faulty electronic component, poor connection, etc. inside there.
We found the same problem developing on another truck. Can you say pattern failure?
With any of these module faults Old Murphy, the author of those laws, could rear his ugly head and use them against you. Also, pertaining to the vehicle, we can’t say there isn’t a bad wire somewhere, a poor connection, etc. Those conditions might not have been evident before, but might become so when programming takes place. So when programming a module, I try to be prepared for the worst case scenario – the failed programming event.
Worst case scenario, I’d sure hate to have deal with a failed programming event and replace a module, only to find out it didn’t fix the customer complaint. That’s a whole lot of money and time spent needlessly, time that could have been used more productively (read: profitably) instead. Isn’t prematurely programming a module – that is, doing so before eliminating all other potential causes of a customer’s complaint – sort of like the part substitution method of diagnostics?
To prevent something (besides the unknown) from causing such a thing from happening, I routinely go through important steps that I’ll describe later in this article. If I do experience a failed programming event after taking all the proper precautions, I know I’ve done everything in my power to prevent it from happening and it was just meant to be.
With the inner fender removed, the signs of harness contact were easy to see.
Hedging Your Bets
My experience as an automotive diagnostics specialist has taught me, among other things, to allow plenty of time when I’m called upon to program modules. In addition to the time spent eliminating all other causes of a problem, there is a lot of what I call preparation time, or time that’s invested before I’ll even get to the programming and post-programming steps.
I prepare the vehicle for programming by first performing visual inspections, then by checking the whole electrical system, then by scanning the vehicle’s computer systems and lastly by ensuring no outside interference will influence the results. This last precaution is done by remaining vigilant and observant while programming takes place so no one interferes with the vehicle, electrical cords, etc.
During my visual inspection checks, I look for anything that might interrupt communications while programming. I might look underhood, in the vehicle and maybe even underneath the vehicle, depending on the system requiring programming. In the engine compartment I look for evidence of creative engineering, like additional electrical components or wiring not originally included by the manufacturer, aftermarket anti-theft devices, labels indicating certain self-proclaimed performance enhancing devices have been installed and so on.
In the vehicle, I peek under the dash to see if non-OE devices are installed (like telematics transmitters, tracking devices, insurance company recorders and the like). I also look around to see if any aftermarket audio or video components have been installed (stereos, back-up cameras, DVD players for example,). Under the vehicle I look for damaged wiring, aftermarket trailer lighting and electric braking harnesses, modifications and anything else that isn’t factory. If all my visual inspections don’t indicate anything to be concerned about, I move on to the electrical system inspection.
Inner fender partially installed. You can see how the skirt supports the weight of the harness.
Included in the electrical system inspection are battery load and conductance tests (on all batteries if applicable); both tests are required because neither one provides 100 percent of the information needed regarding the battery(ies) health and state of charge. I won’t program any module unless I see no problems at all revealed with these tests.
Because I know what the battery voltage reads, now is a good time to see what the ignition voltage reads at the module connector too, just in case I neglected to view that Parameter Identifier (PID) in the data list. It helps to have an accurate wiring diagram and connector pin-out for this test. Once I’m confident there are no concerns about voltage supplies or grounds I’ll proceed to the actual programming of the module.
It should be noted that most of the time I’m called in to assist another shop with a failed programming event of their own, I find the cause to be a low voltage condition; not necessarily a low battery, but a low system voltage condition. There are many reasons why the Electronic Control Unit’s (ECU’s) battery or ignition-fed voltage might be less than required during programming. Depending on the vehicle design, there may be many connectors, switches, and/or relays, where a voltage drop may occur before reaching the ECU’s connector. We must be absolutely sure what the system voltage is before, and during, the programming event.
.bmp?auto=format,compress&fit=max&q=45&w=250&width=250 "undefined")
With the harness supported, there was just enough electrical contact to allow the truck to run and the scan tool to communicate. Perfect example of the importance of voltage drop testing.
If the measured battery voltage is low at the ECU, the first step I do is verify that the battery connections are clean and tight. I mean all battery connections, not just the multiple battery vehicles either. I also inspect those remote junctions where battery positive cables are attached to a stud where other wiring gets their positive voltage feeds. These have to be clean and tight as well. Once the same voltage is read at the battery and at the ECU, then I will proceed to verify ground integrity(ies) of that module. There are many tools available today which can load those circuits safely, and once those tests are successful I move on to the next step.
I cannot stress enough the importance of monitoring system voltage(s) while programming. Even after we tested everything before programming, we must monitor this during the process as well. Just like checking the static battery charge and watching how much it changes when cranking, modules aren’t using the same amperage with the key on and the engine off as they draw when operating or when they’re being programmed.
Lessons Learned in the Real World
Not too long ago, a very knowledgeable, well-trained technician who is an experienced reprogrammer called me regarding a programming issue he was dealing with. He follows the pre-programming instructions I mentioned every time he flashes modules. He’s experienced some problems in the past while reprogramming modules, as everyone does eventually, and learned lessons from them all. However, he had never encountered the error messages he was receiving while trying to perform an update to the Powertrain Control Module (PCM) of a 2004 GMC bucket truck.
The truck had been driven there, was in for other service work and the flash was supposed to address one of the driver complaints. Of course, by the time he called me, the allotted amount of time promised to the customer had run out.
This module should program very similarly to one in a lighter vehicle with some minor exceptions, but in this case, the process stopped part way through and at seemingly random steps on subsequent attempts, delivering differing error codes each time. The technician exhausted all his knowledge resources before calling on me (and even tried installing a different PCM with the same results).
During his call to me, I had him perform some tests including ones on his programming interface (Tech 2), all of which passed successfully. Once I was confident he wasn’t dealing with a tester issue, I asked him for the Vehicle Identification Number (VIN) and researched the OE service information (SI) for known programming anomalies. According to GM SI, there was nothing out of the ordinary that had to be done in order to program this module. Everything mentioned was straight-forward; the job should have been a slam dunk, but Old Murphy was in the house. When I felt he’d answered as many questions as I could muster and he was still unable to successfully program that PCM, we agreed I should go to his shop and take over the perplexing diagnosis of the failed programming event.
We tried everything we could to solve this truck’s problem prior to my arrival at the shop.
Without any disrespect intended, I always confirm other technicians’ test results. The reason I do is because not everyone tests things the same way. For example, when obtaining a voltage reading, one might use a dash ground. I prefer to use the battery negative post. The two readings may differ greatly. Besides, on more than one occasion, I have come up with completely opposite results in person than what I was told over the phone, which usually will require a different diagnostic path to be followed. I won’t get into the reasons why differing test results might be gotten by two different people in this article. In this case though, all of my test results were identical to the technician’s results.
To be sure we were not dealing with a tool issue, we initially used my equipment instead of the shop’s tools, but the results were the same. Partway through the process the programming would stop, it would allow two more attempts, then cease with an error message. This confirmed we had a vehicle issue and not a PC, tool or cabling issue.
My instincts told me I’d better monitor the voltages at the PCM (as I mentioned earlier). I used a four-channel oscilloscope instead of a Digital Multimeter (DMM) because I could view numerous circuits at the same time. That method is less time consuming than testing circuits individually (and will show momentary drop-outs where a DMM might average those into the displayed voltage). Sure enough, on the next attempted flash I lost my ignition feed to the module. None of the other monitored circuits changed when this happened.
You might ask why I only lost the ignition voltage only at a certain time during the flash process. You might wonder how come I could still read data and the engine could still run if I lost ignition voltage? What would be your next step, knowing what you know now? How valuable would an accurate wiring diagram become if you were presented with this problem?
It was through a process of elimination that I isolated the circuit fault to a small area between the fuse protecting the circuit and the PCM connector. Looking at the pictures of the looped harness and the wire that was damaged, and then picturing the vehicle in a road-worthy state, one can answer almost all the previous questions. The right inner fender is installed when the vehicle is not being serviced, and it was pushing up on the harness, ultimately wearing through the ignition feed wiring to the PCM connector. Just a strand or two were intact — and barely at that — until the harness was allowed to hang freely (it had no support once the inner fender was removed for servicing). When the vehicle was fully assembled, there was enough current flowing through the wire to enable normal PCM operation but not enough current could pass to the module once the strands were only touching their ends.
Imagine what the customer was told when the PCM update was sold, then imagine what the customer had to be told once Old Murphy reared his ugly head. Also, imagine the scheduling nightmare that was created throughout the whole shop once this job that was expected to take less than an hour took an exorbitant amount of time. Remember the proportions of free time to degree of complication mentioned earlier?
Did the tech expect the problems he experienced that were caused by preparing the vehicle for service? Would you have? I’ve learned there is no set time for programming modules, and I tell my customers this up front. Prepare them — and yourself — for the unknown and for the unexpected ahead of time. If you allow ample time, the likelihood it will be needed is greatly reduced. Call that Jaime’s Law.
Subscribe to Motor Age and receive articles like this every month…absolutely free. Click here
