OBD2 LT1 XDF $EE EEX creation

**kur4o** · 05-24-2020

I vote for the slowest most reliable option for recovery. $400 bytes of ram is plenty enough. Anyway the original code is set to use 0-1ff as comm loop 300-on as buffer for write message and 200-2ff for code buffer. Each routine is sent on demand. You send erase routine at $200, it is executed and you got positive response, Than send write routine at $200 and overwrite the write buffer.

That way you can make small chunks of code that are send on demand to save ram.

The change of speed can be handled that way. You send some code that change the baud with some wait time after that, for the tool to switch speed.

**Tom H** · 05-27-2020

Hi,

I need a little help understanding the various configurations GM turned out for LT1 SFI. My overall is to help with s/w that un-bricks modules. One of the things I need is to parse binary files and turn them into aldl messages. I would like to understand how you identify the code sets. There are a bunch of questions that pop up...

The computer used for the car is
16188051 1994/5 LT1 OBD1
16181333 1994/5 LT1 OBD1.5
16214399 1996 LT1 OBD2
16242921 1997 LT1 OBD2

Correct?

I see the term $EE and $EEB used for the code. I also see BCC and other terms. Is this explained somwhere? What code are the later 96/7 given.

Once found, I plan to write some small code to extract/separate the Eside and Tside binary, producing files broken up into ALDL messages to drive my bootstrap code.

If all this is explained somewhere, please send me a link.

-Tom

**kur4o** · 05-27-2020

All 94-95 files and pcms are interchangeable. On the average bin you want to parse, first part is tside and second part is eside. there is also ram 0-2000 area in the files. You can cut these and parse 2000-ffff as tside and 12000-1ffff as eside.

96 and 97 files are slightly different but have common structure. Not quite sure if 96 bin will work on 97 pcm.

All 96 files are interchangeable for 96 pcm and all 97 files are interchangeable for 97 pcm.

96-97 files are 0-56 kb tside bank0. 56-88kb bank1 tside. 88-144kb eside.

**Tom H** · 05-29-2020

Originally Posted by kur4o

All 94-95 files and pcms are interchangeable. On the average bin you want to parse, first part is tside and second part is eside. there is also ram 0-2000 area in the files. You can cut these and parse 2000-ffff as tside and 12000-1ffff as eside.

96 and 97 files are slightly different but have common structure. Not quite sure if 96 bin will work on 97 pcm.

All 96 files are interchangeable for 96 pcm and all 97 files are interchangeable for 97 pcm.

96-97 files are 0-56 kb tside bank0. 56-88kb bank1 tside. 88-144kb eside.

Plan to go ahead with 1890 baud as you suggest.

**Tom H** · 05-29-2020

I have completed a few tasks to get closer to the UnBrick software. The 94/5 file format parsing is complete. My routine (posted below) takes the standard bin file as input and produces four files. Two are just the split of the binary into Tside and Eside. The first $2000 bytes are truncated because we do not program those. The second pair of files contain an array of ALDL messages that will drive the 68HC11 code. I have now tested the ALDL messages and they seem to work. Just a bunch more testing to be sure all is correct before moving to test. First focus will be on the Eside of 94/5. Get that going and the rest will follow quickly.

One problem I am running into is with the hardware I use to download with. I have one of those $2 cables for serial. I have tried a bunch of drivers and so on but the noise flag on the 68HC11 sci keeps being set. To get past this, I have eliminated the noise flag from my routine BUT there is something going on & it bugs me I don't know what it is. The noise flag is generated by oversampling the start and stop bits. While I don't see any troubles on the scope, my equipment is hobby quality. The other issue might be level, but I see at least a 3.2V high and a 0.5V low. I wonder about the time base for these USB-->serial ttl cables. Perhaps the bit times wander around?? In any case my workaround of removing the noise flag seems OK. Parity matches every test, so I think it is OK. I would go out and get another cable but it will probably take till fall to get it out of China... Any help or ideas on this (ps I tried a 150pf cap on the tx: no change)

Not quite sure what files to post, I have given the C++ source and the x64 executable. I tested with BSYX_EE.bin which is posted on this site.

-Tom

Would like to post code, but I get "invalid file" do I need to make them all .txt??

**Tom H** · 05-29-2020

Files with extension changed (?)

**In-Tech** · 05-29-2020

Hi Tom,
I'm bad at reading the destructions first so I ran in XP, no worky, then dos cmd prompt, got nag both times that it isn't a 32bit program, duh

Read your post again and then ran on my win7 x64. Of course double click and a dos window popped up and disappeared. Ran from cmd prompt and it told me it needed the input name. Put that in and it ran and showed my cmd prompt without error so checked my root folder and walah the parse worked. Please check if it looks right to you.

p.s. even my win7 lappy has a real serial port if we need to try stuff without a usb adapter. Can do ttl or 232 via a max23x interface.

**In-Tech** · 05-29-2020

Goes to show how little LT1 stuff I have done, I never noticed this in the stock file.

Code:

00003C80 583A EE00 AD00 3206 3900 0045 5241 5349 X:....2.9..ERASI
00003C90 4E47 2046 4C41 5348 204F 4E20 5449 4D45 NG FLASH ON TIME
00003CA0 2053 4944 452E 2020 2020 2020 2020 2020  SIDE.          
00003CB0 2020 2000 0050 524F 4752 414D 4D49 4E47    ..PROGRAMMING
00003CC0 2046 4C41 5348 204F 4E20 5449 4D45 2053  FLASH ON TIME S
00003CD0 4944 452E 2020 2020 2020 2020 2040 0045 IDE.         @.E
00003CE0 5241 5345 2056 5050 2048 4920 4552 524F RASE VPP HI ERRO
00003CF0 5220 2D20 5449 4D45 2053 4944 452E 2020 R - TIME SIDE.  
00003D00 2020 2020 2020 2040 0045 5241 5345 2056        @.ERASE V
00003D10 5050 204C 4F20 4552 524F 5220 2D20 5449 PP LO ERROR - TI
00003D20 4D45 2053 4944 452E 2020 2020 2020 2020 ME SIDE.        
00003D30 2040 0050 524F 4752 414D 4D49 4E47 2056  @.PROGRAMMING V
00003D40 5050 2048 4920 4552 524F 5220 2D20 5449 PP HI ERROR - TI
00003D50 4D45 2053 4944 452E 2020 2040 0050 524F ME SIDE.   @.PRO
00003D60 4752 414D 4D49 4E47 2056 5050 204C 4F20 GRAMMING VPP LO 
00003D70 4552 524F 5220 2D20 5449 4D45 2053 4944 ERROR - TIME SID
00003D80 452E 2020 2040 0046 4C41 5348 2045 5241 E.   @.FLASH ERA
00003D90 5345 2046 4149 4C45 4420 2D20 5449 4D45 SE FAILED - TIME
00003DA0 2053 4944 452E 2020 2020 2020 2020 2040  SIDE.         @
00003DB0 0046 4C41 5348 2050 524F 4752 414D 4D49 .FLASH PROGRAMMI
00003DC0 4E47 2046 4149 4C45 4420 2D20 5449 4D45 NG FAILED - TIME
00003DD0 2053 4944 452E 2020 2040 0046 4C41 5348  SIDE.   @.FLASH
00003DE0 2046 4149 4C45 4420 544F 2050 474D 2054  FAILED TO PGM T
00003DF0 4F20 5A45 524F 202D 2054 494D 4520 5349 O ZERO - TIME SI
00003E00 4445 0000 464C 4153 4820 4552 4153 4544 DE..FLASH ERASED
00003E10 204F 4B20 2D20 5449 4D45 2053 4944 452E  OK - TIME SIDE.
00003E20 2020 2020 2020 2020 2020 2020 4000 464C             @.FL
00003E30 4153 4820 5052 4F47 5241 4D4D 4544 204F ASH PROGRAMMED O
00003E40 4B20 2D20 5449 4D45 2053 4944 452E 2020 K - TIME SIDE.  
00003E50 2020 2020 2020 4000 464C 4153 4820 4D41       @.FLASH MA
00003E60 5920 4E4F 5420 4245 2050 524F 4752 414D Y NOT BE PROGRAM
00003E70 4D45 4420 5749 5448 2054 4845 2020 2020 MED WITH THE    
00003E80 454E 4749 4E45 2052 554E 4E49 4E47 202D ENGINE RUNNING -
00003E90 2050 4C45 4153 4520 5455 524E 204F 4646  PLEASE TURN OFF
00003EA0 2045 4E47 494E 4520 4000 494D 5052 4F50  ENGINE @.IMPROP
00003EB0 4552 204D 414E 5546 4143 5455 5245 5220 ER MANUFACTURER 
00003EC0 2D20 5449 4D45 2053 4944 4520 2020 2020 - TIME SIDE     
00003ED0 2020 4000 494D 5052 4F50 4552 2044 4556   @.IMPROPER DEV
00003EE0 4943 4520 434F 4445 202D 2054 494D 4520 ICE CODE - TIME 
00003EF0 5349 4445 2020 2020 2020 2020 4144 4452 SIDE        ADDR
00003F00 3D20 2020 2020 2052 443D 2020 2020 5752 =      RD=    WR
00003F10 3D20 2020 2020 2020 2020 2020 2020 2020 =

**Tom H** · 05-29-2020

Originally Posted by In-Tech

Hi Tom,
I'm bad at reading the destructions first so I ran in XP, no worky, then dos cmd prompt, got nag both times that it isn't a 32bit program, duh

Read your post again and then ran on my win7 x64. Of course double click and a dos window popped up and disappeared. Ran from cmd prompt and it told me it needed the input name. Put that in and it ran and showed my cmd prompt without error so checked my root folder and walah the parse worked. Please check if it looks right to you.

p.s. even my win7 lappy has a real serial port if we need to try stuff without a usb adapter. Can do ttl or 232 via a max23x interface.

First up, sorry bout the lack of destructions. I forgot to give any. Will do better as this all moves along.

Second, If need be with the push of a button you could have had 32bit. Easy done, just ask.

Last bit, I see your file size listed as 59.9K on the stuff for ALDL. Each chunk ($80 bytes has an overhead of 9 bytes. That means each time a section is loaded, 137 bytes are sent. There should be 448 frames sent which gives a total of 61376 bytes. Not more, not less. Look under file properties and see if it looks like this
FileSize.JPG

Should that not be the case, please let me know and I will fix my screw up. Still, I believe it is working so please check for me.

-Tom

**steveo** · 05-29-2020

really nice work so far, just trying to figure out how it works,

i would have assumed you could just bootstrap it with the existing flash kernel and then once it's booted, just run a flash procedure (like mine) as normal

so i guess i'm trying to figure out why you're dumping aldl messages out to disk

**Tom H** · 05-29-2020

Originally Posted by steveo

i would have assumed you could just bootstrap it with the existing flash kernel and then once it's booted, just run a flash procedure (like mine) as normal
so i guess i'm trying to figure out why you're dumping aldl messages out to disk

Hi,
I did not try to describe the overall plan, because I was not sure what was possible. Ok, so here goes:

My assumption is that a bricked module corrupted FLASH. Obviously if the unit is flooded, burned or electrically shocked there is no afterlife. In a unit where the flash is erased the only operational code resided in a small (0x200 byte) rom. With a few changes to the mode pins, that rom is enabled and permits us to download and execute up to 1K of code. I plan to use that space to initialize the resources we need and to provide a loader (now working). The loader is loosely based on some of the code Kur4o gave us. Using the download & execute mode, I plan to:

- Turn on VPP, checking and reporting input and VPP voltages.
- Check the ID of the FLASH part. If it ain't Intel, it MIGHT work, Intel parts will work.
- Erase the whole FLASH. First write all locations to $00 then do the overall erase
- Using the ALDL messages on disk, program the part

Once done your PCM should be factory fresh & ready to mess with.

Your thoughts?

-Tom