Working through the code int the '97 LT1, at some point you are going need a good understanding of OBDII. I do not claim to have all the answers, but this is my starting point. I spent a career designing data comm hardware, so it is natural for me to look at the system through the OSI (Open System Interconnect) model.
Layer SAE standard Covers
--------------------------------------------------------------------
Layer 1 Physical layer J1850 Bits, voltages, time
J1962 Connector
Layer 2 Data link layer J1850 Header, symbols
J2178
Layer 3 Network layer
Layer 4 Transport layer
Layer 5 Session layer
Layer 6 Presentation layer
Layer 7 Application layer J1978 Messages, filtering, response
J2190
For the most part, folks interested in tuning need not concern with physical details. They are covered by the Data Link Controller (DLC) which is a 68HC58 in this PCM and the connector, connector pin out and so on are all standardized by the GM design. If you want details of the DLC electrical interface, I posted a schematic with most of the details earlier. Just a very few details are of interest here working with the software. The DLC MC68HC58 IC marked 20686 is clocked with a 4.0MHZ ceramic resonator. This will help make sense of some of the initialization code. The DLC is interfaced in parallel mode and uses two locations $1060 and $1061. These locations are multiplexed to provide all the required access. A quick web search will turn up the data sheet you will need if you want to investigate bit level use of this chip.
In this post I won't dwell much on the setup of the DLC, other than to point out that the DLC is polled not interrupt driven. The '97 PCM provides for an interrupt capability, but this is not used in production code. The production code services the Data Link Controller (DLC) interrupts with code that just turns off the interrupt.
Skipping over the electrical and bus level details brings us to software, specifically how PCM code interacts with the DLC. The code detailed here is specific to just a few years/models but may be of interest to folks looking at later code. If nothing else, details of the type of concerns that the coders had could be of interest. I found many examples where the code is checking to ensure the vehicle is not moving or that the engine is not turning (even if it is off).
In my case, I began by messing around with an ELM327 based connection to my PC over USB. I was happy with this until it was uncovered that:
- GM uses a 4X mode at times that ELM327 does not support
- The ELM327 forces a request/response operation
- The ELM327 forces adherence to the J1850 standard and does not permit long frames
- Getting a driver to use this module is a PIA, I made it work but...
There are probably other shortcomings as well. I was not able to find a way to easily download the PCM using this module. If your goal is to debug a problem you *might* get away with one of these cheap units however if your goal is to tune there exist cables and software that permit this. As always you get what you pay for.
The OBDII code in most modes has a request/response format. That is to say, info (or action) is requested and a single response frame is generated. There are some requests however that have multiple responses. An example of this is a request for freeze frame data. A request for freeze frame data will result in 23 or 138 frames of data. A warning to anyone still using an ELM327 type interface... depending on timer settings, most or all of these frames will be lost. It is just beyond the capabilities of that device. I coded my own interface using an Arduino Nano to be sure that all the details were understood, but many good interface cables exist. I have not tried them, so there are no suggestions or recommendations here.
For the most part just a few standards control the details of interest to tuners. J1979 spec sets up functional communications while J2190 spec sets up the physical communications. In '97 there is only one device communicating with the tester equipment. This makes the difference between physical and functional frames quite small. J2178 discusses the differences, but for my purpose I will just discuss what has been done on this PCM and leave other analysis to those with that interest.
OK, so that's all the lead in/boiler plate/intro stuff out of the way. Let's focus on the different commands that testers can issue to find details of problems and/or tune. As mentioned in the previous paragraph there are two comms modes used: functional and physical. We will start with the functional as set out in J1979
Headers
-------
There are two headers of interest to us. Skipping through all the details of various J1850 headers that can be supported to focus on those that are supported. GM uses a three byte consolidated header. Upper three bits are priority which are don't care on a bus with only two devices. In-frame responses are not used. For my purpose here I will use one of three headers:
Functional: $48 $6A $F0
Physical TSide: $4C $10 $F0
Physical ESide: $4C $18 $F0
Functional modes
----------------
The '97 PCM supports functional modes 1 through 7 defined in the standard:
MODE $01, REQUEST CURRENT POWERTRAIN DIAGNOSTIC DATA
MODE $02, REQUEST POWERTRAIN FREEZE FRAME DATA
MODE $03, REQUEST POWERTRAIN DIAGNOSTIC TROUBLE CODES
MODE $04, REQUEST CLEAR/RESET DIAGNOSTIC TROUBLE CODES
MODE $05, REQUEST OXYGEN SENSOR MONITORING TEST RESULTS
MODE $06, REQUEST ONBOARD MONITORING TEST RESULTS
MODE $07, REQUEST PENDING TROUBLE CODES
Mode $01
--------
This mode requests current powertrain diagnostic data and uses a functional header. The format used is:
$48 $6A $F0 $01 <Truncated_PID>
The truncated pid is any pid in which the first two digits are 00. This means that all PIDs that are not within the first 256 can not use this mode. The higher value PIDs are accessed using other modes and physical addressing. Those are detailed here later. PIDs that can be used with this mode are:
Tru Result
PID
--- ------
$00 SUPPORTED PID $01 - $20, BIT MAP FLASH CONST $BFBFF990
$01 NUMBER OF EMISSION-RELATED TROUBLE CODES AND MIL STATUS
$03 FUEL SYSTEM STATUS:
$04 ROUTINE:CALCULATED LOAD VALUE: 0% TO 100%
$05 ENGINE COOLANT TEMPERATURE: -40C TO 215C
$06 LEFT SHORT TERM FUEL TRIM: -100% (LEAN) TO 99.22% (RICH)
$07 LEFT LONG TERM FUEL TRIM: -100% (LEAN) TO 99.22% (RICH)
$08 RIGHT SHORT TERM FUEL TRIM: -100% (LEAN) TO 99.22% (RICH)
$09 RIGHT LONG TERM FUEL TRIM: -100% (LEAN) TO 99.22% (RICH)
$0B MANIFOLD ABSOLUTE PRESSURE: 0KPA TO 255KPA
$0C ENGINE RPM HIGH RES (RPM X 4): 0 TO 16383.75 RPM
$0D SPEED IN KPH: 0 TO 255 KPH
$0E ROUTINE: IGNITION TIMING: -64 TO +63.5 DEGREES
$0F INTAKE AIR TEMPERATURE: -40C TO 215C
$10 MASS AIR FLOW: G/SEC: 0GM/S TO 655.35GM/S
$11 THROTTLE POSITION SENSOR: 0% TO 100%
$12 COMMANDED SECOND AIR
$13 O2 SENSOR CONFIGURATION: $33 = 2 SENSORS/BANK
$14 O2 B1S1 VOLTAGE: 0 TO 1 VOLT: SHORT TERM FUEL TRIM
$15 O2 B1S2 VOLTAGE: 0 TO 1 VOLT: $FF
$18 O2 B2S1 VOLTAGE: 0 TO 1 VOLT: SHORT TERM FUEL TRIM
$19 O2 B2S2 VOLTAGE: 0 TO 1 VOLT: $FF
$1C OBD II TYPE: $01
Here are some examples from my bench PCM
\B 48 6A F0 01 00 59 \E Request: SUPPORTED PID $01 - $20
\B 48 6B 10 41 00 BF BF F9 90 B5 \E
\B 48 6A F0 01 03 7E \E Request: FUEL SYSTEM STATUS
\B 48 6B 10 41 03 01 01 84 \E
\B 48 6A F0 01 05 30 \E Request: ENGINE COOLANT TEMPERATURE
\B 48 6B 10 41 05 00 90 \E
The response header: echos the priority of the request, targets the functional response, sources from the TSide. The response data has variable width depending on the PID requested.
Mode $02
--------
This mode requests powertrain freeze frame data and use a functional header. The format used is:
$48 $6A $F0 $02 <PID> <Frame_number>
PIDs $00 and $01 are supported.
This PCM responds only to frame number $00.
Here are some examples from my bench PCM
\B 48 6A F0 02 00 00 9C \E Request: Supported pid
\B 48 6B 10 42 00 00 7F B9 80 00 DC \E
\B 48 6A F0 02 02 00 04 \E
\B 48 6B 10 42 02 00 00 00 89 \E Request: PID that caused the freeze (in this case none)
Supported PIDs are bit mapped: Starting from the MSB of the first data (7F in this case), moving from MSB through LSB, support is as follows:
Supported are PID
A 02, 03, 04, 05, 06, 07, 08,
B 09, 0B, 0C, 0D, 10,
C 11,
D
Mode $03
--------
This mode requests emission related powertrain diagnostic trouble codes
On my work bench I forced TPS out of range and requested mode 3:
\B 48 6A F0 03 CB \E
\B 48 6B 10 43 01 22 00 00 00 00 E3 \E
The response here is P0122 which is: P0122 THROTTLE POSITION SENSOR CIRCUIT LOW VOLTAGE
Mode $04
--------
This mode requests clearing of DTCs, freeze data, and other on board testing results.
On my bench:
\B 48 6A F0 04 98 \E Request to clear all
\B 48 6B 10 44 52 \E
In my case, the TPS fault will still show up because it is registered with the system right when it happens.
Mode $05
--------
This mode requests results of O2 monitoring.
Inputs to mode $05 are test_id (TID) and O2_sensor number (O2).
Valid test IDs are:
TID $00 SUPPORTED TIDs $01 THRU $20
TID $01 RICH TO LEAN SENSOR THRESHOLD VOLTAGE
TID $02 LEAN TO RICH SENSOR THRESHOLD VOLTAGE
TID $03 LOW VOLTAGE USED TO CALCULATE PASSAGE TIME
TID $04 HIGH VOLTATE USED TO CALCULATE PASSAGE TIME
TID $05 RICH TO LEAN CALCULATE PASSAGE TIME
TID $06 LEAN TO RICH CALCULATE PASSAGE TIME
TID $20 SUPPORTED TIDs $21 THRU $40
TID $40 SUPPORTED TIDs $41 THRU $60
TID $60 SUPPORTED TIDs $61 THRU $80
TID $70 O2 SENSOR WITH LESS THAN 255 COUNTS
TID $71 O2 SENSOR WITH LESS THAN 255 COUNTS
Valid O2 sensor numbers are:
O2 $01 O2 SENSOR BANK 1 SENSOR 1
O2 $02 O2 SENSOR BANK 1 SENSOR 2
O2 $10 O2 SENSOR BANK 2 SENSOR 1
O2 $20 O2 SENSOR BANK 2 SENSOR 2
"Supported TIDs: are done just like mode $02: First data to last data, MSB to LSB.
At the time I did this, there are no O2 sensor simulators connected. Here is just a sample of invalid results.
\B 48 6A F0 05 01 10 97 \E Request for results of O2 test: RICH TO LEAN SENSOR THRESHOLD VOLTAGE, Bank2 Sensor1
\B 48 6B 10 45 01 10 00 2C \E
Of interest here is that no testing for sensor 2 is supported. There are tests in the physical section for issues relating to the second O2.
Mode $06
--------
This mode requests on-board monitoring test results for non-continuously monitored systems. The '97 LT1 supports this list of TIDs:
"Supported TIDs: are done just like mode $02: First data to last data, MSB to LSB. Not sure what the FF indicates but it is in the standard as a constant. Why (??) probably never know.
TID $00 TIDs supported (range 01h to 20h)
TID $03 SECONDARY AIR INJECTION REACTION SYSTEM MONITOR
TID $04 CATALYST EFFICIENCY STEADY STATE MONITOR
TID $06 O2 SENSOR HEATER SYSTEM TIME TO ACTIVITY MONITOR
TID $07 EXHAUST GAS RECIRCULATION SYSTEM MONITOR
\B 48 6A F0 06 00 A0 \E Request supported TIDs
\B 48 6B 10 46 00 FF 36 00 00 00 6D \E
\B 48 6A F0 06 03 87 \E Request secondary air results
\B 48 6B 10 46 03 01 00 00 FF FF A1 \E
\B 48 6B 10 46 03 02 00 00 FF FF 1F \E
\B 48 6A F0 06 04 D4 \E Request cat efficiency results
\B 48 6B 10 46 04 20 80 00 02 00 ED \E
\B 48 6B 10 46 04 30 80 00 02 00 03 \E
\B 48 6A F0 06 06 EE \E Request O2 heater time to activity results
\B 48 6B 10 46 06 35 00 00 00 00 FD \E
\B 48 6B 10 46 06 41 00 00 00 00 F8 \E
\B 48 6B 10 46 06 55 00 00 00 00 A3 \E
\B 48 6B 10 46 06 61 00 00 00 00 39 \E
\B 48 6A F0 06 07 F3 \E Request EGR results
\B 48 6B 10 46 07 0C 00 00 00 00 89 \E
\B 48 6B 10 46 07 0D 00 00 00 00 E3 \E
I need to go through and detail the results here. GM published a paper on Mode $05 that gives us what we need to accomplish this along with J1979
Mode $07
--------
This mode requests on-board monitoring test results for continuously monitored systems. These are all the DTCs normally issued as fault codes.
Test examples from my bench setup:
\B 48 6A F0 07 BF \E
\B 48 6B 10 47 01 22 00 00 00 00 8A \E
The 01 22 indicates that my TPS sensor is disconnected.
That was quite a bit of decoding to get all this figured and written down. Sad part is that the physical is much more complicated. I hope to get this done in Sept (?)
-Tom
Reply With Quote
Originally Posted by NomakeWan
Bookmarks