OBD2 LT1 XDF $EE EEX creation

[steveo]

If you program a location that is already programmed the result is not detailed in the datasheet but I would expect an AND function.

i've experimented with overwriting a region before (somewhat by accident, when my block mapping had a bug) and i agree that it does effectively AND, which is handy if you're writing a bunch of blocks out of order, you don't have to worry about any overlap, it resolves itself.

as far as partial erase goes, i've thought about that before, as i do think the chip can handle it (why wouldn't it? we're not using a uv light here...), and it would make it possible to do 100% safe calibration-only writes on ecms that are considered 'full flash only'.

obviously you don't want to have to sit there and request each erase block with serial protocol as the overhead would be really high, so a method where you send a map of erase and non-erase regions then run a more selective write algorithm against that list would be really efficient.

this is all in theory, i don't think i'll ever get around to working on that, especially since a glitch in the erase would certainly brick immediately... it's probably not worth toying with for me

[sherlock9c1]

Howsabout this: Maybe the smart approach is to get Tom's socketless brick fixer working, then we can start playing with selective writes. I have accumulated a decent stack of PCMs here (of both OBD1 and 2) so I could be a beta tester.

I think for tuning, I really like kur4o's hack of putting the MAF, VE and spark tables in RAM. At least with MAF and VE you could make the LT1 PCM self tuning, then if the selective write works, just flash those to EEPROM shortly after. Just dreaming here...

[Tom H]

then we can start playing with selective writes.

For me, selective writes are no problem IF the location has not been programmed ($FF). When a programming a location that is already programmed, you "over charge" the floating gates. With the thin dielectric there is a possibility (likely ??) that you will punch through. Then it is time to socket...
I could go on, but I won't. Folks have tried this with some success so it seems to work. One should always make the location = $FF first then do an erase verify command. This will tell you if the margin in the location is OK. Otherwise the bit can be intermittent (crash/misoperation/piss off owner) I believe for myself that avoiding this is the right thing but if others accept, OK w me. There are alternatives...

1) Run the SCI at a faster rate. I will test this. In the past I have run at 125K with no issues. I will need to calc the divisor for the 12.(*& crystal we have and do a test or two to find the reasonable limit. Disadvantage is the need to switch baud in the middle of loading. I will look into the bootstrap to see if the "fast" rate could be used. I think this option best.

2) Load through the SPI with a small loader. This is more complex. In a system you need to keep the other cpu happy & quiet. Along with this there are more wires and a complex code sequence. I say no to this. Advantage is it would cover 94-97.

3) use class II at 4x 10.4 (average with half 0s and half 1s)... ~41k or so give/take. Only support for 96-7

There are dozens of other ways but these are the easy ones that need no additional H/W.

I will avoid overwriting programmed locations, if you do this, your mileage may vary.

-Tom

[Tom H]

Hi,
I am working through the class II programming routines... about half done. Ran across an interesting patent some time back, just getting around to reading now. This patent details the SPI operation on our boards. This is of course needed for Eside programming in the class II years. I didn't yet check but may also be needed for the early years (but I think not).

Have a look at:https://patents.google.com/patent/US...=US5023778.pdf

-Tom

[Tom H]

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]

Hi,

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

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

[kur4o]

We will separate the response in 2 parts. 1st ones are comming from the main comm loop, The second ones coming from the write,erase code.

from write,erase code we have

8085, there is error writing erasing the requested data.
8086, success send next block on write
8086, erase completed with success

7678, erase progress message.

From the main loop there is bunch more

7441 submode out of range
7443 upload size out of range
7442 upload address out of range
7444 mode34 success, upload enabled

7677 block checksum not good, resend
7678 upload good, will execute code now[for upload and execute]
7673 upload good, send next block[for upload only]

AAE0 on mode a0 request

Some more hint on using IDA.

You can open hex view and synchronize with ida view-a. You can edit the hex data in hex view. You can edit the input file and reload it in ida. It will take into account the mods. You can write code in hex in hex view and disassemble it and check for errors.
You can copy hex data from hex view.

Press space and it will switch the graph view. Extremely handy to trace code flow.

The file that have no extension in the archive I have uploaded is the hex file being disassembled. That is the load file, You can modify it and reload in ida from file/load file/reload the input file/

[Tom H]

Yeah but you could recalc the checksum & update that byte.
Mitch

If you need to fix a checksum, just program an un-used $FF location anywhere within the checksum range such that the sum is fixed. Harder if it is 16bit, you then need to mess with 256 locations. Still, up high there are largeish blocks of blank.

-Tom

[Tom H]

Hi,
I have completed my look through the '96-7 Tside FLASH programming code & commented the operation. The comments are best efforts only, I hope they are of use to you.

Big thanks to kur4o for his help with the tricky bits.

-Tom

[Tom H]

Hi,
I have completed my look through the '96-7 Eside FLASH programming code & commented the operation. The comments are best efforts only, I hope they are of use to you. It is interesting to look at the Programming Exec which has a mode (upload $35) that is new to me. I am thinking to write code for the upload section, but first I am planning to test my theory on an easy way to unbrick.

I am posting the Tside again, this time with a correction where code was cut out.


-Tom

[kur4o]

Nice work on the comments, much better to understand and complete.

Mode 35 is a built in mode for reading bin over odb2 port. Some of the earlier obd2 pcms have that built in the code, but later it got removed.

[Tom H]

I need some confirmation....

Message format over aldl is [DEVICE ID] [LENGTH] [MODE] [MESSAGE …] [CHECKSUM]

for mode $06 and message $55, does this mean command in progress, not completed yet?

THX -Tom

[steveo]

yep, or in other words just to tell the tester 'wait until next message'

in practice, the only code that seems to use it is the erase routine (being the only code that could potentially run long enough to need it)

[Tom H]

Some small progress to tell you about...

This morning I was able to download all the flash routines while in bootstrap mode. UnBrick is not yet alive, but showing signs of life. So far, just the ESide... still waiting for parts from china to get to the TSide, w a i t i n g & w a i t i n g
-Tom

[Tom H]

Question regarding mode 6, I happened on an unusual fail. I wanted to execute code without download. That is, a transfer of 0 data, execute at the location. Please confirm if you agree or don't...

Consider a download & execute message of $F4 $57 $06 $00 $00 $AE

$F4 passes the test for valid device
$58 passes the length test (>$56)
$06 mode 6
$00 address h
$00 address l
$AE checksum

The routine assumes the download isn't 0 and writes the checksum as if it were data. Then decrements the count which will underflow. The next 256 characters sent will over-write. The 257th byte it gets will be interpreted as checksum and will likely fail and return to the main loop IF it has not been overwritten. Also possible that the 256 writes disturb ram used by this code and crash.
I think: All code that permits download should also include a test for this and prevent it.

Do I have this right?
-Tom