1997 F-Body ECM

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

**Tom H** · 03-21-2019

My project continues, but with a number of twists and turns

After finding that the ELM cable I had been using to test my PCM was not capable of download, I looked into what options there were for replacement. First, I wanted to understand VPW to see if the elm could be re-programmed. The re-programming part turned out to be a dead end. The cable I am using is a clone and not likely the PIC part I expected. Even if I was to learn to re-program it, I would still need a full suite of tools to assemble code and some sort of JTAG programmer to get the code into the part. This all is another project on it's own.

I have a number of test boards with 68HC11 parts on them that run at 16MHZ (4M eclock). I read through the J1850 spec and wrote code to transmit frames of a length that is usable. Debug of this went OK until I tried to connect it to the ELM327. At that point, the ELM could not see the frame I sent. Turns out that the elm transmits a frame, then listens to the bus for a short (under a second even with the AT ST option set to $FF) time. After this it goes into a loop looking for input from it's serial port to the PC terminal. <sigh>
I was able to send a frame through the elm327 and reply through my proto board. It looks like if I am to use this technique, I will need to write VPW receive code also and replace the whole elm327. I feel like I made a mistake starting with the elm327 in the first place.

Commercially available solutions are $300 or so and still have limitations. All told there is one answer I feel works best for me that I will describe. First though a number of things I noticed from the J1850 spec and BDLC datasheet

- J1850 limits the frame size to 12 thus the programming routines are outside the standard
- There is no VPW at 41.6 described in the standard. (Does anyone know for sure if the 41.6 is VPW or PWM from the standard?)
- The BDLC data sheet has almost no description of 4X timing and so on. This is outside the J1850 standard (I think)
- The VPW 10.4 does not actually deliver 10.4K bits/second. Pulse width and level in combination describe the bits. As such the data rate varies between 7,812 and 15,625 the named bit rate of 10.4 is an average.

For me, given that GM has gone outside the regular standard, the best solution is to use the same MC68HC58 DLC chip that they do. Once I have completed my test setup, I will get an old PCM from the wreckers. That should be about $30 or so. I plan to remove the Eside board and re-program the Tside to become my interface. This will eliminate any need to build hardware. Also this is much easier than trying to collect the parts and produce a circuit board.
The finished interface will support 4X mode, frames of any length for programming. I need to do all this just to get back to the original project I started on.....

**kur4o** · 03-21-2019

This is the cheapest interface that can work for you. It was used to flash ls1 pcms, so it is proved to work with larger messages.

https://www.scantool.net/obdlink-sx/

The only drawback, it doesn`t support x4 mode.
There is a free tool to load an updated firmware. The firmware file is available to look at also. I am not sure how it is compiled but upon a request you might be able to get a source code and make it x4 compatible.

Pcm can be flashed in x1 mode, so that shouldn`t bother you. It is just 4 times slower. With that chip size the write times will be acceptable and close to obd1 pcm write time.

The main difference between x1 and x4 is that in x4 mode the rounding of the signal is removed and it is true square type of transition and the timings are cut by 4.

The 12 bytes frame size limit is software limitations. When the PCM enters datablock mode the limitation is removed and you can send as long as you want.

**kur4o** · 03-22-2019

I found interesting thread for a pcm with similar components.

https://pcmhacking.net/forums/viewtopic.php?f=8&t=4671

It has the same memory chip as tside and bank switching look similar.

Raw bin file is scrambled due to address line swapping. Did you managed to find something about that issue.
One thing that is still missing in obd-1 pcm hacking is a bin descrambler from raw bin to usable bin.

**Tom H** · 03-22-2019

Originally Posted by kur4o

This is the cheapest interface that can work for you. It was used to flash ls1 pcms, so it is proved to work with larger messages.

https://www.scantool.net/obdlink-sx/

The only drawback, it doesn`t support x4 mode.
There is a free tool to load an updated firmware. The firmware file is available to look at also. I am not sure how it is compiled but upon a request you might be able to get a source code and make it x4 compatible.

Pcm can be flashed in x1 mode, so that shouldn`t bother you. It is just 4 times slower. With that chip size the write times will be acceptable and close to obd1 pcm write time.

The main difference between x1 and x4 is that in x4 mode the rounding of the signal is removed and it is true square type of transition and the timings are cut by 4.

The 12 bytes frame size limit is software limitations. When the PCM enters datablock mode the limitation is removed and you can send as long as you want.

This device looks OK... the message limit is 47 bytes I think (from manual). Given this, the overhead is 3 for header, 7 for message, 2 for sixteen bit checksum. I think the checksum is provided by the stn1100 so 35 bytes could be transferred in a frame.
This would mean that you would send multiple frames for the download with the last of them having download and execute bit set.

Is this the way it works (?)
-Tom