1997 F-Body Tools

[In-Tech]

Hiya Tom,
GM is wonderful on async, especially the old stuff. Always logical. Intentional clock jitter was what I was eluding to, as you know it is kinda like encryption without a routine. Back in the early 2000's 64 bit was the edge, The TMS370(6805 variant) had some cool perif variables at the time. I introduced 5024 to a homeland bud. Anyway, off track.
Bottom line is it all boils down to one register once you are inside.

I love your work, Tom. I enjoy, so if I can help, I will :)
I'm still an old gearhead at heart, finishing a 430" LS and dyno soon so we can make the offroad vegas to reno race in August.

[Tom H]

Hi,

I am posting some software today that was written to give upload access to the FLASH in early OBDII LT1 PCMs. The software is setup to drive the Home Brew Cable (HBC). Details of this cable and how to build it are given earlier in this thread. Uploading code was something that GM had intention of supporting only in the factory. I suggest this because the TSide has no mode $35. The ESide has mode $35 but is accessible only through the SPI bus. There is no standard way to access the SPI through class II commands.... So a ram based module was needed to support upload access. The code is not fast, uses only X1 mode. Upload of the complete PCM takes about ten minutes for the complete TSide flash (both banks) and the Eside flash. I think this is fast enough given that it will be done only a few times.

I wrote the module based roughly on the SAE standards for mode $35 (See J2190 for details). One difference with the regular GM scheme that I introduced into the code is the use of the upper address bits to indicate bank. Banking on the TSide was used by GM to increase code size from 57,344 ($E000) to 90,112 ($E000 + $8000).

To use this App...

The windows app posted here first initializes the PCM. Car needs to be "key on" not running and of course not moving. Be sure the battery is charged and so on. With the HBC connected to the computer's USB and to the car's OBDII connector, start the software. Here is a screen shot:

Screen1.jpg

Using windows device manager, determine which COM port you are using and set it. Click Initialize Upload and the program will install the mode $35 module in TSide ram. A little out of order on my screen, the next step is to enter the PCM's password/security key. There are a good number of posts on this list to help find your key if you don't already have it. Click the initialization key. Once the software has initialized (progress is reported in the
output window on right screen) you will be ready to start your upload. Once loaded, the PCM is placed in a mode where it only supports mode $35. If for any reason you need to start the car, I recommend disconnecting the battery BEFORE trying to restart the car. It might work with just "key off" "key on" but the ram will be scrambled and could cause issues. I did not ensure to overwrite the tags that cause cold restart so best is battery disconnect/reconnect. See second screen shot:

Screen2.jpg

Select one of the three target spaces (TSide bank 0, TSide bank 1, ESide). This select which of the code spaces you will upload. Select the address to start upload from and the length of the upload. Please note that the ESide uses the GM coded mode $35. This code restricts access to ram below $2000 and flash above $2000. Other techniques must be used to upload things like the EEPROM from the ESide. Once the necessary selections are made, click Begin Upload. See screen shot 3

Screen3.jpg

At this point the selected storage has been uploaded to the PC in an array. All that remains is to output into a file in a format that is of use. The provided selections allow storage in three formats. SRecords is the default. This is of use with IDA or other tools. The most common format is binary. Binary file can be saved using a fill option. This will offset the download by the amount of the starting address. With this most common format, (example)the $2000th byte in the file represents the upload from address $2000. The offset option will be little ?never? used. It enters binary from the start address into the file starting at the first byte.

If anyone needs the source to port to a different cable, please just ask.

If you use this, please reply to this thread and let me know how it works for you.


-Tom

[Tom H]

Once again I have been distracted from a current goal of analyzing the knock sensor system. I will
get back to that, but first here are the details of the VSS system. A good deal of this may be common
knowledge but I thought to write up what I have done. This exposes more of the internal workings of TPU
(Circa 1997) which is key to understanding this PCM.
-----------

Starting at the beginning, here are a few details I used to work out the VSS function. These are specific
to my calibration/configuration.

17 PULSES/DRIVESHAFT REVOLUTION (NUMBER OF TEETH ON THE VSS RELUCTOR)
3.42 REAR GEAR RATO (GU6)
58.14 PULSES/TIRE ROTATIONS
504 TIRE ROTATIONS/KM (P245/50ZR16)
811 TIRE ROTATIONS/MILE (P245/50ZR16)
28372.32 PULSES/KM
45660.82 PULSES/MILE

Note that wheel rotations per mile/KM differ depending on tire manufacturer. The numbers I have here are
based on the constants in my calibration and are confirmed to be in the ballpark from available tire data.

I needed a way to generate VSS pulses on the bench to allow me to look into VSS processing. In my case it
was an easy call to use an Arduino Nano to generate VSS. They are inexpensive at about $5 and I have a
bunch of them around. I wrote some crude code to drive different frequencies and or exact
number of pulses. This helped greatly with the investigation. It permitted me to generate pulses of a
fixed count, pulses of a fixed rate/frequency or stop the pulses.

There are a couple of schematics attached to this post. The PCM VSS input is set up such that it requires
a negative going pulse (below ground) to trigger it. It doesn't need much... half a volt or so will be fine.
For more detail look at the VSS_Interface.jpg schematic. Since the switch point for the circuit is just
below ground some conversion of 5V logic signals is necessary. Digital signals from 5V logic can be set to
trigger the VSS with just a couple of common components. I used a small capacitor (0.1 - 0.5uf) to block
dc and a small signal diode (perhaps 1N914 or any small signal diode) to create the level shift. This
interface has been well tested and is reliable. In cases where someone wants to tune transmission
calibrations, more sophisticated software will be needed to drive VSS, RPM, MAP, TPS and perhaps a bunch
of other things. Perhaps some time I will investigate the automatic transmission, but later.

In case someone want's to duplicate this setup, I have included a schematic for the basic interface. Code
is available on request (I will comment it a bit and give it a clean before passing it on). The code is
however quite crude and you might be better off generating your own. The second schematic is of the VSS
interface to the TPU. This is the standard LT1 interface that was used in the $EE style PCMs.

Initial setup generated the following fixed rates. The second column is the PCM's reported speed. Second
setup changed the interface to let the user enter a numeric speed to be output.

VSS input PCM
Frequency Speed
Hz KPH
1953 242
977 121
651 81
488 61
391 49
326 41
279 35
244 31
217 27
195 25
178 23
163 21
150 19
140 18
130 17

To query the PCM I used a bunch of things that have been described elsewhere: Homebrew cable and
CarCom software. The sequence used to read speed in KPH from the PCM is: 4C 10 F0 22 00 0D 01 <CRC>

OK, so far the physical connection between the road and the PCM is described. From here things get
a bit more complicated, I will do my best to describe what is going on in the TPU. Before doing this
everything I write here is from observations of the operation. I have not yet found how to dump the
internal programming of the TPU so what follows is only 99.9% solid.

VSS is connected to the TPU on pin 6.

The PCM transfers data bidirectionally between ESide and TSide on the SPI bus. This bus runs across
the ribbon cable that connects the boards. The PCI bus transfers are formatted such that 32 bytes
are sent (I generally condider this to be a frame). The transfers from ESide to TSide also have a
subframe that is of no consequence to this topic, just mention it to avoid confusion. In each frame
bytes 5 through 8 contain vehicle speed data.

Bytes 5:6 represent elapse time of the VSS pulses
Bytes 7:8 represent the number of VSS pulses since the last read

During this transfer ESide reads an elapse time and pulse count, then sends it across to TSide. The
sequence used ensures that the count and elapse time are always paired. To ensure this paring the
following was done:

- Each time the VSS pulse count is read, the elapse time count is latched inside the TPU. Software
then reads the time count within a few cycles.
(Guess is 48 EClock cycles. This makes sure the elapse time is for the count given)
- The elapse time count is updated each time a VSS pulse is seen.
- The register for elapse time is updated on pulses from the second VSS pulse on.

This ensures that if the car stops part way through, the time is not skewed with the count. Basically
the counter and timer designs ensure synchronization between the two. The pulse count representing
distance and the elapse time is just that...time. That gives us what we need to calculate speed.

The ESide code for this sequence looks like this:

8A04 ldaa word_14E0 ; TIO SHARED RAM
8A07 ldd word_14E0
8A0A std <byte_009A ; BYTE 5/6 TX SPI

8A0C ldaa word_14E2 ; TIO SHARED RAM
8A0F ldd word_14E2
8A12 std <byte_009C ; BYTE 7/8 TX SPI




-------------

7CCC ldd VEHICLE_SPEED_M ; SPEED IN MPH
7CCF ldx #$9FA7 ; MPH X 2^16 / 40871
7CD2 fdiv ; OR 1.6035
7CD3 xgdx
7CD4 addd #$0080 ; ROUND UP INTO ACCA
7CD7 sbca #$00
7CD9 staa VEHICLE_SPEED_K ; SPEED IN KPH: 0 TO 255 KPH


... ( 242kph * 40871 ) / 2^16 = 151



Nano_VSS_IF.jpg

VSS_Interface.jpg


If you would like the software for the "speed generator" , please just request and I will post it.

-Tom

[kur4o]

Vss always have been a dark matter, due to only some constants visible to cpu code. That brings it much in detailed explanation how it works.

I think some constants are passed to tpu in initial reset of pcm. So tpu must be in some way configurable, how it reads speed.

Anyway, Tom great write up. Thanks

[Tom H]

Hi,

From what I see in my code, the TPU parameters do not seem to be adjusted between auto/manual or any other issues. I believe the differences are all in the TSide calibration parameters. I don't have a complete understanding of TPU however and I do see parameters marked (not sure who/why??) as relating to speed transfered from the [ESide config to the TPU] configuration section. Looking at the code however, I can see all the calculations to find Trans Output Shaft (TOS) RPM, filter it, find vehicle speed from gear ratio/tire size and convert the speed to KPH as required by OBDII.

As I understand it, one basic difference between manual and auto trans is that the number of pulses generated per rev of the driveshaft. I believe that the automatic generates 40 pulses where the manual generates 17 (manual is confirmed). I don't have automatic code and am not sure where on this site I could find it. I had a quick look and didn't see much support for the OBDII generation of PCMs. Perhaps someone could send me a pointer...

In a disassembly I was given, the calibration has a named parameter "TOS_Driveshaft_PPR" which I decode to mean "TRANSMISSION OUTPUT SHAFT PULSES PER REVOLUTION". This name seems almost correct but: The config constant becomes the denominator in a FDIV instruction with a value of $4888. Pushing through all the math I believe this constant is as follows:

("TRANS OUTPUT SHAFT PULSES PER REVOLUTION" / "NUMBER OF SECONDS IN A MINUTE) X 2^16

IN NUMBERS

(17 / 60) * 65536 = 18,568 OR $4888 (This is the constant in my code)


Missing from my earlier post is that the VSS_CLOCK used to quantify the input VSS frequency is EClock/48. The sequence on the ESide is to latch the count on the edge of VSS. The count continues, incrementing each 48 EClocks. Notice that EClock/48 is 2^16 or 65,536. Given this, driveshaft RPM can easily be calculated for a given VSS input frequency.

Why was it done this way? My guess is that they re-used automatic transmission code from earlier PCM/TCM and didn't want to mess with what was already working and tested. The way the parameters for TOS are packaged in a structure is quite different to the manner most of the code is written. This makes me think it might be earlier code...

The result of the TSide routine is 8 X Trans Output Shaft RPM. It can be found with PID 1942 using the standard mode $22 request. In my case: 4C 10 F0 22 19 42 01 <CRC>

I will include a couple of assembly code files, commented with what I think I know. If anyone would like the spreadsheet to calculate TOS from VSS input (manual trans only for now), just ask.

-Tom

[Tom H]

Hi,

As I understand it, one basic difference between manual and auto trans is that the number of pulses generated per rev of the driveshaft. I believe that the automatic generates 40 pulses where the manual generates 17 (manual is confirmed). I don't have automatic code and am not sure where on this site I could find it. I had a quick look and didn't see much support for the OBDII generation of PCMs. Perhaps someone could send me a pointer...

In a disassembly I was given, the calibration has a named parameter "TOS_Driveshaft_PPR" which I decode to mean "TRANSMISSION OUTPUT SHAFT PULSES PER REVOLUTION". This name seems almost correct but: The config constant becomes the denominator in a FDIV instruction with a value of $4888. Pushing through all the math I believe this constant is as follows:

("TRANS OUTPUT SHAFT PULSES PER REVOLUTION" / "NUMBER OF SECONDS IN A MINUTE) X 2^16

IN NUMBERS

(17 / 60) * 65536 = 18,568 OR $4888 (This is the constant in my code)

-Tom

I had a better look at this site for automatic code. In the OBDII tune section I found TunerCat ".CAL" files for the automatic. Not knowing anything about this tool or the cal file it works with, I got out my binary edit tool to take a look. Knowing that the FLASH on the TSide bank 0 has a range from $2000 through $FFFF and that bank 1 has a range of $8000 through $FFFF tells me that the TSide needs $16000bytes to represent the flash. Similarly, the ESide has a range of $2000 through $FFFF for a size of $E000. Total .CAL file needs for all the flash is $24000 bytes or 147,456 in decimal. Problem for me was the file had a size of 148,480 bytes. The difference in expected vs. real file size is 1,024 bytes. First guess was that there was some sort of header...
Viewing the file showed a bunch of hex values followed by a VIN for someone's car. Light went on as I realized that the first 1k bytes were the content of EEPROM for the car used to extract the .CAL file from.
My best guess at the format is:

$200 bytes TSide EEPROM
$200 bytes ESide EEPROM
$E000 bytes TSide FLASH bank 0
$8000 bytes TSide FLASH bank 1
$E000 bytes ESide FLASH (no banking on ESide)

Total $24400 bytes or 148,480 decimal

Using my hex editor I found an exact match in the code section with my PCM. Of course the calibration will be different because this is an automatic. I then wrote code to extract the sections into their component parts. I wanted to confirm the conversion of the TPM output for output shaft/driveshaft RPM that I posted earlier.

Looking at the conversion value in the TSide bank 0 at $2B83 for both the manual and automatic code I found:

Manual: $4888
Automatic: $AAAB

The PCM code uses the FDIV instruction so the result is:

(17 / 60) * 65536 = 18,568 OR $4888 (This is the constant in the manual code)
(40 / 60) * 65536 = 43,691 OR $AAAB (This is the constant in the automatic code)

So the calc for driveshaft RPM is confirmed for both transmissions. This was a way too long route to find the answer, but at least I got there.

As a foot note, I know nothing about the TunerCat tool. The code I wrote is good only for LT1 for sure because of the strange multi-processor arrangement. The code could be re-used if someone wants to parse different .CAL files, but would need modifications to the C code. If anyone wants this code, just PM me and I will post it.

-Tom

[Tom H]

Hi,

I am working on a more modern tool to upload and flash the 1997 PCM. Does this interface look like what you would expect for an upload/program tool? I have little experience with Win32 and all it's controls, messages and voodoo but waded through it to make what I think would be an OK interface. This is just a shell at the moment, so far it does nothing except process inputs. Here is a screen shot of the main window and all it's controls. For ease of understanding I have removed all the options for Srecords and just plan to produce a binary ".bin" file.
I am interested in opinions if there is anything missed or improvements you think of.

-Tom