OBD2 LT1 XDF $EE EEX creation

[kur4o]

Hi kur4o,
My version of ida is so old I cannot view your work. Could I talk you into saving/produce as html so I could view it? My old version of ida used to be able to do that with a keystoke.

You can check here for a way to open the files or

if you are still having troubles here are some htmls. There is options to export to other formats but don`t what they are.


I managed to find that there are 2 revisions for the 96-97 files[1 for 96 and 1 for 97]. This is valid only for the latest updates by gm so any older p/n for the vin might have different layout.

I am looking for stock bins to confirm there isn`t any older revisions.


For now at least 2 xdfs will be needed.


We can transfer the thread`s topic to xdf and flash creations and we will be spot on with the conversation without spamming the thread.

I hope sherlock9c1 doesn`t mind.

[sherlock9c1]

No worries. Moderators, organize away.

Kur4o, I was just realizing that the BIN I was pattern-matching on was from Tunercat OBD2 (now JET DST). But is the organization of the file arbitary, dependent on what order the EEPROM memories are read? So the blocks might be re-arranged in a different order than what Tunercat OBD2 did?

[kur4o]

I am not sure about the tunercat layout, but the best one might be

tside 2000 ram + bank 0 + bank 1 + bank 2 +eside 2000 ram + eside rom.

For better offset experience eside might be first than tside full binary like

eside full bin with ram + tside full bin with ram.

[steveo]

if we need to standardize we should try to stick with what is already in use if possible, that way tunercat/jet dst bins will also work with whatever we do instead of having to convert between formats like we did with lt1edit/tunercattunerpro

[sherlock9c1]

I agree - no reason to change it if the data doesn't care and there's already a precedent.

[Tom H]

We can transfer the thread`s topic to xdf and flash creations and we will be spot on with the conversation without spamming the thread.

OK, here we stay. I have gone through a bunch of the code. Seems like a straight forward implementation of Intel's quick pulse programming / quick erase. Makes figuring it out a breeze.

I am still working through the '95 but I imagine the '97 must be very similar. The routine that is named ERASE2_sub_31D in your file represents the first two blocks of the flow chart. The intent is to program the whole array to zero. Here is the commented code I come up with:

*************************************************
* ERASE
* USE QUICK PULSE PROGRAMMING TO ZERO THE ENTIRE
* FLASH ARRAY. AS PER FIG. 4 & 5 OF THE DATA SHEET
*************************************************
031D  9D 29          	JSR	@$29		; INITIALIZE OC1: 20MS

031F  4F             	CLRA			; 
0320  B7 03 68       	STAA	$0368		; 

0323  DE 12          	LDX	@$12		; FLASH END ADDRESS
0325  08             	INX			; 

0326  09             	DEX			; PROGRAM NEXT LOCATION

0327  4F             	CLRA			; INITIALIZE PULSE COUNT
0328  36             	PSHA			; 

0329  9D 26          	JSR	@$26		; CHECK AND CLEAR OC1

032B  32             	PULA			; 

032C  27 0F          	BEQ	$033D		; OC1 MATCH NOT SET
032E  7C 03 68       	INC	$0368		; 
0331  F6 03 68       	LDAB	$0368		; 
0334  C1 05          	CMPB	#$05		; 
0336  25 05          	BCS	$033D		; 

0338  8D D0          	BSR	$030A		; SEND IN PROGRESS MESSAGE

033A  7F 03 68       	CLR	$0368		; 

033D  9D 1D          	JSR	@$1D		; MAKE FLASH OE INACTIVE

033F  C6 40          	LDAB	#$40		; FLASH COMMAND SEQUENCE
0341  E7 00          	STAB	$00,X		; COMMAND: SET UP PROGRAM
0343  C6 00          	LDAB	#$00		; 
0345  E7 00          	STAB	$00,X		; PROGRAM LOCATION TO $00

0347  9D 17          	JSR	@$17		; RESET WATCHDOG TIMERS

0349  C6 C0          	LDAB	#$C0		; FLASH COMMAND: PROGRAM VERIFY
034B  E7 00          	STAB	$00,X		; 

034D  9D 1A          	JSR	@$1A		; MAKE FLASH OE ACTIVE

034F  E6 00          	LDAB	$00,X		; READ BACK LOCATION
0351  27 07          	BEQ	$035A		; SUCCESS, LOCATION IS $00

0353  4C             	INCA			; INCREMENT PULSE COUNT
0354  81 19          	CMPA	#$19		; 25 PULSES
0356  23 E5          	BLS	$033D		; TRY AGAIN
0358  20 09          	BRA	$0363		; PROGRAMMING ERROR

035A  9C 10          	CPX	@$10		; FLASH BASE ADDRESS
035C  26 C8          	BNE	$0326		; LOOP THROUGH REST OF ARRAY

035E  CC 00 00       	LDD	#$0000		; NO MESSAGE, SUCCESS ARRAY IS NOW
0361  20 03          	BRA	$0366		; ZEROED OUT, READY FOR QUICK PULSE ERASE

0363  CC 06 06       	LDD	#$0606		; MODE 6 MESSAGE: PROGRAMMING ERROR

0366  39             	RTS			; DONE

0367  00             				; 
0368  00             				;

I assume the routines that are given between $0400 and $1810 are for the GM test gear. Planning to ignore...

-Tom

[Tom H]

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

-Tom

[Tom H]

Looking at the 96-97 code, I think I understand the Tside flashing. Once loaded, the Flash can be checked for manufacturer and device. Based on that an algorithm is selected. I believe in all our cases that will be Intel. Please let me know if anyone has AMD parts.
Once the part is known, it is programmed to all zeros before erasing it to the factory state ($FF). It looks as if there is about 1K of buffer in the PRU to pass the new data to. The buffer is formatted with three extra bytes. Bytes are target address in flash high, then low and last is byte count. In this suggested case, byte count would be 128 or $80. This would permit 8 buffers of $80 to fit in ram for programming. Total buffer size will be ($80 + 3) * 8 = $418 bytes total. I will propose that the address of the buffer would start at $1BE8 thus it would end at the top of PRU ram $1FFF. Eight calls to the programming routine would yield 1K bytes programmed. I wonder if there is anything to be gained by buffering 1K or if buffering 128 would be more straight forward. Your thoughts?
TSide page 0 ranges from $2000 - $FFFF. Since there is no need to program the first 8K, the buffer (1K) will need to be filled 56 times to complete programming the page. Similarly, page 1 ranges from $8000 through $FFFF. There is no need to program the first 32K.
The result of all this is that a 1K buffer needs to be replenished 88 times on the TSide. That is 704 calls to the programming routine.
Again perhaps filling a 128 byte buffer 704 times will make the code easier. I believe the slowest part of this will be the serial transfer from PC to PCM.

Trying to size the time it will take to program... We need to transfer 88K bytes. That is just over 90K bytes. Each byte is sent as hex digits (that doubles the byte count). With overhead of ID, Count....checksum, I figure that programming the TSide needs to move something in the order of 200K bytes PC to PCM. There will also be 704 replies if all goes well that need to be processed. From this crude figuring, it looks like about 250K characters need sending/receiving & processing. That looks to me like it might take 8 - 10 minutes.

Is 8-10 minutes reasonable & expected (or has my math gone off the rails).

I plan to try this out once my parts arrive from China. It takes so long to ship things... If this is a success, I will be able to suggest a way to reprogram a brick without de-soldering the FLASH. Still it won't be the easiest thing because it will access the test connector. This will require the PCM to be opened up and so on.

-Tom

[kur4o]

The time you came up is way off. It will be like 1-2 min max in x4 mode.

Here is a list of simulated write with the commands send over the bus.

Chipid id used to identify the chip. It is always intel in these PCMs, the tool decides how to proceed if the chip is not correct. I guess the amd id is there so there isn`t a crash response if you try to program the wrong pcm. There isn`t any amd code to handle erase and write of amd chips.

Erase is done in 2 parts. First set all bits to 1. Second part turns all to 0 and than to 1. Something with intel quick erase. The routine manages erase exactly by the data in intel flash chip manual.

Note that each flash routines like erase, vpp, checksum, chipid and so on are loaded at 1810 buffer one by one. The bin upload buffer is at 1b00. The flash routine have built in $500 bytes length message.
The header before each uploaded block is

BD 18 1D 20 00 04 00

18ad is the start address of write routine.
2000 is the address where data will be programmed
0400 is the length of the data to be programmed

Usually 0-1fff area is not programmed at all. That also includes bank2 0-8000 area. Total data transferred is 88kb for tside.

[Tom H]

The time you came up is way off. It will be like 1-2 min max in x4 mode.

Here is a list of simulated write with the commands send over the bus.

Chipid id used to identify the chip. It is always intel in these PCMs, the tool decides how to proceed if the chip is not correct. I guess the amd id is there so there isn`t a crash response if you try to program the wrong pcm. There isn`t any amd code to handle erase and write of amd chips.

Erase is done in 2 parts. First set all bits to 1. Second part turns all to 0 and than to 1. Something with intel quick erase. The routine manages erase exactly by the data in intel flash chip manual.

Note that each flash routines like erase, vpp, checksum, chipid and so on are loaded at 1810 buffer one by one. The bin upload buffer is at 1b00. The flash routine have built in $500 bytes length message.
The header before each uploaded block is

BD 18 1D 20 00 04 00

18ad is the start address of write routine.
2000 is the address where data will be programmed
0400 is the length of the data to be programmed

Usually 0-1fff area is not programmed at all. That also includes bank2 0-8000 area. Total data transferred is 88kb for tside.

Hi Kur40,

I need to clarify my post for you, it was at best confusing. For all the 94-97 PCMs a module that is truly bricked has no access to the data link controller. This means the J1850 is not available which means no x4 mode. In this case you need to use the SCI. I failed to note when the thought context switched between understanding of the later code and un-bricking based on sci.

You will notice two commands sent to the flash prior to erase...

0200  9D 1D          	JSR	@$1D		; MAKE FLASH OE INACTIVE

0202  86 AA          	LDAA	#$AA		; AMD UNLOCK COMMAND 1
0204  B7 55 55       	STAA	$5555		; INTEL IGNORES

0207  86 55          	LDAA	#$55		; AMD UNLOCK COMMAND 2
0209  B7 AA AA       	STAA	$AAAA		; INTEL IGNORES

020C  86 90          	LDAA	#$90		; INTEL/AMD ID COMMAND
020E  B7 55 55       	STAA	$5555		;

The unlock feature is present only in the AMD part but is ignored by the Intel part for compatibility. From the datasheet and the '94-5 code you sent the erase sequence programs 0s then erases to 1s. I am not far enough into the 96-7 code to answer this, but expect it matches the Intel flow chart.

Using 1K ($400) as a transfer size in a non-bricked 96-7 makes perfect sense. The GM implementation of J1850 permits long frames. This reduces overhead and speeds the process. In this case we should do the same, 88 downloads of 1K.

Going back to the bricked module flashing, to do this, the program needs to bootstrap a loader. When the loader is in place there will be a need to increase the baud rate. The bootstrap baud rate with the stock crystal works out to 1888 baud. Nice round number. When I wrote yesterday I envisioned moving to 8192 which is the standard. It may however be possible to move to a higher rate. Since this is single purpose and not integrated with the ABS/Dash/BCM/whatever, it will be interesting to test at 16384 or 32768. I need to look at the baud rate generator to see what faster speeds fall out of it that the rest of the module can support.

I am now off to look at the later code.

-Tom

[NomakeWan]

If this is a success, I will be able to suggest a way to reprogram a brick without de-soldering the FLASH. Still it won't be the easiest thing because it will access the test connector. This will require the PCM to be opened up and so on.

-Tom

Looking forward to this, and agreed that it currently is taking an insane amount of time to get anything from overseas unless you pony up for private couriers like DHL or FedEx. I order stuff from China and Japan often so I'm definitely feeling your pain right now.

I wonder if this is actually how new PCMs are factory-programmed. Obviously won't be a big deal if that's how we have to do it, but I've always wondered how the dealership did it. I somehow can't imagine your typical service tech cracking open a PCM and jumping onto some PCB pins to flash an EEPROM. Plugging into the PCM's external ports or the ALDL connector, though, those seem more likely.

In any event, carry on, I love everything you guys are doing even though it's for the OBDII cars. Both because I might end up owning one one day, and because lots of this will probably end up trickling down to the 94-95 PCMs too.

[Tom H]

Looking forward to this, and agreed that it currently is taking an insane amount of time to get anything from overseas unless you pony up for private couriers like DHL or FedEx. I order stuff from China and Japan often so I'm definitely feeling your pain right now.

I wonder if this is actually how new PCMs are factory-programmed. Obviously won't be a big deal if that's how we have to do it, but I've always wondered how the dealership did it. I somehow can't imagine your typical service tech cracking open a PCM and jumping onto some PCB pins to flash an EEPROM. Plugging into the PCM's external ports or the ALDL connector, though, those seem more likely.

In any event, carry on, I love everything you guys are doing even though it's for the OBDII cars. Both because I might end up owning one one day, and because lots of this will probably end up trickling down to the 94-95 PCMs too.

Hi,
There were several ways we used to handle flash way back when. Easy, was to have the chip vendor pre-program the parts on their final test. Downside was that last minute changes and variation of the final product would mess up the plan. You needed high volume (not a problem for GM) and some setup cash. Second thing that could be done was to program on the "bed of nails" tester. These things have a custom interface board with hundreds of spring loaded points. Through the points you can generate the wave forms to program the part. Often boards were tested and programmed in one step. Last and slowest was to move things in serial.

If I were guessing, I think that the program section would be factory program and the calibration would be programmed after. Where the calibration was not programmed (all FFs), just that section could be programmed on the line. The amount is smaller and would take only a minute or so. Well, so much for my guesses.

Earlier I wrote about a way to revive bricked modules. This should work for all the PCMs with this configuration 94 through 97. The interesting thing with the later cars is that we can now see the programming software and use it for updates. This should not require removal of the boards from the case, that is just for bricks.

C-Tom

[Terminal_Crazy]

Do the flash roms HAVE to be fully zero'd and 0xFF set first ?
I always thought it was a bit crap that you couldn't just flash individual cells & update them.

Mitch

[steveo]

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

thanks so much for doing that, that's very detailed. definitely fills in a lot of blanks that i never understood before.

[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