Page 4 of 10 FirstFirst 123456789 ... LastLast
Results 46 to 60 of 148

Thread: OBD2 LT1 XDF $EE EEX creation

  1. #46
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    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

  2. #47
    Fuel Injected!
    Join Date
    Sep 2012
    Location
    Huntsville, AL
    Posts
    237
    I agree - no reason to change it if the data doesn't care and there's already a precedent.

  3. #48
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Quote Originally Posted by kur4o View Post
    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:
    Code:
    *************************************************
    * 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

  4. #49
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    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
    Attached Files Attached Files

  5. #50
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    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

  6. #51
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    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.
    Attached Files Attached Files

  7. #52
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    757
    Quote Originally Posted by Tom H View Post
    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.
    1990 Corvette (Manual)
    1994 Corvette (Automatic)
    1995 Corvette (Manual)

  8. #53
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Quote Originally Posted by NomakeWan View Post
    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

  9. #54
    Fuel Injected! Terminal_Crazy's Avatar
    Join Date
    Oct 2015
    Location
    Lancashire England
    Posts
    410
    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
    '95 Z28 M6 -Just the odd mod.
    '80 350 A3 C3 Corvette - recent addition.

  10. #55
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Quote Originally Posted by kur4o View Post
    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...
    Code:
    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

  11. #56
    Fuel Injected!
    Join Date
    Nov 2017
    Location
    Californiacation
    Age
    57
    Posts
    811
    Quote Originally Posted by Terminal_Crazy View Post
    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
    The quick answer is no. You can clear, or set, even a bit of a byte. A little bit longer answer(see what I did there? ) is did you correct the checksum for the change you made and the CEL is flashing rapidly cuz it is very unhappy The software could do a compare of your old file vs new file and write just that. If much has changed, that would probably be futile, time wise. Shit, you could write an idling bootloader, disable the checksum, send executable packets and almost have real-time emulation. Ummmmm this IS freeware, right?
    -Carl

  12. #57
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Quote Originally Posted by Terminal_Crazy View Post
    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
    Hi Mitch,

    I have not gone through the AMD datasheet, but the Intel part requires a full erase. If a cell is FF, you can program it. Programming only takes 1s and makes 0s. If you program a location that is already programmed the result is not detailed in the datasheet but I would expect an AND function. The erase command does indeed program every bit in the array to zero before erase. This is done to make the threshold the same for all cells. When you do the verify commands an offset threshold is used to make sure the stored charge is enough for the life of the part. To be safe, erase as a whole and program locations that are FF only. The exception to the second part is what is done to erase.

    It is my guess that the ECMs were programmed with all the code when the parts were soldered to the board and that calibration was added later perhaps on the assembly line. If you want to overwrite the calibration a full erase then program cycle is needed. It would be interesting if there are some folks who worked for GM at the time we could talk to.

    -Tom

  13. #58
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Quote Originally Posted by In-Tech View Post
    The quick answer is no. You can clear, or set, even a bit of a byte. A little bit longer answer(see what I did there? ) is did you correct the checksum for the change you made and the CEL is flashing rapidly cuz it is very unhappy The software could do a compare of your old file vs new file and write just that. If much has changed, that would probably be futile, time wise. Shit, you could write an idling bootloader, disable the checksum, send executable packets and almost have real-time emulation. Ummmmm this IS freeware, right?
    Hi Carl,

    Thank you Carl, I missed a key bit of info. You can erase and erase verify a single loc. My bad.
    -Tom

    xxxxxxxxxxxxxxxxxIf you program locations that are not FF and 0s transition to 1s the cell is internally not correctly
    xxxxxxxxxxxxxxxxxxprogrammed. This can result in heat sensitivity and worst case a bricking. Suggest we follow the data sheet,
    xxxxxxxxxxxxxxxIf I understand what I am reading their caution is "CAUTION: The algorithm must be followed to ensure proper and reliable operation of the device."
    xxxxxxxxxxxxxI have not tested this but: If a cell that is programmed 00 is written to FF and an erase verify command is run, I think you will find faults from time to time. The "margin threshold" won't be met.



    Can you suggest where I can find programming directions that indicate programming 0 --> 1 is OK?

    -Tom
    Last edited by Tom H; 05-07-2020 at 02:33 PM.

  14. #59
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    Quote Originally Posted by Tom H View Post
    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.

  15. #60
    Fuel Injected! Terminal_Crazy's Avatar
    Join Date
    Oct 2015
    Location
    Lancashire England
    Posts
    410
    Quote Originally Posted by In-Tech View Post
    The quick answer is no. You can clear, or set, even a bit of a byte. A little bit longer answer(see what I did there? ) is did you correct the checksum for the change you made and the CEL is flashing rapidly cuz it is very unhappy
    Yeah but you could recalc the checksum & update that byte.

    Quote Originally Posted by In-Tech View Post
    The software could do a compare of your old file vs new file and write just that. If much has changed, that would probably be futile, time wise.
    Steveo's EEHack does to a small extent

    Quote Originally Posted by In-Tech View Post
    Shit, you could write an idling bootloader, disable the checksum, send executable packets and almost have real-time emulation. Ummmmm this IS freeware, right?
    Great, will that be ready by tea time? :-)

    I wish I knew more about these sytems, so I appologise if I throw in some random comments

    There are a few of us who do follow these discussions even if we're sat here with a dumb expression on our face sometimes.
    If the processors were ARM based, i'd be able to follow some of the dissassembly better.


    Mitch
    '95 Z28 M6 -Just the odd mod.
    '80 350 A3 C3 Corvette - recent addition.

Similar Threads

  1. XDF Creation / Editing - How To????
    By B52Bombardier1 in forum OBDII Tuning
    Replies: 5
    Last Post: 02-28-2020, 02:04 AM
  2. new to obd2
    By myburb in forum OBDII Tuning
    Replies: 0
    Last Post: 05-28-2018, 05:54 AM
  3. DHP/AVT-852-002 Rev L OBD2 programmer $250
    By SappySE107 in forum Buy - Sell - Trade - Wanted
    Replies: 2
    Last Post: 02-03-2018, 09:25 AM
  4. flashing OBD2 ECU?
    By vwnut8392 in forum OBDII Tuning
    Replies: 4
    Last Post: 11-25-2017, 01:43 AM
  5. WTB TunerCats II (OBD2)
    By XRelapse13 in forum Buy - Sell - Trade - Wanted
    Replies: 0
    Last Post: 12-16-2014, 08:26 PM

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •