Printable View
I have started working on an OBD2 LT1 XDF for use in TunerPro. I know I'm not the first, and I'm looking for anyone interested in helping or contributing. I've made a lot of progress with the big tables using commercially available hex comparison software but the individual flags and scalars are going to take some time and may require looking into the disassembly.
If you're interested, send me a PM. I can teach you.
so i've never seen an XDF specifically but i swear i did see someone had damn completed a disassembly on here. i never plan to tune one myself so i wont be much help with the XDF but i do plan to hack up its reflashing routine at some point
i'd start here and try to find what that Tom H fella has done
http://www.gearhead-efi.com/Fuel-Inj...8791#post78791
I've thoroughly mined that thread for info but didn't want to hijack it. He's really focusing more on the hardware and comms side of it so I figured I'd work on the file definition.
I would like to offer what I can... my work is far from perfect though and I hope what I send doesn't present setbacks. I think the most digestible is perhaps my ram tables for the tside. Those can be reached with ELM327 and so on. We can start there. If you need my version of commented code, I can send that also.
-Tom
Making an xdf will be really awesome. Since now we have a viable method to convert raw bins to good bins, tuning the old school chip burning way will be much easier.
First thing to do will be to define the bin format for the xdf. eside is 64kb chip and tside is 128kb chip, including the ram section.
Tside must be first and eside second on the final bin. Than you can set the relative addressing. I think you should convert all the bins you have to that format and start the xdf with it.
One xdf fit all won`t work here. There are at least 2-3 different bin revision that shifted data here and there, so different version of xdf will be needed.
You can also look at the 96-97 code as 94-95 with the addition of obd2 emissions bloatware.
Eside structure is almost identical with the 94-95 code with the addition of some extra tables and scalars.
I suggest you start with the 94-95 xdf and change the starting addresses of the tables and scalars and mark the obd2 converted stuff so you can keep track of it. Later you can ditch the unneeded stuff. Some new tables will be added but they are not much.
You can also edit the xdf in text editor. It is much faster, than the built in interface.
Check bits are not that much, so you won`be having difficulties here, once understood. Find a good hex,binary calculator that can convert hex to binary and you can easily find which bits are changed. Windows calculator is doing fine with that in scientific level.
You did some great work here. I have one question for the tside memory chip. How the data is written to it. The usable banks are 3 banks with 32kb with $2000 bytes added to the first bank to make it 32kb.Quote:
Originally Posted by Tom H
How are this written to flash chip is there any offset for the third bank. Is it bank1 and 2 from 0-ffff and bank3 from 10000-18000 or bank 3 from 18000-1FFFF with 10000-18000 empty space.
Wow that's very helpful. I've done what you suggested - started with an OBD1 BIN and then opened a OBD2 BIN, both in TunerPro, and just used the built-in XDF editor which allows me to immediately see if the tables now match. I started with an Impala (b-body) BIN since there was no options on that carline (like rear axle ratio) to mess anything up in the BIN.
For hex editor / comparison, I'm using BeyondCompare, which is a great tool for the price. It's successfully found all of the big tables I've searched for almost instantly. The latest Windows calculator has a programmer mode that simultaneously displays hex, decimal, binary and octal, and that's been useful too.
So far I've found all the MAF, spark and VE tables. I started working on the transmission tables but ran out of time.
kur4o, can you send me a PM and we'll start talking over email? I'm going to need some help understanding how to read disassembly, otherwise these scalars and check bits will take a long time.
I'd also like to better understand the interplay between RAM and EEPROM while the car's running. What's left as a EEPROM lookup, and what's brought into RAM? I haven't looked at Tom H's attachment yet but will soon.
On the '96/7 TSide, the FLASH is set up to work in two pages. First page is enabled in the 'HC11 address space from $2000 through $FFFF, second page overlays from $8000 thru $FFFF. Address line 16 is driven by the bank switch bit (port a bit 5) and A 15. I believe the chip marked 014 P56AB 83833 is an AND gate (I need to confirm that it is not a NAND) This means that the 2nd page maintains the same code as the first in the range of $2000 thru $7FFF. The upper 32K are replaced with the 2nd page. In the FLASH chips address range, from $00000 thru $01FFF and from $10000 thru $17FFF are not used. It would be possible to add some logic and expose a 3rd page, but this is not what GM did.Quote:
Originally Posted by kur4o
Note that if the part mentioned above turns out to be NAND the address ranges in the flash flip.
Hope this answer is not confusing. If so, ask again and I will try to clarify. It is hard to write these things in a clear way.
-Tom
PS... The reason GM didn't overlay the lower 32K is because of interrupts. All the vectors need to point to the lower area such that if an interrupt happens, it can be serviced no matter which bank is active.Quote:
Originally Posted by Tom H
Tom H
The explanation says it all. So if you read the full flash chip the empty regions will be 0-1fff and 10000-17fff.
I have some routines that will erase and write the intel chips. You can set it up for the bootstrap mode and try some flashing.
Maybe we can move the conversation to the 96-97 lt1 thread.
Yes, that's what I expect. The question of if the gate is AND or NAND does come into this though and would just flip the banks. Easy to sort out if I had a working Tside (I don't at the moment). One issue gives me pause with what I wrote... the DLC interrupt seems to be in the switched bank. In the case this interrupt fires in the upper bank, the PCM will crash. Yipes did I find a bug???? or is that interrupt just not used. If not used, why provide a vector in a switched bank.Quote:
Originally Posted by kur4o
I am getting closer to being able to help with this but still struggling with some of the basics. Also struggling with finger problems... I soldered a header strip in place of the flex cable that broke. I should have placed one on the comp side to use a standard ribbon cable. now I need to cross all the wires ^&%&^%&^%
When I get the latest little (?) project of the schematic done, I would like to disassemble the erase and write routines. Have you already done this??
-Tom
I did it on 94-95 code but I am sure they use the same code. On 96-97 there might be slight difference, but when you get there I will give you a good start.Quote:
Originally Posted by Tom H
Chip enable must be set high with vpp to enable most of the functions.
i just got what i think is a 'bricked' 1996 ecm so i'm going to try to bring it back to life and help a bit with this research too.
It was bricked during a write while outside in cold weather. The laptop and cable were 30*f cold. Ive had 50/50 success with putting them in the freezer for a week or so. Some come back, some dont. Cant answer why. That one didnt. Works on vin locked hypertech tuners. Shh dont tell...
Hi Kur4o,Quote:
Originally Posted by kur4o
I am 95% through with the TSide schematic. This was a very difficult task... There are just a few chips that I am unable to identify. Two chips from Philips Semi. I believe one is some sort of amplifier and the other may be sample/hold/comparator. To finish work, I need to hook up a sound source and try to characterize the knock filter/ amp/ comparator. All this while simulating a running engine. This will take a while and I need a break SO...
I re-wrote my disassembler and it is ready to work through your code. It will be interesting to see the GM code for programming
-Tom
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
Here is for the 94-95 pcm. All labelled and commented so you can go through it really fast. I am sure the write and erase part will be almost identical in 96-97 pcm.Quote:
Originally Posted by Tom H
I plan to make a diss of that too to compare the difference.
Hi kkur4o,
Quickest of looks --> great work. One question, is the code loaded into ram $18xx-$1Fxx? Is this GM code? What was the process provided to GM techs?? Is this code downloaded from the tester or hidden away somewhere in FLASh. Just trying to get my bearings on this.
On 94-95 in the expanded area there is no code from factory, I offset it there for nicer look. Main loop is loaded at the 0-200 area and all the other routines are loaded at 200 start address one by one and overwritten. The data message buffer is at 300. It is send by the tool. Nothing is in the pcm code, all send by the tester.
On 96-97 there is more complex comm loop and the upload buffer is in 1800-on area, since the length of the message is like $400-$800 bytes. And that spi relaying to eside.
we have often suspected this is possible
would love for someone to try or get more details/theories on how
Quote:
Originally Posted by Tom H
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,Quote:
Originally Posted by kur4o
Would it be possible to get the binary for the flash routines?
-Tom
Sure, here it is.
Ooops, now understanding the files included ARE the binarys. I will comment the code and post... -TomQuote:
Originally Posted by Tom H
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.
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:
-TomCode:*************************************************
* 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
06 aa is the positive response when upload is good, it can be followed with some data like 2 byte checksum or chipid.
It is some standard frame response.
This is the header that is uploaded via mode5 request for a checksum range.Quote:
1C75 BD 1C 2E JSR $1C2E ; NOT REFERENCED
1C78 0000 ; CHECKSUM RANGE START
1C7A 0000 ; CHECKSUM RANGE END
1C7C 0000 ; WORKING CHECKSUM RANGE END
And you are right it is 7e not bd. This was the initial version that crashes but wasn`t fixed in the dissasembly.
I took a step back and realized there's still hundreds of parameters left. I started writing a script that takes in the '95 XDF, loads in all the scalars, tables and flags, then loads up the BeyondCompare output and steps through for matches. I'll include enough logic to handle little differences like individual cylinder fuel trims, which appear to be different from '95 to '96. Unless this is a waste of time...
i'd be doing some disassembly at this point.. you have a lot of input now to label some things, and track those back to identify the code responsible for them. there are lots of things you wont be able to find the way you're going at it. for example where's the switch to disable the crank sensor? that one is pretty important for 96-97 cars with huge cams.
Hi Steveo,Quote:
Originally Posted by steveo
Could you explain a bit more about how a large cam needs the crank sensor code disabled? This is stuff I don't know enough about...
-Tom
the crank sensor on these engines is only there to feed the OBD-ii misfire detection requirement. it compares the cam and crank angles i suppose and if they're too far off it figures there's a misfire.
you can imagine how the cam to crank relationship looks with a really lumpy cam. it causes the timing chain to jog back and forth a lot and cause the same kind of result as a real misfire.
the check engine light flashes if that happens. that might be a good clue, if you can find a routine that looks like it's flashing the CEL rather than just sticking it on, you could probably track that back and find the memory containing the error bit, then go back from there and find the misfire detection code.
it'd be nice to find the parameters so you could widen the angle that it considers a misfire and still retain some misfire detection, but other tools don't have that so people tend to just disable the error code so their dash doesn't blink at them. also the misfire detection doesn't SEEM to do anything other than flash the light, but nobody is 100% sure about that
I am sure (?) I can find it, once past these programming routines I will take a look. You are talking about the dtc.. right? There is a table where each dtc can be disabled/enabled. I sort of remember that there are four classes. I will refresh and post back later.Quote:
Originally Posted by steveo
Somewhere in the last 25yrs I was told by someone (sort of vague?) that misfire was done by looking at the time between hi-res ticks. If she fires, the momentary acceleration of the crank would reduce time to the next tick. That & the
operation of the crank sensor beyond looking for the disable is probably a fall task. That is unless we all get locked down.
Easy to see how a lumpy cam would mess with all the crank acceleration stuff also.
-Tom
i dont know if the DTC is separate from the misfire detection code flashing the check engine light...it does both
If your car is like the 96/7 Camaro/Firebird, I can give you a suggestion in a few days that *should* stop the lights. Can you tell me what code it is throwing??Quote:
Originally Posted by steveo
i don't have a car
from memory it sets that obd-ii code called random misfire
More comments added.
Well, I've got the disassembler open and am looking at the OBD1 code, with a whole lot of help from kur4o. And great work him on the commenting! I need to start an Ibuprofen fund; whew this is new territory for me.
Hi kur4o,Quote:
Originally Posted by 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.
Thank you, I think the transmit routine detailed here is correct now. I was interested to find that in the flash code there seems to be separate support for Intel and AMD sourced flash. I would expect that with the size of GM they would have had relationships with both vendors. The Intel was preferred but AMD was backup. I wonder if any PCMs were produced with the AMD parts. If so, all code needs to check the manufacturer and device id and have these separate routines. I noticed this in the erase code where there is a sequence for the AMD only UNLOCK.Quote:
Originally Posted by kur4o
Not had tiime to look at the '97 code you sent yet, but thank you for the update.
After this post, I plan to move details back to the '97 F-body thread. I now notice that this thread was to be about XDF and my posts are a bit of a hijack...
-Tom
Code:*************************************************
* SEND ALDL MESSAGE
*************************************************
012C 36 PSHA ; SAVE REGISTERS ON STACK
012D 18 3C PSHY ;
012F 3C PSHX ; MOVE POINTER TO MESSAGE ON STACK
0130 18 38 PULY ; TO IY
0132 CE 10 00 LDX #$1000 ; 68HC11 REGISTER BASE ADDRESS
0135 86 08 LDAA #$08 ; TRANSMIT ENABLE
0137 A7 2D STAA $2D,X ; SCI CONTROL REGISTER
0139 37 PSHB ; RT DELAY
013A C6 0B LDAB #$0B ;
013C 5A DECB ;
013D 26 FD BNE $013C ;
013F 33 PULB ;
0140 B6 18 03 LDAA $1803 ; PRU PORT B DIRECTION
0143 8A 40 ORAA #$40 ;
0145 B7 18 03 STAA $1803 ;
0148 B6 18 02 LDAA $1802 ; PRU PORT B
014B 8A 40 ORAA #$40 ; ALDL TX ENABLE
014D B7 18 02 STAA $1802 ;
0150 4F CLRA ; INITIALIZE CHECKSUM
0151 97 2E STAA @$2E ;
* MESSAGE CONTENT:
* [DEVICE ID] [LENGTH] [MODE] [MESSAGE …] [CHECKSUM]
*
* DEVICE ID: $F4 FOR TSIDE, $E4 FOR ESIDE
* LENGTH: MESSAGE LENGTH + $52
* MESSAGE LENGTH INCLUDES DEVICE ID, LENGTH, MODE, MESSAGE() AND CHECKSUM
* MODE: MODE1 – READ DIAGNOSTIC INFORMATION
* MODE2 – READ MEMORY SEGMENT (64 Bytes)
* MODE3 – READ MEMORY SEGMENT (Arbitrary, 1-84 Bytes)
* MODE4 – TEST ACTUATORS
* MODE5 – ENTER PROGRAMMING MODE
* MODE6 – UPLOAD AND EXECUTE PROGRAM SEGMENT
* MODE7 – BROADCAST
* MODE8 – DISABLE CHATTER (TAKE BUS MASTER)
* MODE9 – ENABLE CHATTER (GIVE BUS MASTER)
* MODE10 – CLEAR MALF CODES
* MODE12 – PROGRAM AUXILIARY FLASH MEMORY
* MODE13 – SECURITY CHALLENGE/RESPONSE
*
0153 86 F4 LDAA #$F4 ; PCM DEVICE ID: PCM
0155 8D 2E BSR $0185 ; SCI TRANSMIT BYTE
0157 17 TBA ; MESSAGE CONTENT LENGTH
0158 8B 55 ADDA #$55 ; LENGTH: ID + LENGTH + CONTENT +SUM + 0X52
015A 8D 29 BSR $0185 ; SCI TRANSMIT BYTE
015C 18 A6 00 LDAA $00,Y ; LOOP THROUGH MESSAGE
015F 8D 24 BSR $0185 ; SCI TRANSMIT BYTE
0161 18 08 INY ; INCREMENT POINTER
0163 5A DECB ; DECREMENT REMAINING BYTE COUNT
0164 26 F6 BNE $015C ; LOOP
0166 96 2E LDAA @$2E ; CHECKSUM
0168 40 NEGA ; NEGATE, SUM OF 0XFF
0169 8D 1A BSR $0185 ; SCI TRANSMIT BYTE
016B 1F 2E 40 FC BRCLR $2E,X,$40,$016B ; LOOP TILL TRANSMIT COMPLETE
016F B6 18 03 LDAA $1803 ; SET PRU PORT B DIRECTION
0172 84 BF ANDA #$BF ; DEFAULT ALDL TO DISABLE TX
0174 B7 18 03 STAA $1803 ;
0177 37 PSHB ; SAVE REGISTERS
0178 C6 0B LDAB #$0B ; 3 + 2 + (11 *5) + 4 = 64 ECLOCK
017A 5A DECB ; RT DELAY = 20US
017B 26 FD BNE $017A ; LOOP
017D 33 PULB ; RESTORE REGISTERS
017E 1D 2D 08 BCLR $2D,X,$08 ; DISABLE SCI TRANSMITTER SCCR2:TE
0181 18 38 PULY ; RESTORE REGISTERS
0183 32 PULA ;
0184 39 RTS ; DONE