1997 F-Body Tools

**Tom H** · 06-30-2023

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** · 07-14-2023

Originally Posted by 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** · 12-06-2023

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

**kur4o** · 12-06-2023

Looks great, maybe add read button, and some progress dialog or simple log window.

I think we need to specify bin format, used for reading tuning and flashing.
This seems the easiest from tune point. All offsets will be correct and easier to create definition file
eside 0-ffff, ,tside 0-ffff, tside 32kb bank2.

**Tom H** · 12-07-2023

Originally Posted by kur4o

Looks great, maybe add read button, and some progress dialog or simple log window.

Are you suggesting that the button captioned "Upload" be changed to "Read" ? I will change that.
Progress dialog is a great idea. I will add that. Earlier tool had a monitor of the traffic on the bus. That had no meaning I guess.

Originally Posted by kur4o

I think we need to specify bin format, used for reading tuning and flashing.
This seems the easiest from tune point. All offsets will be correct and easier to create definition file
eside 0-ffff, ,tside 0-ffff, tside 32kb bank2.

There are several formats in use for binary. For myself, I like to use the SRecord but that's not supported by any of the tools. Most binaries I have seen are formatted this way:

Code:

TSide
 $0000 -  $1FFF    Padded with $FF. This is the area of ram, peripherals, registers and so on
 $2000 -  $FFFF    Calibration, code, vectors: Bank 0
$10000 - $17FFF  Padded with $FF. This area holds same as Bank 0
$18000 - $1FFFF  Code, vectors: Bank 1

ESide
 $0000 -  $1FFF    Padded with $FF. This is the area of ram, peripherals, registers and so on
 $2000 -  $FFFF    Calibration, code, vectors. Note: No banking here

There are some (like the .cal files) that eliminate the padding. Probably others I don't know about also. I need to be sure that when programming is requested, the entire binary is programmed. Fail on this and the result is a brick. To that end, I set the default when TSide or ESide is selected to be the whole FLASH. When you do "Upload" (now "Read") the interface permits you to download as little as you like. For example you might be interested in the EEPROM and want to Read that. This front end permits that.
I think that some folks would like to use all the good tools available for OBDI in later cars. I know of no reason that say 1995 software couldn't be loaded on to the 1997 computer. If someone wanted to try this, setting bank 1 lengths to zero and programming just the lower 64K will permit this.

If I understand your suggestion, you would like to see the padding for Tside Bank 1 eliminated. This is easily done with the interface I have by setting Bank 1 padding to zero. As this all gets debugged, I could change the default when TSide is selected to this.

If you like, I can send you a working version of the controls part of the project. I would be interested in further comments and/or suggestions on coding. So far all I have integrated is the serial port.

-Tom

PS: Wonder if anyone has a bricked PCM they could send me. Looking for a 16242921 or perhaps a 16214399 (not as good) to bring this project to life. Needs to be suffering a software issue which I can fix. Trouble finding them locally.

**kur4o** · 12-07-2023

0000-1fff can be read too, it is actual ram so is accessed, no need to pad it.

If we move tside part at the end of actual file, there is no need for bank1 padding since it don`t contain any tuning parameters, but we may also leave it, so it is easier for patching. that way all offsets will be correct with the addition of only +10000 +20000 +30000 offset. So we can keep the padding. The file will increase in size but it doesn`t matter since only partial data will be read and written.

With current layout
tside bank0 0-ffff
tside bank1 10000-1FFFF
and eside 20000-2FFFF

The writing will be pretty straightforward
2000-FFFF
18000-1FFFF
22000-2FFFF.

You can also develop some mini bins that contains only vectors and communication loop, that will be written first, so in case the communication is dropped it can be recovered.
The pcm running from mini bin only. Something like a boot mode cutout bin.

On earlier pcm we managed to cut the bin to that parts only, not sure how well will work on later style.

Some bin verification will be needed too. We don`t want someone flash the wrong bin. Some basic checksum and identifiers for bin integrity.

**Tom H** · 12-07-2023

While there is no need to pad it, the ram is overwritten by my code to support programming and ESide access. I will maintain padding such that if the file were used to program a part, the first $2000 locations will contain the erased state of the FLASH ($FF). Both TSide bank 0 and ESide need this padding. If you were programming on a standard programmer a blank part, the first $8000 of TSide bank 1 should be handled the same way.

I plan for a TSide file and an ESide file, each starting at $0. If the plan were to have a single file (like the .CAL files) Tside bank 0 would take up 56K, bank 1 32k and Eside 56K:

File
$0000 - $DFFF TSide bank 0
$E000 - $15FFF TSide bank 1
$16000 - $23FFF ESide

So that's a total of 144K which is all the FLASH space that is used. I will mull this over but I lean to having the two files, formatted such that if they were burned on a DataIO machine the bytes would land in the correct place.

Regarding flashing the wrong bin, I don't know how to stop that other than looking at the gm number for the code and forcing a match. Even if this were done there would need to be a bypass to allow someone to program code for a '95 into a '96/7. Can't think why that should be prevented.