1997 F-Body Tools

**In-Tech** · 06-21-2022

Hiya Tom H and kur40,
You actually want to measure clock and use that as a "standard" in your comm protocol, this way the ticks can be accurate in digital micro land ;). I'll try to dig up an example from yeeeeeeearssss ago, am just throwing out ideas for y'all for now :) latency and each particular circuits latency will always exist. Here we have a known proven structure so it should get narrowed down fairly quick. You can always use flip/flop(7407 style) to help "clean" the signal in your interface comm device. The old 160/8192 non standard crapola seemed like a biatch at the beginning too. Throw in some clock jitter with an unknown protocol and you can imagine the kinda crap i had to sift and figure out back in the day. You guys are well on your way :) It still and always will boil down to 8 bit ;)

**Tom H** · 06-21-2022

Originally Posted by In-Tech

Hiya Tom H and kur40,
You actually want to measure clock and use that as a "standard" in your comm protocol, this way the ticks can be accurate in digital micro land ;). I'll try to dig up an example from yeeeeeeearssss ago, am just throwing out ideas for y'all for now :) latency and each particular circuits latency will always exist. Here we have a known proven structure so it should get narrowed down fairly quick. You can always use flip/flop(7407 style) to help "clean" the signal in your interface comm device. The old 160/8192 non standard crapola seemed like a biatch at the beginning too. Throw in some clock jitter with an unknown protocol and you can imagine the kinda crap i had to sift and figure out back in the day. You guys are well on your way :) It still and always will boil down to 8 bit ;)

Hi Carl,
Not sure I understand all you wrote. All this stuff is async. PCM has it's own ceramic resonator for the 4MHZ the DLC wants. HBC micro has it's own 16MHZ clock and of course there is the PCM's 12.whatever crystal. In places where it was easy, I put buffers to handle instant overspeed. Other places I depend on the rate being in excess of the bandwidth and buffer excess. Clock jitter is every where along with line jitter and all the errors my cheap and dirty interface introduces.

So far, my testing of the 10K4 seems OK. I have used the same code to download into ram & read back w no faults.

re calcs for clock, these are based on min/max specs. Going 4x will probably require me to change the interface, which is a PIA.

Cheers,
-Tom

**In-Tech** · 06-21-2022

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** · 10-07-2022

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** · 06-22-2023

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** · 06-22-2023

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** · 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.

**kur4o** · 12-07-2023

You need to consider how that files will be tuned. The best format for tuning and creating definitions, regarding offsets will be to stack 3 complete 0-ffff bins, and upon flashing to extract what you need.
1 file fits all will be much preferred than split type of pattern.

That is why we need to carefully consider the final format of file, since the process of flashing will include and editing. Making definition files with messed offset will be real nightmare, while keeping the 3 bin stacked will line perfectly with disassembly and all relative addressing will be just +10000 and +20000.

**Tom H** · 12-08-2023

In thinking about how the file will be edited, your suggestion now makes sense. Three blocks of 64K, initialized to $FF and overwritten with the FLASH content. Perhaps a checksum or CRC at the file end.

Implications to the front end read/program are that there is no need to identify padding or code spaces. Probably just needs serial setup, password, and two buttons one for read other for program. Makes the controls 100% easier.

I will put together the revised controls and post.

-Tom