1997 F-Body ECM

2 Attachment(s)

Optispark Hi&Lo res inputs

Traced through the inputs for optispark. Both wind up in unidentified logic but the signal conditioning part is complete. This is a work in progress but will shuffle to the back burner for a bit.

While doing this, I have identified another chip if this is of interest. Parts marked
014
P66AB
83833

are a quad Nand or And function. I need to sort out which (easy once I get the scope on it). I believe the part to be 74HC08 or possibly 74HC00. This part is used in the bank switching for the 28F010 Flash. In that application, A15 is one input and Port A bit 5 is used to switch the upper half of the FLASH. In this way the lower 32K of the address space remains constant while only the upper 32 is switched.

OK so back to opti... here is the info on the input signal conditioning. Interesting to note, going back to spfautsch's reply that the Hi Res signal is inverted in the signal conditioning comparitor. Hmmmm

-Tom

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

Attachment 13732

High Resolution signal enters through connector:
Connector C2 (BLACK)
Pin 20
Wire Purple/White
Circuit 430
Name High Resolution Signal

1 Capacitor to ground HIRES_C1
2 1K Pull up resistor to +5V HIRES_R1
3 100K resistor to Node A HIRES_R2
4 Capacitor to ground HIRES_C2
5 Resistors HIRES_R3 AND HIRES_R4 form a divider between 5V and ground
this 2.5 volt reference is the +VE input to comparitor 2 on pin 11
6 Resistor HIRES_R5 connects to the -VE Input of comparitor pin 10
7 LM339 is an open collector type ouput on pin 13. HIRES_R6 is used to
pull the output to +5V.
8 HIRES_R7 provides feedback/hysteresis to the +VE input / voltage divider.
9 Pin 4 of the unknown 28 pin PLCC see below

Comparitor chip is marked
014
M66DB
89551

Believed to be a LM339 quad comparitor or a variant
that shares the pin configuration.

Unknown 28 pin PLCC
609-3700521
CP08978
144436
9638N
SYMBIOS LOGIC
726

Attachment 13733

Low Resolution signal enters through connector:
Connector C2 (BLACK)
Pin 2
Wire Red/Black
Circuit 453
Name Low Resolution Signal

1 Capacitor to ground LORES_C1
2 1.0K Pull up resistor to +5V LORES_R1
3 100K resistor to Node A LORES_R2
4 Capacitor to ground
5 10K Resistor to Node B LORES_R3
6 Resistor feedback LORES_R4
7 +VE Input of comparitor LM339 pin 9
8 -VE Input of comparitor pin 8 to pins 4,6 and 10
these inputs are biased to 2.5V by components
Resistor VATS_R5
Resistor VATS_R6
Capacitor VATS_C3
9 LM339 is an open collector type ouput. LORES_R5
resistor pulls the output to +5V. Output is pin 14
10 Unknown logic chip pin 9

Comparitor chip is marked
014
M66DB
89551

Believed to be a LM339 quad comparitor or a variant
that shares the pin configuration.

Unknown logic chip is TI branded and marked
014
P63SN
73098

Some code from the Tside used to monitor low side drivers on both boards for short and open condition...

-Tom

Code:

************************************************ * READ STATUS OF OUTPUT DRIVERS THROUGH SPI ************************************************ BAA2 12 B3 01 03 BRSET @$B3,$01,$BAA9 ; SPI FRAME TX IN PROGRESS BAA6 7E BB 29 JMP $BB29 ; DONE BAA9 13 7F 10 03 BRCLR @$7F,$10,$BAB0 ; BRANCH IF BATTERY NOT LOW BAAD 7E BB 29 JMP $BB29 ; DONE BAB0 0F SEI ; DISABLE INTERRUPTS BAB1 7F 10 28 CLR $1028 ; RE-INITIALIZE SPI FOR MASTER BAB4 86 50 LDAA #$50 ; MODE AND DIFFERENT CLOCK PHASE BAB6 B7 10 28 STAA $1028 ; TO MATCH LOW SIDE DRIVER CHIPS BAB9 CE 18 00 LDX #$1800 ; PORT REPLACEMENT CHIP * C1 (RED) CONNECTOR DRIVER BABC 1D 00 10 BCLR $00,X,$10 ; SELECT FIRST LOW SIDE DRIVER BABF B6 10 29 LDAA $1029 ; READ SPI STATUS AND WRITE BAC2 B7 10 2A STAA $102A ; STATUS AS DATA TO INITIATE TRANSFER BAC5 3D MUL ; REAL TIME DELAY BAC6 3D MUL ; BAC7 B6 10 2A LDAA $102A ; READ SPI DATA BACA 9A 90 ORRA @$90 ; UPDATE OPEN CIRCUIT STATUS BACC 97 90 STAA @$90 ; BACE B6 10 29 LDAA $1029 ; READ SPI STATUS BAD1 B7 10 2A STAA $102A ; INITIATE TRANSFER BAD4 3D MUL ; REAL TIME DELAY BAD5 3D MUL ; BAD6 B6 10 2A LDAA $102A ; READ SPI DATA BAD9 9A 8F ORRA @$8F ; UPDATE SHORT CIRCUIT STATUS BADB 97 8F STAA @$8F ; BADD 1C 00 10 BSET $00,X,$10 ; DE-SELECT FIRST LOW SIDE DRIVER * C2 (BLACK) CONNECTOR DRIVER BAE0 1D 00 20 BCLR $00,X,$20 ; SELECT SECOND LOW SIDE DRIVER BAE3 B6 10 29 LDAA $1029 ; READ SPI STATUS AND WRITE BAE6 B7 10 2A STAA $102A ; STATUS AS DATA TO INITIATE TRANSFER BAE9 3D MUL ; REAL TIME DELAY BAEA 3D MUL ; BAEB B6 10 2A LDAA $102A ; READ SPI DATA BAEE 9A 92 ORRA @$92 ; UPDATE OPEN CIRCUIT STATUS BAF0 97 92 STAA @$92 ; BAF2 B6 10 29 LDAA $1029 ; READ SPI STATUS BAF5 B7 10 2A STAA $102A ; INITIATE TRANSFER BAF8 3D MUL ; REAL TIME DELAY BAF9 3D MUL ; BAFA B6 10 2A LDAA $102A ; READ SPI DATA BAFD 9A 91 ORRA @$91 ; UPDATE SHORT CIRCUIT STATUS BAFF 97 91 STAA @$91 ; BB01 1C 00 20 BSET $00,X,$20 ; DE-SELECT SECOND LOW SIDE DRIVER * BLUE CONNECTOR DRIVER BB04 1D 00 40 BCLR $00,X,$40 ; SELECT THIRD LOW SIDE DRIVER BB07 B6 10 29 LDAA $1029 ; READ SPI STATUS AND WRITE BB0A B7 10 2A STAA $102A ; STATUS AS DATA TO INITIATE TRANSFER BB0D 3D MUL ; REAL TIME DELAY BB0E 3D MUL ; BB0F B6 10 2A LDAA $102A ; READ SPI DATA BB12 9A 94 ORRA @$94 ; UPDATE OPEN CIRCUIT STATUS BB14 97 94 STAA @$94 ; BB16 B6 10 29 LDAA $1029 ; READ SPI STATUS BB19 B7 10 2A STAA $102A ; INITIATE TRANSFER BB1C 3D MUL ; REAL TIME DELAY BB1D 3D MUL ; BB1E B6 10 2A LDAA $102A ; READ SPI DATA BB21 9A 93 ORRA @$93 ; UPDATE SHORT CIRCUIT STATUS BB23 97 93 STAA @$93 ; BB25 1C 00 40 BSET $00,X,$40 ; DE-SELECT THIRD LOW SIDE DRIVER BB28 0E CLI ; ENABLE INTERRUPTS BB29 39 RTS ; DONE

Engine RPM calcs

How does this code match up with what other folks have found? Not sure yet why engine rpm is calculated twice with different scale factors... re-use of older code??

Code:

************************************************ * OPTISPARK LOW RES SIGNAL IS DRIVEN OFF THE CAM * AND HAS EIGHT SLOTS. EACH TWO ENGINE REVS GENERATE * EIGHT PULSES OR FOUR PER REVOLUTION. * * LOCATION $01E0 IS THE NUMBER OF 5.086US TICKS * BETWEEN EACH CYL. THIS VALUE COMES FROM * THE TIMER CLOCK INPUT AND PRESCALE AS: * 12.5829MHZ /4 /16 = 196,608HZ OR 5.086US * * FDIV DIVIDES THE CONSTANT 461 * 2^16 OR 30,212,096 * DIVIDED BY THE NUMBER OF TICKS * RESULT IS 8 * RPM. * * FOR 1000RPM, OR 16.66RPS, EACH OF THE EIGHT LOW * RES PULSES HAPPEN AT 90 DEGREES (CRANK-> 45 CAM&OPTI) * OR 66.666HZ/.015MS * 15MS/5.086US = 2949 TICKS BETWEEN LOW RES PULSES * 30,212,096/2949 = 10244....1000 RPM. *********************************************** 7182 FE 01 E0 LDX $01E0 ; TIMER TICKS BETWEEN LO RES INTS 7185 CC 01 CD LDD #$01CD ; DIVIDE CONSTANT 461 * 65536 7188 03 FDIV ; DIVIDE TO GET RPM * 10 7189 8F XGDX ; 718A 37 PSHB ; SAVE RPM * 10 718B 36 PSHA ; 718C C3 00 80 ADDD #$0080 ; FORCE CARRY OUT FROM LSBYTE 718F 24 02 BCC $7193 ; SHOULD NOT OVERFLOW 7191 86 FF LDAA #$FF ; FORCE ERROR INDICATION 7193 B7 01 62 STAA $0162 ; RPM * 10/256 OR RPM/25 7196 32 PULA ; RESTORE RPM * 10 7197 33 PULB ; 7198 05 ASLD ; MULTIPLY BY 2 7199 25 05 BCS $71A0 ; 719B C3 00 80 ADDD #$0080 ; FORCE CARRY OUT FROM LSBYTE 719E 24 02 BCC $71A2 ; 71A0 86 FF LDAA #$FF ; FORCE ERROR INDICATION 71A2 B7 01 63 STAA $0163 ; RPM * 20/256 OR RPM/12.5 71A5 5F CLRB ; 71A6 FE 01 64 LDX $0164 ; READ AGERAGE RPM 71A9 27 06 BEQ $71B1 ; IF ENGINE NOT RUNNING, BRANCH 71AB F6 2A 25 LDAB $2A25 ; FLASH CONST $33 71AE BD 4E 94 JSR $4E94 ; CALCULATE AVERAGE, OLD * 5/6 + 33 * NEW 71B1 FD 01 64 STD $0164 ; UPDATE 20 * RPM * CALCULATE HIGH RESOLUTION ENGINE SPEED: RPM X 4 71B4 CC 00 B4 LDD #$00B4 ; DIVIDE CONSTANT 180 * 65536 71B7 FE 01 E0 LDX $01E0 ; TIMER TICKS BETWEEN LO RES INTS 71BA 03 FDIV ; RESULT IS 4* RPM 71BB 8C 00 B4 CPX #$00B4 ; TEST FOR 45 RPM 71BE 22 03 BHI $71C3 ; BRANCH IF RUNNING... 71C0 CE 00 00 LDX #$0000 ; MARK AS NOT RUNNING 71C3 FF 01 D0 STX $01D0 ; ENGINE RPM X 4

1 Attachment(s)

Great work on the hardware side. It does clear some missing pieces.

The rpm calculations come in many different scalars, because of the various tables that need different resolution. There is aso a rpm variation coefficient, that is not clear what is does.

Here is the code that is used for PCM flashing. I tried to label most of them. You can do a disassembly to get an insight of the process.

Working through test tool interface code at the moment. I have found the download sequence in mode $34. Interesting that controller $10 and controller $18 which I take to be Tside and Eside are handled differently. Hmmm perhaps I got this wrong(?) Good puzzle though. Almost looks like one is download and the other download & execute. More effort needed here.

I got the hardware work I planned done, although I expect to be back there again at some point. The code shows more hardware and the hardware shows more code....

Still trying to get hold of a board with both 68HC11 and D84G on it. Any ideas what to ask for? I don't care if it is an ECM or ABS or ??. Just need a common cheap part to mess with.

Most of the physically addressed modes J2190 are now commented. Some confusion still exists, but getting better. Not much work on Eside yet.

Thank you for your interest, I will look through the write routine now. Hope this is a good boost.

Perhaps I should caution everyone... The ribbon cable between E&T sides is VERY FRAGILE. After investigating hardware I put it back on the test bench and there was no life. Hours and hours later I am back up with several wires jumpered between boards. Probably should replace the PCM or at least the ribbon cable. I was thinking to install headers on the board with a plug in cable. Would be very convenient to be able to separate the boards. Wires fracture at the internal insulation displacement contacts: no hope to repair w/o jumper or replace cable.

$10 as primary communication ID should be tside. $18 should be eside. Must be confirmed in code as it is only assumption.
$18 triggers the VPP voltage for both chips during erase/write.

Mode 34 is only for requesting mode 36. If the pcm agrees it response with 44.
Mode 36 80 is for download and execute. 36 00 is for download only. Some earlier pcm only have download and execute mode only so it doesn`t matter if it is 36 80 or 36 00.
Mode A1 is for high speed comm x4 vpw mode.

Here are sample msgs.
6C 10 F0 34 00 [03 42] [00 00 EE] request data download for $342 bytes at 00 00 EE ram address
6C F0 10 74 00 44 response [pcm agreed ]
tool sends
6D 10 F0 36 00 03 42 00 00 EE ....message....[XX XX or YY]
xxxx= block checksum if used
yy=1 byte checksum only

You will get a confirmation message before the pcm execute the code at EE address.

This example is for newer PCMs and might differ slightly with the 97 lt1 pcm.

I have seen D84G as only processor in 94 camaro ABS and SIR modules. Will try to gey you a pictures of those.

I have an update regarding the data link controller. No longer a need to guess regarding the registers and use of the comms part....

I have found a data sheet at:

http://pdf.datasheetcatalog.com/data.../374731_DS.pdf

which I believe is the the part marked:
54545T40
20686
466 {?delco?delphi?other? logo}

The post I made earlier is perhaps how the prototype was done, but not the actual chip. It makes dis-assembly much easier when the exact definition of bits is know. Perhaps a list of GM parts vs. house numbers can be assembled on this forum? I have found a number of them that relate to my PCM, but they are used all over and can help with other projects.

-Tom

Here is code used to service frame receive with the DLC in cases where the code waits for the frame to become available. Service of asynchronous / background frames uses other code. This is the code used when sending data to the PCM for programming. It was lucky that I was able to find the data sheet for the MC68HC58 because while the operation isn't complex, it is hard to decipher with out the bit definitions.

-Tom

Code:

************************************************ * LOOP WHILE MONITORING DLC RETURN WHEN * FRAME IS AVAILABLE, ON TIME OUT, ON ERROR ************************************************ DDDB 37 PSHB ; SAVE REGISTERS DDDC 18 3C PSHY ; DDDE 18 CE 0D 3A LDY #$0D3A ; SET TIME OUT CONSTANT 3386 DDE2 7F 1C 10 CLR $1C10 ; SET LOOP COUNTER DDE5 BD 4E 7F JSR $4E7F ; RESET THE COP DDE8 BD 4E 8A JSR $4E8A ; RESET THE PORT EXPANDER WATCHDOG DDEB 7A 1C 10 DEC $1C10 ; DECREMENT LOOP COUNT AND RESET DDEE 26 0A BNE $DDFA ; WATCHDOGS EVERY 256 LOOPS DDF0 BD 4E 7F JSR $4E7F ; RESET THE COP DDF3 BD 4E 8A JSR $4E8A ; RESET THE PORT EXPANDER WATCHDOG DDF6 18 09 DEY ; DECREMENT TIME OUT COUNT DDF8 27 2B BEQ $DE25 ; BRANCH TIME OUT EXPIRED DDFA B6 10 60 LDAA $1060 ; READ DATA LINK CONTROLLER STATUS DDFD 85 E0 BITA #$E0 ; TEST RECEIVE FIFO STATUS FIELD DDFF 27 EA BEQ $DDEB ; LOOP ON BUFFER INVALID/EMPTY DE01 B7 1C 07 STAA $1C07 ; SAVE RFS FIELD OF STATUS WORD DE04 FC 10 60 LDD $1060 ; READ STATUS & DATA DE07 B1 1C 07 CMPA $1C07 ; TEST FOR STATUS CHANGE DE0A 23 03 BLS $DE0F ; DE0C B6 1C 07 LDAA $1C07 ; GET ORIGNIAL STATUS RFS FIELD DE0F 18 38 PULY ; RESTORE IY DE11 81 A0 CMPA #$A0 ; TEST FOR COMPLETION CODE AT HEAD OF BUFFER DE13 24 03 BCC $DE18 ; BRANCH ON COMPLETION CODE AT HEAD DE15 0C CLC ; INDICATE NOT LAST BYTE (COMPLETION) DE16 20 1C BRA $DE34 ; PASS DATA BACK TO CALLING ROUTINE * PROCESS COMPLETEION CODE DE18 C5 40 BITB #$40 ; TEST RECEIVE FIFO OVER RUN DE1A 26 09 BNE $DE25 ; BRANCH ON OVER RUN DE1C 5D TSTB ; TEST ERROR INDICATION DE1D 2A 14 BPL $DE33 ; BRANCH NO ERROR * ERROR CODE FIELD * 00 CRC error * 01 Incomplete byte * 10 Bit timing error * 11 Break DE1F C4 03 ANDB #$03 ; DE21 C1 03 CMPB #$03 ; DE23 27 02 BEQ $DE27 ; BRANCH BREAK DETECTED * TIME OUT DE25 20 FE BRA $DE25 ; LOOP TILL WATCHDOG DE27 8E 1C 2A LDS #$1C2A ; RESET STACK DE2A CC F8 0A LDD #$F80A ; ABORT TRANSMISSION DE2D FD 10 60 STD $1060 ; RE-CONFIGURE DLC ; FOR INTERRUPT OPERATION DE30 7E DC 5F JMP $DC5F ; GET FRAME DE33 0D SEC ; CARRY INDICATES COMPLETION CODE ; FRAME READY DE34 17 TBA ; TRANSFER DATA TO ACCA DE35 33 PULB ; RESTORE REGISTER DE36 39 RTS ; DONE

I'm anxious to see about how the 3->2 downshift works in the 96/97 code, maybe we can Port it over to the 94/95 for those that obd1 swap the 96/97.

BTW are you Tom Hussey from here
https://web.archive.org/web/20030527...y/msg00279.htm
If so wow I congrats on working on this platform for so long

I hope once complete any/all code could be ported or modified. Sticking with GM tested code is safe: exhaustivly tested and considering the entire design. So far I have detailed much of the OBDII and Tside code. Three is transmission code I have not touched... yet. There is 100K of code and that is a steep thing for disassembly. I hope that we could get there...

I am that same person from a lifetime ago. I can't say I have been working on the platform all this time however. I had the car new and took it solo racing. This love of road racing grew and I bought an open wheel car: Formula Vee. Ran that in regional racing (CASC up here in Canada is like SCCA down in US). The Camaro met it's demise on our busy highway 401 one afternoon when I stopped for road construction backup. When I woke, I was looking up at someone's oil pan through the shattered back glass. I was lucky the seat had broken and it went up, landing on top.
I am planning a project now, and started again a month ago to understand the ECMs. I had some code that I wrote from all those years ago but am starting almost fresh. I have discovered (and re-discovered) much of the work I did back then.

I hope that this work will be of use to someone other than myself. Currently I am working on download. I have now digested steps up to the point where the tester has entered Mode $34. Last step is mode 36 to actually send something. I was surprised that all this isn't more common knowledge. I am now working out details such as which bytes are contained in the 16bit checksum of the download mode 36 commands. I hope to post details and a program to get a PCM reply of "Hello world!" soon.

Cheers, -Tom

Quote:

Originally Posted by Tom H

So far I have detailed much of the OBDII and Tside code.

I hope that this work will be of use to someone other than myself. Currently I am working on download. I have now digested steps up to the point where the tester has entered Mode $34. Last step is mode 36 to actually send something. I was surprised that all this isn't more common knowledge. I am now working out details such as which bytes are contained in the 16bit checksum of the download mode 36 commands. I hope to post details and a program to get a PCM reply of "Hello world!" soon.

Cheers, -Tom

I went through obd2 code real quick and it is a real mess at least on the 96. Later OS might get it a bit cleared.

As far as mode 36 block checksum is calculated on later vpw pcms it is really simple.
Sum all words after 6D 10 F0 36 ......data...... xxxx[last 2 bytes of checksum=block checksum] yy[vpw message checksum of whole message].
I couldn`t find it in the code to confirm but should be something like that.
The pcm might response with 72 and 77 message stating wrong checksum and longer than expected message.
73 or 78 or something else if the upload is successful.

Did you managed to find what modes are supported. I have a detailed info on most of them.

Have been sorting through the code for mode $34 & $36 for some time now. There are a bunch of different buffers and queues, code that depends on flags I don't yet know the purpose of and so on. Typical disassembly ?s.

One thing I am questioning is if the standard "header:frame:checksum" format is followed in mode $36. The DLC is set up for this format as is the ELM327. I need to see if/how the ....data.... you suggest is handled.

I have detailed most of the supported modes and found all of them. Different modes supported depending on which target ECM, physical vs. functional addressing and other conditions ( such as access to the data transfer)

I will keep plugging away on this, hope to complete soon.

-Tom

{6D 10 F0 36 [[80 (00 70) (00 18 10) //86 86 36 CE 76 80 3C 30 9D 86 38 31 39 18 38 18 EC 02 FD 18 7C CD EE 00 18 08 18 08 18 08 18 08 4F 9D 8F C6 40 E7 00 18 E6 00 E7 00 FB 18 7F F7 18 7F 24 03 7C 18 7E 9D 89 C6 C0 E7 00 9D 8C 18 E6 00 E1 00 27 07 4C 81 19 23 D6 20 12 08 18 08 3C FE 18 7C 09 FF 18 7C 38 26 C5 86 86 20 02 86 85 36 CE 76 80 3C 30 9D 86 38 31 39 00 00 00 00//]] [29 0A]} [56]

Here is some sample mode 36 message.
MODE is 36 80 it could be 36 00 also. It depends on pcm. 80 means download and execute. 00 means download only. Some PCMs don`t support multi message download and they execute on both 00 or 80.
(00 70) is the lenght of the message. The message lenght is contained between //...//
(00 18 10) is the ram address you want the message to get loaded. It is always 3 byte length.
[29 0A] this is the block checksum. It is used by the pcm to check data integrity. It is word+word+word 16 bit type checksum caculated from data contained in[[.....]]
[56] this the checksum of DLC. it is calculated from data contained in {....}
this is 8-bit CRC with the following attributes

8 Bit CRC
Polynom 0x1D
Inital value 0xFF direct
Final XOR value 0xFF
Reflection IN false
Reflection Out false

So you have 2 different checksums to calculate. The DLC checksum is usually handled by the tool.
If the upload is successful you are likely to get a message containing 73.

Thank you for all your help! The additional clarification is a great boost.

Looks to me as if the ELM327 is a non-starter for download. To send anything like the format you have given, a large buffer is needed internally OR the translator needs to start the transmit before all the characters have been placed in it;s fifo.
I guess a different setup will be needed. Setback but a thing that is not too difficult.

I will go through the code. I had already found the process for the 2nd byte (execute the code). Along with that are a great number of checks and standard replys (things like invalid address if not in ram )

Again, thanks for the help and I will get back over the next few days.

-Tom

you know if you want any help with the software end of things i'd be happy to do things like.. you know.. write a tool and UI for a flash tool or whatever? help write and clean up an XDF? i did it for $EE and i'd do it just for fun with this thing. just holler.