Early GM Class 2 Programming Woes…
I posted this on our Trainedbytechs.com Blog, it is an excerpt from a book I am writing, it outlines my thoughts on the cause of the issue. Please, feel free to add your method for success, or comment with experiences below. And most importantly, correct any misinformation I have written. Thanks again!
Have you ever attempted a programming event on an early 2000’s GM truck or van with a J2534 device? If so chances are you have had a failure or two. This is not uncommon, and it can be a stressful experience, but it’s not the end of the world.
The early GM class 2 network (SAE J1850 VPW) that I am speaking about today is nearly exclusive to the truck chassis vehicles produced before 2004. This network consisted of a power-train control module (PCM) and body control module (BCM) that provides the 7 volt bias required to run the network, along with the other modules specified by the chassis. And unlike most of today’s CAN systems, there are no terminating resistors in the network to aid in a network circuit integrity test. Instead, there is a single hub of all the single network wires usually referenced as splice number SP205 on a wiring diagram. This splice is often referred to as a comb because of the obvious resemblance to one.
This comb is usually located in the lower under dash area on the driver’s side. This single wire communication design has a fatal flaw of being significantly slower than almost every other communication network type of this era. Nearly every J2534 device created communicates and pushes data at a much faster rate than this network was designed for. These new devices were built to meet the Society of Automotive Engineers standard SAE J2534-1 API so they can keep up with the high speed controller area network (HSCAN) architecture in use under the SAE J2534 protocol.
Without getting deep into the technical information, a brief description of the SAE J2534 protocol was to create a standard for a single device that acts as a mediator for which programming can pass through from a PC to the module being programmed. This led to the J2534’s other most commonly referred to moniker, a pass-thru device. This SAE J2534 device, if it meets the standards outlined, should successfully mediate the programming of any emissions related module on the following communication protocols outlined in the aforementioned SAE article: ISO9141, ISO14230 aka (KWP2000), J1850, CAN (ISO11898), ISO15765, SAE J2610, and J1939.
This difference in communication speed of networks and the J2534 device cause conflicts where data and communication corruption happens causing a programming failure. In an alarming number of cases, the faults occur around the time the communication protocol structure is being written to the module. This in turn makes the module a non-communicating device and can render it a rather expensive brick! So how do we prevent this failure? Can the process still be completed with a J2534 device? If I brick a module, can it be saved?
The most successful method I have used is to pull the network comb, find the pin for the module that needs flashing, and jumper that pin directly to the DLC pin in the comb. This will remove the other modules from the network and prevent any network traffic collisions and communication speed issues. This also serves as a diagnostic method if you have a module bringing network communication down. You can simply pull the comb to remove all the modules from the network and add them back on one at a time. Monitoring communication via scan tool or oscilloscope determines what module would require further diagnosis to isolate the network fault.
Now I recommend that this flash NOT be carried out with a J2534 device, but instead with the General Motors original equipment diagnostic tool, the Vetronix/Bosch Tech2. It would need to be carried out in the remote programming mode of the Tech2, this allows the flash calibration file to be downloaded to the Tech2’s memory card directly from the General Motors network via a PC with internet connection and the service programming application (SPS), from that point the Tech2 is disconnected from the PC and then reconnected to the vehicle, and a process is carried out in the tool to program the module with the downloaded file. Using the OE method allows the transfer of the calibration file to happen with a tool that matches the baud, or communication speed, that is matched to the vehicles network, as it was designed for this network specifically, and the network would be absent any modules besides those required to complete the flash programming event. And using this method of programming will usually bring a module back to life that has failed a programming event, even if it has lost communication.
Keep in mind, if the PCM or BCM is not the module you are trying to flash, you will need to connect one of them back to the network as well as the module needing to be programmed. As stated earlier, those two modules provide the 7 volt bias needed to power the entire network. As for using the J2534 device to carry this procedure out, well…. the Drewtech branded and rebranded devices, such as the Snap-On Pass-Thru Pro, AEZ Flasher, and newer generation Launch J2534, just to name a few, have a debugging mode built into the toolbox software suite that that Drewtech provides with the tool. This software allows the communication of the device to be slowed down to allow for a higher rate of success with these networks. Although I have heard of more success stories than failures with this method, I am inclined to urge you to the side of caution and use the OE tool and procedure.
I love it Keith! Thank you for taking the time to write this document and share it.
Hi Bryan. I'd like to add some information to your post if I may. Many of the observations that you alluded to in your post were common knowledge back when Class 2 was introduced to all GM vehicles around 1996 and by Y2K were prevalent issues for diagnosticians with associated UXXX DTCs. This of course was long before the "one size fits all J2534 device" was developed and marketed and
Martin, thanks for the write up... I almost finished off my first cup of tea reading it. This brings to mind, back in about 20001, I had bought my first Tech 2, and in came a 1994 Chevy pickup with 6.4 power. I was so proud of that vehicle and my scan tool. The problem was an intermittent stall and I thought I had found the problem, which I didn't and I sent you an email pleading for
Hi Albin. Fancy meeting you here! I remember that post! That's the instructor in me hoping to empower long term learning and system understanding, rather than blurting out answers for a single application. BTW, once you folks get through the border on the 25th, give us a call and I'll get dinner going.
Wow, I just logged into the new Network and I am already impressed with the level of knowledge and discussion. It's just like the early days of iatn. I thanked Keith for this post and now with your additional information I would like to thank you also. I have only been doing module programming for the last 10-15 years so I don't have a lot of knowledge on the early systems. I may need to
Hi Bob. It's been way too many years since I programmed one of those old Corvettes! We were a Chev, Olds, Cadillac dealership, so we got a mix of 'vettes in with a larger dose of Cadillacs. It is easy enough to isolate the PCM communication at the Splice Pack (Star Connector), which I recall Star Connector # 1 was connected to the PCM. FWIW, we used to have a rotary tool for diagnosis J42236…
Happy New Year Martin. Yup, most vehicles around here are pre-CAN, be they GM, Ford, Chrysler, you name it. Most are pre-CAN. Certainly appreciate you taking the time to talk about your "ancient history" knowledge and experience (as always).
Oops, sorry I meant Keith!
No Problem Martin!
This is exactly the type of response I had hoped for, I want to thank you Martin for adding to my information, I love learning the in's and out's of each systems architecture and design. This is the style of learning that has hindered so many in our industry, they look for the answer without even understanding the problem. With a solid understanding of the system you can devise your own test
Well this is timely information. I may need to program a replacement ECM in a 1995 Vette for another shop. I did plan on using Tech2 remote but was wondering if you still recommend disconnecting all other modules on the bus? I've never programmed anything this old but I have been told that the other modules on the bus may try to talk and interrupt the programming process. Thanks for posting
The dreaded … Trailblazer. We have long chased after this issue. Here's what I know: - We have seen this work over J2534, and generally it has gotten better with later revisions to TIS2WEB, but can still be problematic. But our call volume on this has significantly dropped. - When we had a failure with a CarDAQ, we would also be able to replate the same failure with an MDI/MDI2. All
Hi Brian. We always used the Tech 2 remote programming method back then in the GM dealership, although beyond August 2003 I was no longer working in the service bays. Tech 2 pass through was the next evolution of programming prior to J2534 box introduction. From recall, before programming lift gate fuse # 6 had to be removed on the Trailblazer/Envoy model and it was noted in TIS. Otherwise
To add some color to Brian's comments, having worked at Vetronix on this project the issues mentioned above are not really related to J2534 but to select ECUs that have sketchy communication software internally. There have been tens of thousands of ECUs programmed using J2534 on J1850VPW with no issues. The main offenders are early 2000s light duty trucks (C/K, S/T), whereby the ECU cannot
Thank you Bob! I'm sure you can tell some of my information was based off of conversations you and I had in the past. Glad you are here, I know you will provide a lot of useful information to the network and the industry!