1997 F-Body ECM

**kur4o** · 03-08-2019

https://www.scantool.net/

These are the only elm devices that are tested to work for reading/flashing Gm PCM.
All have a 192 bytes buffer out of the box that support elm commands. They also have extended commands that enables upto 2-3k bytes messages.
The usb version has the smallest buffer.
The only drawback is the lack of high speed mode, which might be fatal if the main communication loop that is loaded at RAM is set to communicate only in high speed. You might check if there is multiframe support for mode 36 00[download only], so you can split the message in smaller pieces.

A homebrew board is also easy to do, If you are interested I will try to get you a schematic.

The main routine that is loaded at the very start is the code the processor will run from during reflash. It should have all the loops for bd2 communication and you need to land it in the processor ram space. So my guess is both processor have slightly different versions and the chips are flashed independantly. The main concern here is how the obd-2 messages goes to eside RAM. Is it direct communication, or it goes through the SPI channel from tside to eside.

After the main communication loop is loaded and the processor runs from there you can send more code to execute.
A erase code or a vpp enable code. After it gets executed there is a jump again to main control loop. It should be an indefenite loop or it could expire after x time of inactivity. A disassembly will reveal all the functions it has.

**steveo** · 03-09-2019

you guys are both brilliant. i really want to get an lt1 again so i can contribute, i'll have to keep my eyes open. i don't need a car right now, but maybe an lt1 in a truck swap or some such thing

My understanding of the code is that the Tside download is not used for FLASH. It looks to me like the Eside (0x18) is used to transfer from tester to RAM. The code we develop or find to program can target Eside or Tside.

what you suggest would involve one side running a (probably uploaded and executed) spi 'relay' loop of some kind during programming so the other side can program, wouldn't it? or how else would it be accomplished? are you sure direct comms aren't used? just curious because i had to scratch my head for a long time to realize that in $EE the ALDL bus runs in parallel but the e-side doesn't respond to messages unrelated to programming, pretty much just for the purpose of programming without having to rely on the other side as a relay or whatever.

**Tom H** · 03-09-2019

[QUOTE=steveo;74693
what you suggest would involve one side running a (probably uploaded and executed) spi 'relay' loop of some kind during programming so the other side can program, wouldn't it? or how else would it be accomplished? are you sure direct comms aren't used? just curious because i had to scratch my head for a long time to realize that in $EE the ALDL bus runs in parallel but the e-side doesn't respond to messages unrelated to programming, pretty much just for the purpose of programming without having to rely on the other side as a relay or whatever.[/QUOTE]

This all is yet to be confirmed. I am sure no direct comms over the class 2 OBDII link takes place with the Eside because there is no DLC on the E board. One could see a way that SPI (ALDL the 8192 baud serial or however it ti described) could be used to program. I would like to see a more general solution, one that could be used on later PCMs as well. Will post later this morning with code to take Srecords and produce a frame including header, mode and parameters, data, checksum and crc. Then the trick becomes designing/finding hardware that can deliver the long frame. I have been thinking about the buffered obdlink hardware kur4o described. While this is not my preferred solution, it could work for sure. As long as the buffer is big enough to send a download frame, multiple mode 36 commands can be issued. With this we can fill the available ram one chunk at a time. the size of the chunk depends on the buffer size. Anything over 20 bytes or so could work. Frame overhead is

3 bytes header, 7 bytes mode and parameters, then after the data, 2 bytes checksum, 1 byte crc =13 bytes

Adding the overhead with the smallest data size I think could be reasonable (16) gives a working frame buffer size at the tester of 19 bytes. As in most things more is better.

The other way to go is with the 'HC58 DLC. This being the same part used on the Tside board. That part can send and receive any length. The internal FIFOs permit the software to access the frame while it is still being received. This eliminates any constraint on how long the frame is.

-Tom

**Tom H** · 03-09-2019

I have completed code to generate the long mode $36 download frames. Can't thank kur4o enough for the help...

Starting with the details of a correct frame...

Code:

{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

I generated an assembler source file for the content of that frame. This represents the code we expected to be downloaded. This means that the header, mode and parameters along with the checksum and crc bytes are removed from the source code. Origin is set to match what I see in the frame.

Code:

	ORG $1810
	;DB  $6D  Header is re-generated by the program
	;DB  $10  
	;DB  $F0  
	;DB  $36  
	;DB  $80  
	;DB  $00  
	;DB  $70  
	;DB  $00  
	;DB  $18  
	;DB  $10  
START	DB  $86  
	DB  $86  
	DB  $36  
	DB  $CE  
	DB  $76  
	DB  $80  
	DB  $3C  
	DB  $30  
	DB  $9D  
	DB  $86  
	DB  $38  
	DB  $31  
	DB  $39  
	DB  $18  
	DB  $38  
	DB  $18  
	DB  $EC  
	DB  $02  
	DB  $FD  
	DB  $18  
	DB  $7C  
	DB  $CD  
	DB  $EE  
	DB  $00  
	DB  $18  
	DB  $08  
	DB  $18  
	DB  $08  
	DB  $18  
	DB  $08  
	DB  $18  
	DB  $08  
	DB  $4F  
	DB  $9D  
	DB  $8F  
	DB  $C6  
	DB  $40  
	DB  $E7  
	DB  $00  
	DB  $18  
	DB  $E6  
	DB  $00  
	DB  $E7  
	DB  $00  
	DB  $FB  
	DB  $18  
	DB  $7F  
	DB  $F7  
	DB  $18  
	DB  $7F  
	DB  $24  
	DB  $03  
	DB  $7C  
	DB  $18  
	DB  $7E  
	DB  $9D  
	DB  $89  
	DB  $C6  
	DB  $C0  
	DB  $E7  
	DB  $00  
	DB  $9D  
	DB  $8C  
	DB  $18  
	DB  $E6  
	DB  $00  
	DB  $E1  
	DB  $00  
	DB  $27  
	DB  $07  
	DB  $4C  
	DB  $81  
	DB  $19  
	DB  $23  
	DB  $D6  
	DB  $20  
	DB  $12  
	DB  $08  
	DB  $18  
	DB  $08  
	DB  $3C  
	DB  $FE  
	DB  $18  
	DB  $7C  
	DB  $09  
	DB  $FF  
	DB  $18  
	DB  $7C  
	DB  $38  
	DB  $26  
	DB  $C5  
	DB  $86  
	DB  $86  
	DB  $20  
	DB  $02  
	DB  $86  
	DB  $85  
	DB  $36  
	DB  $CE  
	DB  $76  
	DB  $80  
	DB  $3C  
	DB  $30  
	DB  $9D  
	DB  $86  
	DB  $38  
	DB  $31  
	DB  $39  
	DB  $00  
	DB  $00  
	DB  $00  
	DB  $00  
	;DB  $29  Checksum is regenerated by the program
	;DB  $0A  
	;DB  $56  CRC is regenerated by the program
	END     START;	end of program with start address specified

Assembling that code, we come up with the Srecord (.S19) file that we want to turn into a frame...

Code:

S1231810868636CE76803C309D86383139183818EC02FD187CCDEE0018081808180818085B
S12318304F9D8FC640E70018E600E700FB187FF7187F24037C187E9D89C6C0E7009D8C181A
S1231850E600E10027074C811923D620120818083CFE187C09FF187C3826C5868620028605
S11318708536CE76803C309D8638313900000000B4
S9031810D4

The Srecord file is input to the frame generator code... output looks like this

Code:

Input file opened

Line: 1  Byte count: 75
Record type: S1 found
Record length: 0x23
Record address: 0x1810
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

Checksum: 0x5b

Line: 2  Byte count: 4b
Record type: S1 found
Record length: 0x23
Record address: 0x1830
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

Checksum: 0x1a

Line: 3  Byte count: 4b
Record type: S1 found
Record length: 0x23
Record address: 0x1850
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

Checksum: 0x05

Line: 4  Byte count: 2b
Record type: S1 found
Record length: 0x13
Record address: 0x1870
85 36 ce 76 80 3c 30 9d 86 38 31 39 00 00 00 00

Checksum: 0xb4

Line: 5  Byte count: b
Record type: S9 found
Record length: 0x3
Record address: 0x1810
Srecord indicated execution start address: 0x1810

Frame content:
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

Since the output frame matches the original example frame, I think all the code that adds headers, mode and parameters, checksum and CRC is well tested.
Using this frame generator we can write 6811 code, assemble it to Srecords, make a mode 36 frame. That frame can then be used to download the PCM.

I am happy to share all code, but the archive of the visual studio project is quite large (27M). I am not sure a file that large should be loaded here (?)
Let me know what would be of use. The actual source is quite small and the exe is tiny.

I will make a example program the standard "Hello World" to download. Then it is on to figuring out how to bash bits to get around limits of the ELM327

-Tom

**dzidaV8** · 03-10-2019

Wow, I see I'm not the only one to reverse engineer OBD2 LT1 PCM :) Nice work, but it's a shame we are doubling up... I started working on this PCM over a year ago, now I have full E-side and partial T-side disassembly done in IDA and I'm in the process of finalizing the reflash kernel. I have succesfully read and reflashed T-side, E-side is still giving me some problems (SPI synchronization).
I'm willing to share most my work, there's a lot yet to be done on T-side - the transmission code is quite complicated.
My goal is to make fully functional and intuitive OBD2 LT1 tuner, partially free (but not completely, coding the flash kernel in pure assembly took me almost a year and was a major PITA).

As for the reflash, there are two routines uploaded, one to each PCM side. T-side does all the OBD data transfer functions, and relays data to E-side over SPI. E-side has routines to process SPI received data. ALDL is not used during reflash, I'm not sure if it is even connected to E-side, and even if it was, it's 8192bps vs 41.6 kbps - no brainer which interface to use :)

ELM327 will not work for reflash, it does not accept long messages, but STN1110/STN1170 (cheap ELM327 compatible interface) will work in slow 1X mode. For Fast reflash AVT cable is the best option, which I'm using.

I'm attaching T-side disassembly, where all the OBD Mode 34 magic goes ;)

**Tom H** · 03-12-2019

Fantastic to see other folks interested!!!

"
Wow, I see I'm not the only one to reverse engineer OBD2 LT1 PCM :) Nice work, but it's a shame we are doubling up... I started working on this PCM over a year ago, now I have full E-side and partial T-side disassembly done in IDA and I'm in the process of finalizing the reflash kernel. I have succesfully read and reflashed T-side, E-side is still giving me some problems (SPI synchronization).
"
You are much farther along with this than I am --> great going!

"
As for the reflash, there are two routines uploaded, one to each PCM side. T-side does all the OBD data transfer functions, and relays data to E-side over SPI. E-side has routines to process SPI received data. ALDL is not used during reflash, I'm not sure if it is even connected to E-side, and even if it was, it's 8192bps vs 41.6 kbps - no brainer which interface to use :)
"
This confirms what I have suspected. Thanks

"
ELM327 will not work for reflash, it does not accept long messages, but STN1110/STN1170 (cheap ELM327 compatible interface) will work in slow 1X mode. For Fast reflash AVT cable is the best option, which I'm using.
"
Two questions here if you don't mind: How does one know what chip is used in a cheap interface cable? I am not sure how to probe into the USB module to determine this. 2nd Q is can the ELM or STN be re-programmed? I will look into cost, availability and tech of the AVT to see if I can get my hands on one up here in Canada.

Thanks for the info. I have done quite a bit with the Tside and am interested to see how well I did <grin>

If there is anything I can help out with, please just ask.

Cheers,
-Tom

**Tom H** · 03-12-2019

I have completed "Hello world" code and generated a download frame for testing. The object here is to download a benign file to ram proving the download code. In moving with caution, I hope to avoid creating bricks...

The simple 68hc11 code I wrote is:

Code:

* Clock source	16MHZ to the PCMs 12.5829
* Eclock	 4MHZ to the PCMs  3.1457
* Timer is prescaled by 1, 4, 8 or 16
* Prescale is set in TMSK2 $1024 bits 1:0
* TMSK2 defaults to $00 on reset
* Default setting overflow at 60hz to the PCMs 50hz

REGISTERS	EQU	$1000		;
RAMEND		EQU	$03FF		;

TFLG2		EQU	$25		;
SPCR		EQU	$28		;
BAUD		EQU	$2B		;
SCCR1		EQU	$2C		;
SCCR2		EQU	$2D		;
SCSR		EQU	$2E		;
SCDR		EQU	$2F		;

	ORG	$0000			; SET ORIGIN


START	LDX	#REGISTERS		; POINT X AT REGISTER BASE ADDRESS

; NO NEED TO SET UP PORT... ALREADY SET BY PCM CODE OR
; IN THE CASE OF TEST, THE BOOTSTRAP ROUTINE
;	BSET	SPCR,X,$20		; SET PORT D FOR WIRE OR MODE

;	LDD	#$330C			; RATE IS INPUT /4(ECLK) /8(PRS) /13 DIVISOR = CLK/416
;	STAA	BAUD,X			; RATE IS CLOCK /416 (16M:  2,400  PCM: 1,890)
;	STAB	SCCR2,X			; ENABLE SCI

DELAY	LDAA	#$80			; MASK TIMER OVERFLOW FLAG
	BITA	TFLG2,X			; TEST TIMER FLAG 
	BEQ	DELAY			; LOOP WAITING FOR TIMER TO OVERFLOW

	STAA	TFLG2,X			; CLEAR THE OVERFLOW FLAG

	DEC	TCOUNT			; DECREMENT COUNT
	BNE	DELAY			; LOOP UNTIL EXTENDED COUNT REACHES ZERO

SEND	LDAA	#$F0			; RE-INITIALIZE THE EXTENDED COUNT
	STAA	<TCOUNT			; (~4S 16M) (~5S 12.5829M) DELAY

 	LDY	#HELLO			; POINT AT MESSAGE
TXRDY	LDA	#$80			; TEST TX EMPTY
	BITA	SCSR,X			; WAIT TO TX NEXT CHAR
	BEQ	TXRDY			; LOOP

	LDAA	0,Y			; READ MESSAGE
	STAA	SCDR,X			; TRANSMIT

	INY				; POINT TO NEXT CHAR
	CPY	#HEND			; TEST FOR LAST OF MESSAGE
	BGT	DELAY			; BACK TO 1S WAIT

	BRA	TXRDY			; SEND NEXT CHAR

HELLO	DB	"Hello world!!!"
	DB	$0A
HEND	DB	$0D

TCOUNT	DB	$00			; EXTEND THE TIMER 	

	END	START

When loaded into Tside or Eside ram and executed, this code will output it's message every 5 seconds. After reset or power down no changes will have been made to the PCM.

The attached file is the download frame (Mode $36) that when sent will test the setup. On my system I have named the download file with a .DFR extension (Download FRame). This is not a permitted upload type on this system, so I renamed it .bin. I am sure this will be confusing later but....

I need to spend some time now digesting all the info that has been sent to me and getting hardware together to support download. I should mention also that the opti-spark simulator I built a while back has not yet been tested. I need to solve some questions regarding VATS before that has any hope. I will get there, but this is a long road.

Cheers,
-Tom