OBD2 LT1 XDF $EE EEX creation

**Tom H** · 05-01-2020

Hi Steveo, Rocko
For those with bricked PCMs...

Before you remove the flash from the board, I think that there is a better way to refresh the module IF you are willing to wait a bit. Here is why:

-Removing the FLASH chip opens the conformal coating of the board. Without this waterproof layer, condensation will result in intermittent problems/crashes.
-Sockets (if used) are often not reliable in vibration

Should you agree with that, All the signals needed to program the flash are available at the tester connector. This connector is unpopulated on my board and I have already used it to force my code into ram & run test routines. I believe the same thing can be done with a programming routine. I can not promise to work on this straight away, but it is something I plan to work through. The routine for the internal boot loader is published in the ref manual and works well for me. Although the later boards communicate with the outside world using class II, the regular serial NRZ can still be used with the boot loader to solve any loss of flash code that has happened.

just an idea...

-Tom

-Tom

**steveo** · 05-02-2020

we have often suspected this is possible

would love for someone to try or get more details/theories on how

Originally Posted by Tom H

Hi Steveo, Rocko
For those with bricked PCMs...

Before you remove the flash from the board, I think that there is a better way to refresh the module IF you are willing to wait a bit. Here is why:

-Removing the FLASH chip opens the conformal coating of the board. Without this waterproof layer, condensation will result in intermittent problems/crashes.
-Sockets (if used) are often not reliable in vibration

Should you agree with that, All the signals needed to program the flash are available at the tester connector. This connector is unpopulated on my board and I have already used it to force my code into ram & run test routines. I believe the same thing can be done with a programming routine. I can not promise to work on this straight away, but it is something I plan to work through. The routine for the internal boot loader is published in the ref manual and works well for me. Although the later boards communicate with the outside world using class II, the regular serial NRZ can still be used with the boot loader to solve any loss of flash code that has happened.

just an idea...

-Tom

-Tom

**kur4o** · 05-02-2020

Here are the 96-97 ones disassembled and offset. Not too commented but labelled for easy identification. Code is very similar to 94-95 with some extra crap added.

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

Originally Posted by kur4o

Here are the 96-97 ones disassembled and offset. Not too commented but labelled for easy identification. Code is very similar to 94-95 with some extra crap added.

Hi,

Would it be possible to get the binary for the flash routines?

-Tom

**kur4o** · 05-02-2020

Sure, here it is.

**Tom H** · 05-09-2020

Originally Posted by kur4o

Sure, here it is.

Hi
Probably of interest to only me, but...

I have been using the IDA file as a binary. It *seemed* ok, and I was able to understand the way it worked. I have found an issue though, The IDA replaces named locations with a token. My disassembler takes that token as the address because it expects a binary. If anyone needs a binary, IDA has a built in generator that produces the file in less than a second. Should you need a binary for some purpose, hit FILE --> PRODUCE FILE --> CREATE EXE FILE. It's done.

Kur4o, thank you for these files. Saved a bunch of time not having to re-write!

-Tom

**Tom H** · 05-10-2020

Hi,

Still at looking through the '97 Flash code. Are the response codes known? Look at this code segment

Code:

*************************************************
* SEND MESSAGE: 
*************************************************
1B80  CC 80 86           LDD    #$8086        ; SUB-PARAMEATER 80 = D/L & EXECUTE
1B83  DD 15              STD    @$15        ; 

1B85  CC 18 76           LDD    #$1876        ; TSIDE MODE 36 REPLY
1B88  DD 13              STD    @$13        ; 

1B8A  C6 06              LDAB    #$06        ; MESSAGE LENGTH
1B8C  BD 02 3E           JSR    $023E        ; SEND MESSAGE TO DLC

1B8F  CE 03 FF           LDX    #$03FF        ; ZERO THE INTERNAL RAM
1B92  6F 00              CLR    $00,X        ; 
1B94  09                 DEX            ; 
1B95  26 FB              BNE    $1B92        ; 
1B97  6F 00              CLR    $00,X        ; 

1B99  CE 40 00           LDX    #$4000        ; SEND BREAK SYMBOL
1B9C  FF 10 60           STX    $1060        ; FROM DLC

1B9F  20 FE              BRA    $1B9F        ; LOOP UNTIL WATCHDOG HITS


This results in a reply of 6C F0 18 76 80 86
                            |  |  |  |  |  |
Priority -------------------   |  |  |  |  |
Destination tester ------------   |  |  |  |
Source TSide ---------------------   |  |  |
Reply to mode 36 -------------------    |  |
Submode D/L & execute ------------------   |
Code unknown to me ------------------------

Do we have any info regarding the reply code? The one shown sends the message just before returning to normal operation with a watchdog reset. My guess it is a "done and happy" message.

-Tom

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

Originally Posted by Tom H

Hi,

Would it be possible to get the binary for the flash routines?

-Tom

Ooops, now understanding the files included ARE the binarys. I will comment the code and post... -Tom

**sherlock9c1** · 05-03-2020

Well I got through another 40 parameters. I haven't dug into the disassemblies yet, just using BeyondCompare on the BIN files to do pattern matching between the files. There are definitely a few strange moves where the data will be bit for bit and then all of a sudden ONE value will change. Once I start looking at the disassemblies I'm sure it'll fill in the gaps.

**Tom H** · 05-03-2020

Hi,

Started looking at the FLASH code. It is just what would be expected (for once). I am slowly working through some of the routines. I began with the '95 code because it is based on ALDL. For those with bricked modules who would like to revive them using bootstrap, these are the routines you will need.

A quick update on some of what I am looking at: I have found a number of sent messages and a sequence for receive. Do we know all the messages for modes 5 & 6 of aldl?

I have gone through the checksum section and found a message: 06 AA <checksum> . I believe length is inserted and the message becomes a mode 6 with content of AA <checksum> . Sound right??

Here is that section of code:

Code:

*************************************************
* CHECKSUM
*************************************************
1C2E  FE 1C 7A       	LDX	$1C7A		; CHECKSUM RANGE END ADDRESS
1C31  FF 1C 7C       	STX	$1C7C		; COPY END ADDRESS

1C34  FE 1C 78       	LDX	$1C78		; CHECKSUM RANGE START ADDRESS

1C37  CC 00 00       	LDD	#$0000		; INITIAL VALUE OF SUM IS ZERO

1C3A  18 CE 05 DC    	LDY	#$05DC		; WATCHDOG REFRESH COUNT:1500
1C3E  09             	DEX			; START -1

1C3F  08             	INX			; NEXT BYTE

1C40  EB 00          	ADDB	$00,X		; KEEP SUM IN ACCD
1C42  89 00          	ADCA	#$00		; ADJUST FOR CARRY OUT OF LS

1C44  18 09          	DEY			; DECREMENT WATCHDOG REFRESH COUNTER
1C46  26 06          	BNE	$1C4E		; COUNTER NOT EXPIRED

1C48  9D 17          	JSR	@$17		; RESET WATCHDOG TIMERS
1C4A  18 CE 05 DC    	LDY	#$05DC		; WATCHDOG REFRESH COUNT:1500

1C4E  BC 1C 7C       	CPX	$1C7C		; LAST BYTE OF CHECKSUM
1C51  26 EC          	BNE	$1C3F		; LOOP THROUGH BLOCK

1C53  3C             	PSHX			; DECREMENT STACK 4 PLACES
1C54  3C             	PSHX			; 

1C55  30             	TSX			; INDEX TO STACK
1C56  ED 02          	STD	$02,X		; OVERWRITE WITH MESSAGE MODE
1C58  CC 06 AA       	LDD	#$06AA		; MODE 6 MESSAGE: UPLOAD,EXECUTE PROGRAM
1C5B  ED 00          	STD	$00,X		; 
1C5D  C6 04          	LDAB	#$04		; MESSAGE CONTENT, 4 BYTES: CHECKSUM
1C5F  9D 14          	JSR	@$14		; SEND CHECKSUM MESSAGE

1C61  38             	PULX			; RESTORE STACK POSITION
1C62  38             	PULX			; 

1C63  39             	RTS			; DONE

1C64  00 00             			;



*************************************************
* DO NOT REFERENCE $1C75: LIKELY CRASH SITE
*************************************************
1C75  BD 1C 2E       	JSR	$1C2E		; NOT REFERENCED

1C78  0000					; CHECKSUM RANGE START
1C7A  0000					; CHECKSUM RANGE END
1C7C  0000					; WORKING CHECKSUM RANGE END

* NEXT BYTE IS INTERESTING IN THAT IT IS NOT
* REFERENCED BY CODE. I BELIEVE THAT THIS IS 
* A MISPLACED INSTRUCTION "RTS" THAT IS INTENDED
* TO BE PAIRED WITH THE CODE AT $1C75. IN ANY
* CASE IT IS UNUSED AND AS LONG AS $1C75 IS 
* NEVER REFERENCED, IT WILL NOT CAUSE HARM.
* IF $1C75 IS REFERENCED, THE CPU WILL INTERPRET
* THE RANGE START/END AS CODE AND CRASH.
1C7E  39					; NOT REFERENCED

-Tom