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 independent facilities outside of dealerships were introduced to the ability and option to program vehicle systems. Most of this is now a walk down "memory lane", but could be useful.
I'll include some observations and experiences from the dealership service bay perspective and a little about the diagnostic aspects and challenges that Class 2 may pose.
Given that this is now an aging protocol that gave way in GM terms to single wire LS GM LAN, it is worth the discussion for those previously not tackling network diagnostics. An old article from GM Techlink e-zine, "De-Mystifying Class 2", may be of interest. norcal-cobras.com/GTM/gm-tech-li….pdf
The J1850 protocol explained citeseerx.ist.psu.edu/viewdoc/downlo…
The GM Class 2 network was widely used in all GM passenger vehicles from 1996 and connected at the DLC terminal # 2 for single wire (or in some models if required was assigned dual wire connection at terminals at DLC # 2 and # 10). The baud rate by design was 10.4Kbits/sec for data transmission and up to 40Kbits/sec during programming events. Class 2 continued in use beyond the introduction to mandated adoption of HS CAN for 2008, until some models so equipped, were replaced with new platforms.
Both loop and star design Class 2 networks were utilized, depending on vehicle platform, with passenger cars more often utilizing the loop, while trucks and utilities used the star network. There were a few variants that used a combination of both.
As far as the network basics, system functionality is based on a 0 volts rest (passive) and an (active) signal voltage toggling to a nominal 7 volts. Measuring voltage with a Fluke 87 on 1 millisecond peak min max might net 6.25 volts, while a Fluke 87 V will show ~7 volts and DSO as high as 7.25 volts.
Class 2 limitations, were quickly discovered to be the number of nodes. With a maximum bus length of 35 metres of conductor and a maximum of 32 devices and a maximum scan tool cable length of 5 metres, the limitations most notably put the network to the test when vehicles were heavily optioned, close to the maximum node count. Vehicles with only a handful of modules didn't often exhibit communication DTCs unless there was an actual system failure.
Frequently, UXXX communication codes were present on a vehicle that was operating normally, in part because the network was very sensitive to voltage dropping during cranking or with a partially charged battery. Any extended cranking typically resulted in communication DTCs that were little more than "ghosts", not worth chasing and that were rectified with restoration of correct system voltage, or other system diagnosis and repairs concluded. An example might be a vehicle with a fuel pump issue, where extended cranking and an eventual start was the situation and UXXX DTCs were common.
As far as programming, as mentioned Class 2 was designed long before the J2534 devices in current use and remote programming was the most commonly used practice of the day when the system was current. Off board, remote and pass-through with Tech 2 were utilized, depending on the system. Within TIS2Web or TIS2000 as it was known back then. There were often foot notes in the SPS selection screens identifying whether modules required complete isolation, or specific systems to be shut down to allow programming events to be completed successfully. Memorable examples were the Trailblazer/Envoy S/T platform requiring lift gate fuse # 6 to be removed and Cadillac requiring PCM to be isolated for programming on some models.
The issues with programming tended to arise from modules waking up unexpectedly during programming. While it is natural to consider cycling the ignition during a programming failure, that should be avoided and the programming event re-attempted, followed by a call to TAC if still unsuccessful.
By design in normal operation, Class 2 nodes wake up at key on and send State Of Health (SOH) messages at ~2 second intervals, since they are essentially inactive until required. Essentially message scheduling was either periodic or send on change, for example when a door was opened. If any node did not send a SOH message, the modules that it normally connected with flagged DTCs for the missing module, much like the "buddy" system, where someone doesn't show up for work and its somebody else's job to take attendance.
The nodes on a Class 2 system basically allow for transmission of data when they have something to say, beyond the SOH (I'm alive) message. Data transmissions typically take ~5 milliseconds to transmit, but the issue is that none of the nodes know when to speak, much like when people start talking at the same time. To avoid message "collisions", each node depending on its function, is assigned a message priority identifier, with 000 = 0 the highest and safety related. In order of priority 001 = 1, 010 = 2, 011 = 3, 100 = 4, 101 = 5, 110 = 6 and 111 = 7, with the latter being convenience related.
As far as splice packs, they are typically located approximately 5" - 8" from the DLC, with DLC terminal # 2 usually being a purple wire to the splice pack(s). SP203 and SP205 were commonly used, since some systems utilized two splice packs, due to the higher number of modules. Beyond the splice pack, the bus wiring was whatever the designer chose. For loop type Class 2 networks the conductors connect all nodes together, so there are two network wires at each module connector. The DLC is simply connected into the loop in parallel.
Since there were no splice packs on most loop Class 2 networks, it was necessary to identify connectors to be disconnected and subsequently observe whether communication was restored. A single open in a loop network could still result in communication, since data can be transmitted around the loop in the other direction.
Diagnosis of star networks begins as it does for any typical system. The customer concern is verified and in the case of no communication issues, physical inspection and basic measurements at the DLC and easily accessible modules is usual. Verification of the battery condition and SOC should always be a an early inspection when diagnosing any network issues.
Some basic measurements at the DLC terminal # 2 will quickly identify whether the bus is active with signal voltages toggling from rest passive ~ 0 volts to active ~ 7 volts. As previously mentioned, the technician may choose whichever diagnostic tool produces the required results. All Class 2 modules require battery voltage, ground, data bus integrity and the 0-7 volts signal voltage.
It is not so much necessary at least initially, to determine the accuracy of the signal voltage measurement, but whether the network shows any activity, or is shorted to ground or shorted to voltage. A Fluke 87 V records at 250 µ seconds, (4x faster than the 87 or 87 III it replaced) is quite capable of providing a useful enough measurement, without the immediate need to resort to using a DSO, other than for those who must analyze the data transmission more deeply.
With an open circuit from a node, the network will usually be unaffected, except for the missing node and associated DTCs flagged by nodes that it communicates with, while a shorted module or bus will shut down the entire network. Where CAN Bus can flag a useful DTC useful for diagnostics, Class 2 may also set a relevant DTC, but it will not be accessible via the scan tool, until after the issue has been corrected.
As far as programming, it is definitely best to utilize the prescribed method and tooling. GM vehicles prior to 2004 model year (Malibu) mostly did not utilize any CAN Bus diagnostics. The Duramax engine control system had CAN in 2001, but there was no communication with any scan tool at the technician level, only CAN communication between the FICM and the ECM. So, while technicians have been used to dragging around a Tech 2 with a CANdi module connected, the CANdi is a bit of an anchor weight and unnecessary prior to 2004 MY GM vehicles. It was designed purely to allow the Tech 2 to function and be utilized as a CAN bus interface.
Tech2Win. In my opinion, an unreliable old program at best, that was first used in classes as an interface when training technicians on the Tech 2. The Tech 2 Emulator program merely allowed students at the classroom PCs to all operate a Tech 2 interface. Dragged out and "dusted" off a few years ago by Hewlett Packard, re-named Tech2Win and combined with the GM MDI, it allows for interrogation of some GM vehicle systems. It is somewhat a "hit and miss" affair at best, but can prove useful as long as the user is aware of limitations and exclusions. However, if the user is not aware of what should be available via the scan tool, they may miss accessing such information that could be useful and that may be readily available via the Tech 2 hand-held scan tool.
Tech2Win was not intended to be used for programming and it was clearly stated in GM publications, along with a list of vehicles for which it was not a suitable option. So, user beware. When released, we experienced notable issues that were reported to HP for consideration. Some were addressed and some, it appears not. So, the Tech 2 is the tool of choice over Tech2Win, but since far fewer Class 2 network equipped vehicles tend to cross GM dealership thresholds these days, non-functioning Tech 2s tend not to be replaced if Tech2Win will suffice.
You provided sage advice in regards to using the intended SPS tools on aging platforms utilizing Class 2 systems and that is sound. It was old news already for GM dealership technicians by MY 2000, that modules may need to be isolated for successful programming and there are many pretty well documented cases where programming has been unsuccessful due to not following procedures, not having stable battery voltages during SPS events and more. Not reading and following instructions properly is a common theme that should not be overlooked when programming events are unsuccessful.
Given that Class 2 is such an old network by current standards, many younger or less experienced technicians may not have been around when Class 2 J1850 was current. I won't go into E & C Bus, UART, SBI and older Keyword protocols, but there are still vehicles around in daily operation with those systems alive and well, that function at a "snail pace" compared to when Class 2 was introduced.
As far as the many years that I spent solely in the GM dealership environment from 1980, there was only a relatively small "handful" of unsuccessful programming events experienced throughout the shop, when using the specified equipment. For the most part, remote programming with the Tech 2 was extremely reliable and usually successful.
However, many technicians struggled with Class 2 network diagnostics back in the day, while CAN bus diagnostics are much overall more straightforward to grasp. To that end, when training GM apprentices in network diagnostics, we do still cover Class 2 systems and while we may have vehicles with various faults on CAN Bus, MOST, LIN, CGI and Ethernet examples, to challenge the students a vehicle with a Class 2 network fault installed is ready to provide exposure to Class 2 diagnostics.
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 information. To that email, you sent me one back, with 18 pages of information, and not one place did you even allude to what the problem was. You wrote about how the system worked, what it took to make the system work and some stuff about where to test. Needless to say, I was a little frustrated to say the least. So,,,,,,,,,,, I took the information and read it over a few times,
Back at the shop, I was able to apply the aforementioned information to my problem, and walla, I came up with not only what the problem was, but how to test for the problem. Needless to say, I found out the 6.5 GM diesel engine controls were quite simple. And, thanks for the information, both then and now!!!
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 program a replacement ecu in a 1995 Corvette LT1. I would definitely use Tech2 remote but would I also need to isolate the ECM? I read service information and it didn't mention the need to do this but others have told me it may be necessary. What say you?
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, with the comb removed and the tool installed we could isolate a faulty network branch.
Usually, TIS called out any special instructions requiring isolation of a module, but it wouldn't hurt to go that route.
Most of the programming at that time was still being completed through the old CAMs machine and Tech 1, both which now seem a lifetime away, although I do still have a couple of Tech 1s around.
A quick check shows Bulletins 53-65-04, 53-65-05 and 53-65-08 dealt with the basics of programming back then.
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 plan, and determine in an efficient manner the cause of a problem.
Thank you Albin as well for reinforcing this method, I look forward to all of your future post!
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 this Keith.
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 Pass-thru devices suffer from this.
- The only hope is to NOT TURN OFF the key when this happens and keep trying. Ignore the software messages telling you to key on or key off. As soon as a flash fails on a GM Class 2 module (J1850) and you turn the key off it's usually toast because you have erased the bootoader, an important part of old GM ECU's that tells it how to power up when the key is on
- In some cases the only way to do this successfully is with an actual Tech2
- We have analyzed this many times, and believe the problem with programming the 03-04 trailblazer lied not with J2534 or the J1850 protocol, but in how the flashing software was ported from Tech2 to PassThru. It could probably be addressed by re-writing the programming routine in TIS2WEB but it's now a 14 year old vehicle, outside of any CARB/EPA/R2R legislation.
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 programming was not an issue using the preferred OEM method and equipment.
I periodically hear of technicians programming using Tech2Win and MDI. However, Tech2Win was not recommended for programming. It was and is still far too glitchy to be considered reliable.
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 accept the transition to high-speed comm mode (usually at the 3-4% event timeframe).
I have personally sent log files to GM Engineering over the years and the response is normally the same, namely the PCM throws up when it can't accept high-speed data.
Just to clarify some statements above: The Tech2 was designed by Vetronix in the early 1990s. HP was awarded the hardware contract in 1995, spun it off to Agilent in 1997, then Vetronix bought the rights back in 1999 when HP wanted out of the diagnostics business. Tech2Win was a project by GM Europe that was never really "officially" a project and as-such has some limitations (no SPS Remote Programming, limited UART support, etc)