1997 F-Body ECM

**In-Tech** · 02-29-2020

I think I read earlier about having a hard time reading some areas. It's been a very long time since I played with any of this stuff so forgive the intrusion. Here is an old "no rom call" dumper, kinda a bit bang approach and not exactly what you are doing but I am hoping the example might give you an idea of things when you are hunting in the blind. If not, I'll go back to my corner, lol :)
-Carl

Code:

0001 0000			;This area is not normally commented out and has specific instructions for this particular assembler
0002				;
0003				;Version 0.2
0004				;
0005 0052			SaveA:		equ	$52		;This stuff is used by the assembler program, 
0006									;52 is the physical register for IO in this app
0007 00F0			BTDelay:	equ	$F0		;bit delay this	can be any value ya like
0008									;the atmel code	will measure the bit time
0009
0010 0071			Header:		equ	$71		;Just to make the Assembler output
0011									;the complete Header packet in its code dump packet :)
0012
0013 0071					org	Header
0014				;------------------------------------------------------------------------------------
0015				;
0016				;Example Header packet starts here but has nothing to do with car stuff, obviously XX won't work,
0017				;just edited for example purpose and didn't want to rewrite the whole thing
0018 0071 XX XX	XX XX XX XX			db $XX,$XX,$XX,$XX,$XX,$XX,$XX,$XX,$XX,$XX,$XX,$XX,$XX,$XX,$XX ;^)
	  XX XX	XX XX XX XX
	  XX XX	XX
0019
0020
0021				;------------------------------------------------------------------------------------
0022				;
0023				;BootStrap code	starts here
0024				;
0025 0080					org	$80		;Start of EXECUTED Buffer
0026 0080			EntryPoint:				;Glitch brings us here ;)
0027 0080 9B					sei
0028 0081 A6 55					lda	#$55		;Acknowledgement byte that informs me that dump is coming
0029 0083 20 28					bra	Start		;run dumper
0030
0031 0085			SendByte:
0032 0085 B7 52					sta	SaveA
0033 0087 4F			SendByteAt52:	clra
0034 0088 AD 47					bsr	DecA		;Inter-Byte delay
0035 008A AE 0A					ldx	#$0A
0036 008C 43					coma			;invert	byte
0037
0038 008D 11 00					bclr0	$00		;5 Zero	Bit
0039 008F AD 3C					bsr	DelayBit	;1st Start Bit
0040 0091 20 00					bra	SetIO		;3
0041
0042 0093 10 00			SetIO:		bset	$00, #0		;5 One Bit
0043 0095 AD 36					bsr	DelayBit
0044 0097 98					clc			;2nd Start Bit
0045
0046 0098 25 04			SendBit:	bcs	Send1		;3
0047
0048 009A 11 00					bclr0	$00		;5 Zero	Bit	|
0049 009C 20 04					bra	bitdelay	;3		|count this for	timing calc
0050
0051 009E 10 00			Send1:		bset	$00, #0		;5 One Bit	|but not this
0052 00A0 20 00					bra	bitdelay	;3		|
0053
0054 00A2 AD 29			bitdelay:	bsr	DelayBit
0055 00A4 48					asla	a		;3
0056 00A5 5A					decx			;3
0057 00A6 26 F0					bne	SendBit		;3
0058 00A8 10 00					bset	$00, #0		;Parity	= 0, Stop bits = 1
0059 00AA 81					rts			;6
0060
0061 00AB 30			AddyHi:		db	$30		;In this application we are starting the dump at address 3000 to read to 
0062 00AC 00			AddyLo:		db	$00
0063
0064 00AD			Start:
0065 00AD AD D6					bsr	SendByte
0066 00AF 4A			LongDelay:	deca
0067 00B0 AD 1B					bsr	DelayBit
0068 00B2 26 FB					bne	LongDelay
0069
0070
0071				; ---------------------------------------------------------------------------
0072 00B4 71			ChangeSeg:	db $71			;I can't remember but this might have been a page change
0073 00B5 80			Segment:	db $80			;I think this page started at address 8000
0074				; ---------------------------------------------------------------------------
0075 00B6 92C6			Loop:		dw	$92C6		;Load A([long.w],X)
0076 00B8 AB					db	AddyHi
0077 00B9 20 CA					bra	SendByte
0078 00BB AD CA					bsr	SendByteAt52
0079 00BD 3C AC					inc	AddyLo
0080 00BF 26 F5					bne	Loop
0081 00C1 3C AB					inc	AddyHi
0082 00C3 26 F1					bne	Loop
0083 00C5 3C B7					inc	Segment+2
0084 00C7 A6 80					lda	#$80
0085 00C9 B7 AB					sta	AddyHi
0086 00CB 20 E9					bra	Loop
0087
0088
0089 00CD			DelayBit:				;standard 8 bit	delay loop
0090 00CD B7 52					sta	SaveA
0091 00CF A6 F0					lda	#BTDelay
0092 00D1 4A			DecA:		deca
0093 00D2 26 FD					bne	DecA
0094 00D4 B6 52					lda	$52		;SaveA
0095 00D6 81					rts
0096
0097 00D7 9D					nop			;Padding so packet is the correct length
0098 00D8 9D					nop
0099 00D9 9D					nop
0100 00DA 9D					nop
0101 00DB 9D					nop
0102 00DC 9D					nop
0103 00DD 9D					nop
0104 00DE 9D					nop
0105 00DF 9D					nop
0106
0107 00E0 02					db	$02		;End of packet
0108
0109							;		   | 1 STB  |	     | 2 STB  |
0110							;
0111							;I/O Pin >---------+	    +--------+
0112							;		   |	    |	     |	       ..... data bits
0113							;		   +--------+	     +--------+

**Tom H** · 02-29-2020

Originally Posted by In-Tech

I think I read earlier about having a hard time reading some areas. It's been a very long time since I played with any of this stuff so forgive the intrusion. Here is an old "no rom call" dumper, kinda a bit bang approach and not exactly what you are doing but I am hoping the example might give you an idea of things when you are hunting in the blind. If not, I'll go back to my corner, lol :)
-Carl

Thanks Carl. Not at all sure of how this relates. I am running in bootstrap and communicating through the spi. Slow and cumbersome yes, but still better than bit bashing <grin>

Cheers,
Tom

**Tom H** · 02-29-2020

Hi,

This morning I re-visited efforts to find associations between TPU locations and functions. I modified my debug tool to read all registers of the TPU : wait 12.5ms : re-read all registers. The register content is stored in the PRU ram at $1900 through $1EFF. I decided not to keep track of the last quarter of TPU address space because in all testing so far, it is unused and just reads back zero. In any case I have completely run out of ram for code and data storage. My debug code uses all but a dozen locations of the internal low ram. The PRU ram is filled with stack and storage buffers. At this point, if I want to add something it needs to be in FLASH or EEPROM. Otherwise I need to remove some content in order to add anything.

Here are this mornings results. This details locations used by MAF, VATS and EBTCM spark retard request. The results come from buffering the TPU registers waiting 12.5ms and writing a different buffer of the registers. These buffers are uploaded into excel. In excel, the content of the registers are tested to see if they differ over the 12.5ms period. If so, I mark them as associated with the tpu function. Some locations are free running and do not depend on external input. I marked those with an 'x'.

Here is a summary of the data so far

-Tom

**Tom H** · 02-29-2020

Originally Posted by Tom H

Here is a summary of the data so far

That data file is confusing at best. I did not show the register address. This file is better...

**kur4o** · 02-29-2020

Unfortunately the code I refer to is from 96-97.
I have an idea for you to check. Upon entering bootstrap, do you upload the TPU configuration.
Try skipping the microcode load and see if the tpu will behave the same way. I suspect that the prebuilt code can be similar to the 94-95 code and since there is some changes mainly on the operating memory range but not on the registers, the 96-97 uses an updated version that is loaded externally from eside.

The xdf is some form of xml file for configuration. The best tutorial is to open one in a tunerpro and see how the tables are configured.
Here is one for 94-95 files.

**jthompson122183** · 02-29-2020

Maybe this hack can be of some use...
Lucky for us gm reused a lot of code through out the years.
A lot use the stuff i have named in eextra xdf has been found in previous hacks.

**In-Tech** · 03-01-2020

Originally Posted by Tom H

Thanks Carl. Not at all sure of how this relates. I am running in bootstrap and communicating through the spi. Slow and cumbersome yes, but still better than bit bashing <grin>

Cheers,
Tom

Hello Tom and others, I figured you guys were ok, just wanted to throw that out there if anyone needed an idea. Probably nothing to do with most efi stuff YET ;) for future use in protected areas(ie protected rom,ram,eeprom,maprom,etc) that you have some known calls in that area what I would do is push for example 33 onto the stack and load it up and when a rts is hit it will jump to YOUR code at 3333(in this example)...good times :)

**Tom H** · 03-29-2020

Hi,

It's about time I got a schematic together, it is too hard to communicate without being able to identify components. Like everything associated with reverse engineering the PCM, the schematic has a number of things that are just backward. GM did not want to pay to have silkscreen on their boards. This means we have no reference designators to go by. The first step must be to identify the components such that the schematic can be drawn. Usually the process is done the other way and ref des are generated in layout. Here they must come first.

The four files that follow are rough approximations of the PCBs (both sides) and the placement of components. If I have done my job well, each component will have a reference designator. If anyone would like a copy of the CAD files, just ask. They are in .dxf format. I used free cad software to generate by loading a picture of the board in. Then traced the outlines of the parts and manually assigned reference designators. Bunch of work but with lock down, what else would you do.

File names: BG stands for Blue/Gray (TSide) RB for Red/Black (ESide)
SS is solder side CS is component side

I wrote a small program to pull the ref des from the cad files but as yet have not started to fill in component info so not much use to post.

Work on the TPU has largely stalled. Later I will get back on that.

-Tom

**Tom H** · 05-02-2020

Hi,

Spent some productive "virus time" working through all my notes on the '97 Tside hardware. It's been a long haul, but here is a 95% schematic. It is of use for most things, so I wanted to share it now. I will refine it a bit over time. There are three PDFs. Two associate the physical PCB parts with a reference number that is used in the schematic file. I needed to revise these because of an oversight on my part. There were four parts that I assumed were polarized caps. They turned out to be a type of zener: for more info see

https://html.alldatasheet.com/html-p...4SMA16AT3.html

These parts are used on both the Class II serial and ALDL / NRZ serial lines.

Some other clean ups were done, so it is best to use these three files together. I got a long way into the schematic with my preferred tool (Mentor graphics) then suffered a crash. Hard drive gone, I found that my version was supported only up to xp and I no longer own a computer that isn't windows 10. My Mentor program is only supported in earlier OS and I don't want to $pend big time for current. I picked up a free program Kicad and it seems to work fine. If you would like Kicad source files, just ask.
While on the topic of tools, I used LibreCAD to produce the outline drawings. Also a free tool and works well.

Hope everyone is staying well in these times. -Tom

**Tom H** · 06-25-2020

Hi,

I have a question regarding vehicle distance traveled. Looking at the code I see a jump table that breaks down the steps required to process oil life. One of these steps takes distance the car has traveled as a factor. So far all good. The software calculates distance in a way that makes me unsure if I am understanding it correctly consider...

The oil life is assessed over a time of 1 second. There are ten time slices, the first of which calculates distance traveled. Software takes the vehicle speed in MPH and multiplies by 18. I believe they want the distance traveled in inches (?) and that the equation would look like this

MPH * 63360
----------- = inches traveled over 1s
3600

The 63360 is inches in a mile
The 3600 is seconds in an hour

Problem is that the code uses 18 and the actual factor is 17.6. This is quite a bit off and makes me question work.

The answer could be related to the second stage of this count. 2nd stage is incremented every 256 counts of the result of "inches traveled over 1s". Second stage will count each 250 inches (quite accurate). Taking the first stage factor of 17.6 * 256/250 gives us quite close to the expected 18 (18.0224).

Has anybody looked at this? Turns out to be linked into the calculated mileage (I think) and stored in the EEPROM.

Should have said at the top, this is all Eside s/w

-Tom

PS: Did anyone have a chance to test the unbrick software. I had hoped to see some result good or bad.

**kur4o** · 06-26-2020

I never look at the exact logic of that fuel change thing. It is nice to know it meters distance. Does the travel distance gets stored in ram somewhere from start of engine. We can datastream it to get very precise fuel consumption calculations. Newer Pcms takes also rpm and temp in the fuel life algo and can distinguish highway vs traffic miles.

I am planning to test the unbrick on a completely different GM pcm that use 68hc11 cpu, but never had the time. It will need some small fixes for the registers but overall structure is the same.

**NomakeWan** · 06-26-2020

Originally Posted by kur4o

I never look at the exact logic of that fuel change thing. It is nice to know it meters distance. Does the travel distance gets stored in ram somewhere from start of engine. We can datastream it to get very precise fuel consumption calculations. Newer Pcms takes also rpm and temp in the fuel life algo and can distinguish highway vs traffic miles.

I am planning to test the unbrick on a completely different GM pcm that use 68hc11 cpu, but never had the time. It will need some small fixes for the registers but overall structure is the same.

Oil change, not fuel change. In addition, distance travelled is only one of the variables that the '94-'97 computers use. At least on the Corvette, it also takes into account temperature and RPM, just like you stated.

https://www.youtube.com/watch?v=5-B1Pa33z90#t=33m30s

**Tom H** · 06-26-2020

Originally Posted by NomakeWan

Oil change, not fuel change. In addition, distance travelled is only one of the variables that the '94-'97 computers use. At least on the Corvette, it also takes into account temperature and RPM, just like you stated.

https://www.youtube.com/watch?v=5-B1Pa33z90#t=33m30s

Thank you for the link, it explains the intended operation and that is a help. For the oil life monitoring I see at least a few other things factored in...

Code:

*************************************************
* JUMP TABLE
*************************************************
5817  			FDB	$582B		; ASSESS OIL VS LIFE VEHICLE DISTANCE
			FDB	$5856		; ASSESS OIL LIFE VS VEHICLE SPEED
			FDB	$5873		; ASSESS OIL LIFE VS ENGINE RPM
			FDB	$5890		; ASSESS OIL LIFE VS TSIDE ECT
			FDB	$58AD		; ASSESS OIL LIFE VS ESIDE ECT
			FDB	$58CA		; CALCULATE OIL LIFE WEAR FACTOR
			FDB	$5989		; CALCULATE OIL LIFE WEAR FACTOR MULTIPLIER
			FDB	$599E		; 
			FDB	$5A17		; 
			FDB	$5A17		;

Not sure why both Tside and Eside ECT are used. Perhaps it is a fail safe?
As I get a bit deeper into this I see that there is both a RAM and an EEPROM table for oil life. Quite complicated. In my previous post I suggested that there are 10 time slices, but once again it's more complex. Working the timer back, it is related to the 12.5ms timer that is used to schedule software updates of everything. This scheduler is a direct page ram location ($003F in the '97 code). The scheduler is a divide by 80 incremented each 12.5ms. Rep rate is 1second.

I feel as if I am making some headway on understanding all this.
-Tom

**Tom H** · 06-26-2020

Hi,

I find it interesting that release code still contains so many references to debug issues. I happened upon a routine that will never run and seems to have no purpose. I then thought about the problems facing GM engineers and I believe this is their debug code. Some of this code may be of use to us, as when tuning we will face many of the same issues. Consider this segment of code:

Code:

* SEQUENTIAL RAM READ/WRITE FOR LOGIC ANALYZER
663F  12 44 04 18 	BRSET  @$44,$04,$665B	; LOGIC ANALYZER ACCESS COMPLETED FLAG

6643  DE 64       	LDX    @$64		; RAM ADDRESS POINTER
6645  27 0C       	BEQ    $6653		; 

6647  09          	DEX			; DECREMENT WORD POINTER
6648  09          	DEX			; 

6649  0F          	SEI			; 
664A  EC 00       	LDD    $00,X		; LOGIC ANALYZER TRIGGERS
664C  ED 00       	STD    $00,X		; 
664E  0E          	CLI			; 

664F  DF 64       	STX    @$64		; UPDATE POINTER

6651  26 F4       	BNE    $6647		; LOOP THROUGH RAM UNTIL $0

6653  CE 03 18    	LDX    #$0318		; RE-INITIALIZE MEMORY CLEAR POINTER
6656  DF 64       	STX    @$64		; SAVE

6658  14 44 04    	BSET   @$44,$04		; SET COMPLETE FLAG

Location $0064 is cleared at initialization time and as far as I can see is never changed. If external code changes the location and clears the flag, it reads then writes (no change to value) each of the ram locations. I believe logic analyzers would have been used to monitor the bus cycles. The 68hc11 has the option of making internal cycles visible at the pins and GM enabled it. Result is that even if loc $64 is never written, clearing the $44 flag runs the routine with the default of starting at $0316 (decremented x2 from the default of IX $318). I have found a bunch of code that works with their test set. I notice that all the address and data lines are brought to the 40pin connector. A logic analyzer was probably part of the test board and used this routine for on the fly ram dump.

-Tom

**Tom H** · 07-12-2020

Currently working through the ESide schematic. Found a number of things & will post the schematic soon.

One thing had me stumped for a bit was the distributor ignition feed. This circuit is 631 and comes from the ignition voltage input on the black connector pin 30. It turns out that GM used a resettable polyfuse to drive the pin. Has anyone had trouble with the ignition voltage feed to the opti-spark? Here is what goes on inside the PCM...

IgnitionFeed2.jpg

-Tom