OBD2 LT1 XDF $EE EEX creation

[sherlock9c1]

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.

[steveo]

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

[steveo]

i'd start here and try to find what that Tom H fella has done

http://www.gearhead-efi.com/Fuel-Injection/showthread.php?7677-1997-F-Body-ECM&p=78791#post78791

[sherlock9c1]

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.

[Tom H]

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

[kur4o]

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.

[kur4o]

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

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.

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.

[sherlock9c1]

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.

[Tom H]

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.

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.

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

[Tom H]

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

[kur4o]

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.

[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.

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

[kur4o]

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.
Chip enable must be set high with vpp to enable most of the functions.

[steveo]

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.

[Rocko350]

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

[Tom H]

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.
Chip enable must be set high with vpp to enable most of the functions.

Hi 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

[Tom H]

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

[kur4o]

Hi 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

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.

I plan to make a diss of that too to compare the difference.

[Tom H]

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.

[kur4o]

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.

[steveo]

we have often suspected this is possible

would love for someone to try or get more details/theories on how


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

[kur4o]

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.

[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,

Would it be possible to get the binary for the flash routines?

-Tom

[kur4o]

Sure, here it is.

[Tom H]

Hi,

Would it be possible to get the binary for the flash routines?

-Tom

Ooops, now understanding the files included ARE the binarys. I will comment the code and post... -Tom

[sherlock9c1]

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.

[Tom H]

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:



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





-Tom

[kur4o]

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.



1C75 BD 1C 2E JSR $1C2E ; NOT REFERENCED

1C78 0000 ; CHECKSUM RANGE START
1C7A 0000 ; CHECKSUM RANGE END
1C7C 0000 ; WORKING CHECKSUM RANGE END


This is the header that is uploaded via mode5 request for a checksum range.
And you are right it is 7e not bd. This was the initial version that crashes but wasn`t fixed in the dissasembly.

[sherlock9c1]

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

[steveo]

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.

[Tom H]

where's the switch to disable the crank sensor? that one is pretty important for 96-97 cars with huge cams.

Hi 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

[steveo]

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

[Tom H]

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.

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

[steveo]

i dont know if the DTC is separate from the misfire detection code flashing the check engine light...it does both

[Tom H]

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

[steveo]

i don't have a car
from memory it sets that obd-ii code called random misfire

[kur4o]

More comments added.

[sherlock9c1]

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.

[In-Tech]

More comments added.

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.

[Tom H]

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.
And you are right it is 7e not bd. This was the initial version that crashes but wasn`t fixed in the dissasembly.

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.

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



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

[Tom H]

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

Hi,

From what I can tell, the DTCs related to the crank position sensor are these.

P0300 ENGINE MISFIRE DETECTED: RANDOM/MULTIPLE CYLINDER
P0301 CYLINDER 1 MISFIRE DETECTED
P0302 CYLINDER 2 MISFIRE DETECTED
P0303 CYLINDER 3 MISFIRE DETECTED
P0304 CYLINDER 4 MISFIRE DETECTED
P0305 CYLINDER 5 MISFIRE DETECTED
P0306 CYLINDER 6 MISFIRE DETECTED
P0307 CYLINDER 7 MISFIRE DETECTED
P0308 CYLINDER 8 MISFIRE DETECTED
P0335 CRANKSHAFT POSITION SENSOR CIRCUIT MALFUNCTION
P0336 CRANKSHAFT POSITION SENSOR CIRCUIT RANGE/PERFORMANCE


I think we can eliminate anything with a "CIRCUIT" in the name because no amount
of cam can affect continuity of the sensor. My thinking is that the P0300 would
be the code I would expect. In the '97 code I see a table of enables for DTC processing
starting at $20B0, 17bytes deep. Each bit controls the processing of a DTC, set is on. I believe
that clearing bit 7 of $20B4 will eliminate the DTC P0300. It would be more interesting to work
through the code to see if a parameter in the calibration can be change to eliminate the DTC at idle where
the impact of the cam is setting this thing off.

-Tom

PS: This table would be a good thing for the XDF to have...

[sherlock9c1]

I added that bit to my draft XDF, but what indexing are you using? 20B4 is 00 in both a '96 B-car BIN and a '97 F-body BIN, and both are in a field of 00s.

Is that in the E side or the T side? I'll email you.

[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 (http://www.gearhead-efi.com/Fuel-Injection/attachment.php?attachmentid=13796&d=1550268165) 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.

[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

[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

[In-Tech]

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? :happy: ) is did you correct the checksum for the change you made and the CEL is flashing rapidly cuz it is very unhappy :innocent2: 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? :wtg:

[Tom H]

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

[Tom H]

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? :happy: ) is did you correct the checksum for the change you made and the CEL is flashing rapidly cuz it is very unhappy :innocent2: 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? :wtg:

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

[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.

[Terminal_Crazy]

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? :happy: ) is did you correct the checksum for the change you made and the CEL is flashing rapidly cuz it is very unhappy :innocent2:
Yeah but you could recalc the checksum & update that byte.



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



Shit, you could write an idling bootloader, disable the checksum, send executable packets and almost have real-time emulation. Ummmmm this IS freeware, right? :wtg:
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

[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/US5023778A/en?oq=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

[steveo]

i do agree and observed it crashes although it's nice to have a theory why

in practice sending a 7E jump only incurs 3 extra bytes of overhead, so that's what i ended up doing in flashhack

thanks for reminding me of this, as some of my code doesn't check for empty mode 6 data payloads, it'd be nice to trap that error if i ever make a mistake somewhere

[kur4o]

Mode 6 is always download and execute.

In that case

$F4 $57 $06 $00 $00 $AE is

download at $0000 address zero bytes and execute at $0000 address.

I suspect that aldl chip verifies checksum and never sends checksum byte to PCM` cpu and also truncates the message if the checksum doesn`t match. If you are sending this straight to cpu without using aldl chip as a buffer you actually write AE at addess $0000 and than execute it as code. So opcode $ae is a crash for cpu.

IN bootstrap mode some form of checksum should be implemented in the message receive loop, in case it doesn`t match than skip the jsr to download address.

[kur4o]

I figured why it crashes.

You need at least $58 message length to save the jump buffer. Otherwise the code enters loops expecting more bytes that are never send.

It is also unavoidable to write at least one bytes of data before jumping. There isn`t any length specified to skip on zero length and the code assumes there is at least 1 byte to write.

So the best way to execute only is to overwrite the first byte of the jump location.

$F4 $58 $06 $00 $00 $XX $YY

[steveo]

oh, yeah! that's a good point! in my case while running the kernel, i always know what that first byte of a routine or subroutine is since i uploaded all of them. i can easily abuse this to save 2 bytes of bandwidth in a lot of cases. i'll give it a shot tonight.

[kur4o]

Use with care on code that reduce stack for the return address. It might crash as well.

[In-Tech]

What, you no like pop? <<<<< code humor :happy:

[Tom H]

Found one other Hmmmm in the code, this one doesn't matter at all, just a point of interest...

I am not sure what the point of mode 5 is. What ever you send, it just replies 'AA' and does nothing else. Probably just completes a sequence for the tester or ??
Thing I found is, in the programming code, the checksum is never tested. It needs to be there but the value isn't tested. So:

$F4 $56 $05 $55 works just as well as
$F4 $56 $05 $B1 with correct checksum.

OK, so I am now through the code and starting changes needed for functioning code under bootstrap. When you enter bootstrap, no chip selects are defined thus FLASH and PRU are not in the memory map. There is a pesky rom to remove from the memory map. I intend to up the baud rate to reduce time and need a workable way to make the change. Qs for you all: do you have a feel for what baud to use? Faster is better VS. reliable comms. I need to turn off the Tside ALDL driver (not connected right now but later...) and a few other house keeping things.

Do you feel that these setup things are better done in a subroutine? This permits NOT messing with the '95 programming code but has a downside of making the procedure of baud rate change more cumbersome. My current thinking is to start bootstrap in low speed. This is because bootstrap starts the SCI up in wire_or_mode. I don't want to hang too much of a pull-up resistor off the port, so starting at 1889baud makes sense to me. Once the housekeeping routine is run the rate can be upped because port D can now be driven. Thoughts?

One other consideration, since bootstrap has no chip-selects enabled, the internal ram is all that is available. It may be unavoidable to modify the standard code just because I need the space.

-Tom

Give all that, programming in the standard rate is slow in human terms. Speeding it 4X if possible makes it much better, perhaps I should aim at around 32-64Kbps??

-Tom

[steveo]

I am not sure what the point of mode 5 is. What ever you send, it just replies 'AA' and does nothing else. Probably just completes a sequence for the tester or ??

yeah, completing a sequence for the tester is pretty much why it's there. before sending any mode 6 requests, the tester is supposed to send a mode 5 request, and the ECM either replies 05 AA or with a 0D if mode 5 is locked out. having mode 5 reply just satisfies that requirement so someone uploading code doesn't have to worry about whether they're executing from rom or ram and follow the same procedure. in my software i've changed the AA response byte to that command to something else, so we can branch on the condition that the kernel is loaded or not loaded (so we don't try to load a kernel over itself, which is a crashy thing to do)


Qs for you all: do you have a feel for what baud to use? Faster is better VS. reliable comms. I need to turn off the Tside ALDL driver (not connected right now but later...) and a few other house keeping things

your end goal here is just for recovering bricked ECMs, right? nobody will mind waiting for that, so i wouldn't focus too much on how fast it is. even if you can get it near 9600 baud or something it will serve its purpose well

[Tom H]

your end goal here is just for recovering bricked ECMs, right? nobody will mind waiting for that, so i wouldn't focus too much on how fast it is. even if you can get it near 9600 baud or something it will serve its purpose well


Right. So the options are:

118, 236, 384, 473, 512, 768, 945, 1024, 1536, 1890, 2048, 3072, 3781, 4096, 6144, 7562 --> all slower than the 8192 GM selected. 1890 is the default bootstrap speed in my config. I need to change gears before unbrick runs.

8192 --> Tried and true

12288, 15124, 16384, 24576, 32768 --> a bit faster but still within reason

49152, 65536, 98304, 196608 --> Much faster but I don't know if my PC and serial cable can keep up. Not planning to test.

I will try 32,768 and fall back to 16384 if it isn't solid enough. I expect it is OK though because GM doesn't use wire-or mode.

-Tom

[kur4o]

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]

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]

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]

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]

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]

Files with extension changed (?)

[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 :nono: 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.

[steveo]

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

[In-Tech]

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


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]

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 :nono: 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
15648

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

[Tom H]

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

[Tom H]

While on this posting storm, I just found one more thing. With respect to the 68HC11 noise flag, I wanted to understand what the issue is. Seems that there are problems with the baud rate in these cheep-o cables. I built a file of a few hundred $55s and sent it to the transmit. The low pulses were all one size but the high pulses had two different sizes. The high times were measured at 570 or 660us on my hobby quality scope. I had requested 1890 baud and got something like 1750. It is no wonder the 'hc11 UART was getting upset. I guess you get what you pay for (sometimes)

I had read somewhere about folks making software available and having trouble with certain cables. Does anyone know if the driver affects the low level operation of these cables? Any suggestions?? I have five different drivers of which 3 work with the usb-serial cable and some of the others work with ELM327. Sure getting complex to configure your system with all these junk drivers.

-Tom

[kur4o]

While on this posting storm, I just found one more thing. With respect to the 68HC11 noise flag, I wanted to understand what the issue is. Seems that there are problems with the baud rate in these cheep-o cables. I built a file of a few hundred $55s and sent it to the transmit. The low pulses were all one size but the high pulses had two different sizes. The high times were measured at 570 or 660us on my hobby quality scope. I had requested 1890 baud and got something like 1750. It is no wonder the 'hc11 UART was getting upset. I guess you get what you pay for (sometimes)

I had read somewhere about folks making software available and having trouble with certain cables. Does anyone know if the driver affects the low level operation of these cables? Any suggestions?? I have five different drivers of which 3 work with the usb-serial cable and some of the others work with ELM327. Sure getting complex to configure your system with all these junk drivers.

-Tom

I guess you have some crap 3.3v serial cable. I got one batch that hardly worked at all.
The best ones that work flawless are ftdi based and look like this.

Try some other standard baud rate or close to some standard. At higher rates it might work better.

[In-Tech]

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

Second, If need be with the push of a button you could have had 32bit. Easy done, just ask. <<<<< Yes please, if super simple. I have quite a few dos type software items that could prove helpful for debugging and I have doubts they will work with 64 bit Windows.

Last bit,<<<<< I see what you did there :happy: 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. <<<<< It is 61376 bytes

-Tom

I work from home on Mondays since it usually has the phone ringing off the hook, and just place orders too, I'll be able to play with this stuff then to more extent :)

[steveo]

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

it just seems like i've done a lot of work that would assist and save you time. if you get this thing booted up and communicating with my slightly customized kernel, we can kick it out of bootstrap mode and leave that code running, and just plug the thing into my flash tool, it'll do all the rest of the work.

maybe it's not that simple though

[Tom H]

I work from home on Mondays since it usually has the phone ringing off the hook, and just place orders too, I'll be able to play with this stuff then to more extent :)

Please give this a try

[Tom H]

it just seems like i've done a lot of work that would assist and save you time. if you get this thing booted up and communicating with my slightly customized kernel, we can kick it out of bootstrap mode and leave that code running, and just plug the thing into my flash tool, it'll do all the rest of the work.

maybe it's not that simple though

It would be best if it fit into your tool. I'm not sure how to do this... If you can give me a hand I will see if we can make this happen.

I have not yet tried the TSide. The parts I need from China are taking so long to get here. They are now in the hands of Canada Customs and will at some point move to Canada Post. Canada Post moves at a snail pace at the best of times. Hope I see this stuff some time before July. Other option is to wire wrap.

-Tom

[Tom H]

While debugging the ESide routine for setting VPP to 12V, I decided to modify the result codes. Should the ignition voltage be out of range OR the VPP be out of range, an error message is generated. This all is of little use to the tech trying to re-flash. I added ignition voltage and VPP voltage to the reply. I am concerned how this will affect other code that might use the routine ??steveo??

Code works now. I made a bunch of changes to port it from the TSide example I was using to the ESide. Here is the code I am using now.
To convert the VPP voltage, divide result by 17.5.




*************************************************
* APPLY VPP 12 VOLT
*************************************************
VPP_12VOLT LDAA #$00 ; START A/D CONVERTER CH0
STAA CPU_ADCTL ;
ASLD ; TIME DELAY TO A/D COMPLETE
MUL ;
MUL ;
MUL ;
LDAA CPU_ADR1 ; READ ESIDE PCM IGNITION VOLTAGE

STAA @IGN_VOLTAGE ;

CMPA #$66 ; 10.2 VOLTS
BCS VPP_ERR_IVOOR ; IGNITION UNDER VOLTAGE

CMPA #$A1 ; 16.1 VOLTS
BLS VPP_IVIR ; IGNITION VOLTAGE IN RANGE

VPP_ERR_IVOOR LDD #$0602 ; MODE 6 MESSAGE: IGNITION VOLTAGE OUT OF RANGE
BRA VPP_SEND_MSG ; SEND MESSAGE

VPP_IVIR LDAA PRU_PA ; PRU PORT A
ORAA #$80 ; TURN ON VPP
STAA PRU_PA ; UPDATE AND WAIT FOR VPP TO SETTLE

JSR @D_RESET_COP ; RESET COP TIMERS
JSR @D_D10MS_DELAY ; 10MS DELAY
JSR @D_RESET_COP ; RESET COP TIMERS
JSR @D_D10MS_DELAY ; 10MS DELAY

LDAA #$01 ; START A/D CONVERTER CH1
STAA CPU_ADCTL ;
ASLD ; TIME DELAY TO A/D COMPLETE
MUL ;
MUL ;
MUL ;
LDAA CPU_ADR1 ; READ VPP VOLTAGE

STAA @VPP_VOLTAGE ;

CMPA #$BC ; 10.5 VOLTS
BCS VPP_ERR_PVOOR ; VPP UNDER VOLTAGE

CMPA #$E9 ; 13.0 VOLTS
BLS VPP_PVIR ; VPP IN RANGE

VPP_ERR_PVOOR LDAA PRU_PA ; VPP UNDER/OVER VOLTAGE
ANDA #$7F ; TURN OFF VPP
STAA PRU_PA ; UPDATE

LDD #$0603 ; MODE 6 MESSAGE: VPP 12V OUT OF RANGE
BRA VPP_SEND_MSG ; SEND MESSAGE

VPP_PVIR LDD #$06AA ; MODE 6 MESSAGE: APPLY VPP 12V SUCCESS

VPP_SEND_MSG PSHX ; MAKE ROOM FOR MESSAGE CONTENT ON STACK
PSHX ;

TSX ; MESSAGE POINTER TO IX

STD $00,X ; SET MESSAGE CONTENT
LDAA @IGN_VOLTAGE ;
LDAB @VPP_VOLTAGE ;
STD $02,X ; SET MESSAGE CONTENT


LDAB #$04 ; MESSAGE PAYLOAD 4 BYTES
JSR @D_SEND_ALDL ; SEND MESSAGE

PULX ;
PULX ; RESTORE STACK POSITION

RTS ; DONE



-Tom

[kur4o]

That brings a good point. The vpp is applied by tside only, I guess the relay transistor is wired there and the voltage goes to both sides. Now can we apply vpp from tside, while flashing eside. I guess we need to bootstrap both sides and than do the flashing.

[steveo]

yeah you cant apply vpp from the eside at all
back to my original thought
bootstrap the dead side with the entire kernel then just let flashhack do its normal thing over aldl. no need to bootstrap both sides
the chances of both sides being bricked are near zero

[steveo]

just out of curiosity, is there any way to bootstrap the chip over the regular ttl serial pin that aldl uses? or is it a different pin entirely

in other words can you upload the bootstrap program from the aldl port?


I am concerned how this will affect other code that might use the routine ??steveo??

definitely would need a tweak on the tool side of things, but otherwise looks harmless. i'd just put ignition voltage in there, since if that's out of range, that is something the user is able to solve. knowing the vpp voltage might be academic, as good battery voltage should mean good vpp voltage unless there's damage to the ECM itself. the only person that's ever reported the vpp voltage out of range error to me opened his ECM and found it full of moisture damage.

[kur4o]

Why don`t just make a bootstrap flash mode in flashhack and collaborate the effort with Tom H for easy recovery.

It is still serial comm and the same ftdi adapters can be used. The bootstrap flashing will use very slightly modified version of 94-95 flashing routines and it will be just uploading the code in bootstrap and flash in bootstrap.

The only addition to existing code will be entering bootstrap mode and wiring the cable to the pcm board.

So Steveo had the high level program interface and Tom H has the low level code and bootstrap sequence. That way it can work for 96-97 too without bothering with vpw communication.

[steveo]

i am just reading about bootstrap mode and it's really interesting, i think i can help get this working.... and might be way easier than i thought

is this correct?

- ground MODB to enter bootstram rom on reset
- power up the whole rig
- set the SCI baud rate with a byte of 1s or 0s. FF=low baud 00=high baud (should be 8192 with this processor, right?)
- transmit your code from 0 offset
- handle the echo (actually i think we'll get a double echo if we've tied tx/rx together, not sure how that'll look).
- wait for timeout and it'll execute from 0x0000

there are a few trivial things i'm curious about after looking at bootstrap mode

it seems that in bootstrap mode the onboard EEPROM is forcibly relocated to 0xFE00 to 0xFFFF and there's not much that can be done about it. i guess that wont affect writing...? but that'll give us a nonsense reset vector. i do have functions in my flash tool that expect to be able to read the onboard eeprom at 0x0E00, but that's ok, they'll just read zilch from RAM and no harm done.

is the COP timer available during bootstrap mode...? if it does crash what reset vector does it use? does it use 0xFFFE like normal, so in actuality it's going to use whatever is in the onboard eeprom? it'll try to jump to FFFF which contains FF and will probably just lock up. the existing method we use for rebooting the ECM is just tripping the COP timer so obviously it wont reboot successfully but that's no big deal.

does anyone know what happens if you un-ground MODB while the processor is running?

[steveo]

The bootstrap flashing will use very slightly modified version of 94-95 flashing routines and it will be just uploading the code in bootstrap and flash in bootstrap.

modified in what way?

[Tom H]

That brings a good point. The vpp is applied by tside only, I guess the relay transistor is wired there and the voltage goes to both sides. Now can we apply vpp from tside, while flashing eside. I guess we need to bootstrap both sides and than do the flashing.

I believe that the VPP is generated on the ESide by the small 8pin part center just below the heat spreader bar. I have not yet done a schematic for the Eside and do not know the part number for that VPP regulator. I believe it is a buck configuration and makes use of at least one of the transistors next to it. I need to trace it. In my case, the ribbon cable is cut and I just applied vpp through a resistor. That's how I tested the a/d function and replies of the code. I thought (hoped?) that the control for the regulator was or tied between T&Esides. I need to look at this more.

-Tom

[In-Tech]

Why don`t just make a bootstrap flash mode in flashhack and collaborate the effort with Tom H for easy recovery.

It is still serial comm and the same ftdi adapters can be used. The bootstrap flashing will use very slightly modified version of 94-95 flashing routines and it will be just uploading the code in bootstrap and flash in bootstrap.

The only addition to existing code will be entering bootstrap mode and wiring the cable to the pcm board.

So Steveo had the high level program interface and Tom H has the low level code and bootstrap sequence. That way it can work for 96-97 too without bothering with vpw communication.

Yes please,Steveo, if you can whip me/us up a quick test version we might have an answer shortly before I head to the shop today or I will do some testing when I get home, I only have a '96 here to test on though.


does anyone know what happens if you un-ground MODB while the processor is running?

There was a reason I was asking someone to test the pin for flashing CEL and it wasn't for checking codes :thumbsup:

[Tom H]

yeah you cant apply vpp from the eside at all
back to my original thought
bootstrap the dead side with the entire kernel then just let flashhack do its normal thing over aldl. no need to bootstrap both sides
the chances of both sides being bricked are near zero

Please confirm... You think the Tside turns on VPP through the port replacement part port a bit 7?

[Tom H]

just out of curiosity, is there any way to bootstrap the chip over the regular ttl serial pin that aldl uses? or is it a different pin entirely

in other words can you upload the bootstrap program from the aldl port?


Can't use ALDL i/o in bootstrap. The internal rom echos received data this would get looped back and mess the load. One concern I have is making sure that the aldl driver chip doesn't mess things when turned off.



definitely would need a tweak on the tool side of things, but otherwise looks harmless. i'd just put ignition voltage in there, since if that's out of range, that is something the user is able to solve. knowing the vpp voltage might be academic, as good battery voltage should mean good vpp voltage unless there's damage to the ECM itself. the only person that's ever reported the vpp voltage out of range error to me opened his ECM and found it full of moisture damage.

Agree, but it does tell you that & more info is always better in my estimation. Cost is one byte = no time.

[Tom H]

That way it can work for 96-97 too without bothering with vpw communication.
Yes that is what I think will work easy.

[In-Tech]

Steveo,
I have never used your program and this error popped up when I ran it in WinXP.

[kur4o]

I have traced the vpp pin and it is common for the 2 sides. When it is turned on both sides get the voltage and the trigger pin is commanded by tside. Also the tside reads the voltage.

An easy solution is dual bootstrap or external supply of vpp it must be filtered in a a narrow 12v range.

[Tom H]

i am just reading about bootstrap mode and it's really interesting, i think i can help get this working.... and might be way easier than i thought

is this correct?

- ground MODB to enter bootstram rom on reset
- power up the whole rig
- set the SCI baud rate with a byte of 1s or 0s. FF=low baud 00=high baud (should be 8192 with this processor, right?)
- transmit your code from 0 offset
- handle the echo (actually i think we'll get a double echo if we've tied tx/rx together, not sure how that'll look).
- wait for timeout and it'll execute from 0x0000

In my setup, i ground both mode pins
First byte is $FF. In my case that is all that works but again I suspect the problem is my (*(*&^6 serial cable
No ht high baud isn't 8192. I can tell you what it is, just don't have the number right now.
Transmit code starts at 0
I separate the tx & rx you can;t connect them for a single wire
Time out and execute -Yes. I have done all this for a while and built tools to produce the file with a prepended FF. I just send the binary to my terminal program and it loads.




there are a few trivial things i'm curious about after looking at bootstrap mode

it seems that in bootstrap mode the onboard EEPROM is forcibly relocated to 0xFE00 to 0xFFFF and there's not much that can be done about it. i guess that wont affect writing...? but that'll give us a nonsense reset vector. i do have functions in my flash tool that expect to be able to read the onboard eeprom at 0x0E00, but that's ok, they'll just read zilch from RAM and no harm done.

is the COP timer available during bootstrap mode...? if it does crash what reset vector does it use? does it use 0xFFFE like normal, so in actuality it's going to use whatever is in the onboard eeprom? it'll try to jump to FFFF which contains FF and will probably just lock up. the existing method we use for rebooting the ECM is just tripping the COP timer so obviously it wont reboot successfully but that's no big deal.

does anyone know what happens if you un-ground MODB while the processor is running?

Turn off the eeprom, change modes after boot. things like that. Remember also to turn off the bootstrap ROM. Also once booted you need to program all the chip selects and what not. A/d function needs to be enabled. At the start the PRU will not show in the memory. Again chip select program will light it up. My plan was to use the internal mem for loader function and the PRU ram as a sort of transient program area.

COP is available. If the boot rom is on, vectors are replaced with those in the rom. search the reference manual for pseudo vectors. Mode pins are sampled at power up.

-Tom

[kur4o]

Steveo,
I have never used your program and this error popped up when I ran it in WinXP.

I have a version that will work on xp sp3. Just need to compile the latest source and will post it.

[Tom H]

Steveo,
I have never used your program and this error popped up when I ran it in WinXP.
Not happy w that. can you try messing with the "compatibility mode" setting. It's the same code I sent before compiled for x86 under visual studio.

[Tom H]

I have traced the vpp pin and it is common for the 2 sides. When it is turned on both sides get the voltage and the trigger pin is commanded by tside. Also the tside reads the voltage.

An easy solution is dual bootstrap or external supply of vpp it must be filtered in a a narrow 12v range.

I agree, VPP is common through the ribbon cable. What about enable for the chip?? I don't know which pin, but it must also be across the ribbon. My guess is that there is a multidrop and that the Eside can enable somehow...

[steveo]

Steveo,
I have never used your program and this error popped up when I ran it in WinXP.

not exactly the right thread for this but flashhack and eehack are written with modern QT libraries and XP is 20 years old. QT no longer supports XP, so neither do i. you will find most software does not run on XP including mine.

kur4o compiles with an older version of QT and you're welcome to do that, that's what open source is for, but if any bugs come up related to that i honestly don't really want to know, and i reserve the right to use modern QT features that may not work on your older versions so it may break at any time, leaving you high and dry.

from flashhack's page:


It’s open source and will run on Windows 7, Windows 10, and Linux.

[In-Tech]

Yes please,Steveo, if you can whip me/us up a quick test version we might have an answer shortly before I head to the shop today or I will do some testing when I get home, I only have a '96 here to test on though.



There was a reason I was asking someone to test the pin for flashing CEL and it wasn't for checking codes :thumbsup:
Yes, Steveo, it runs fine on my Win7 machine.

There is a procedure that I am playing with on the '96 here and it shows promise. I'll see if I can track down a 94/95 pcm today to test/blow up.

[Tom H]

- set the SCI baud rate with a byte of 1s or 0s. FF=low baud 00=high baud (should be 8192 with this processor, right?)


Looked it up for you... With our crystal frequency the two speeds are 1,890 and 12,288. As I previously mentioned, my serial cable does not work at 12,288.

User sends $FF and IF received correctly, baud rate is 12,288.
User sends $FF at slower rate, the start bit will be much wider and FF will not be received, probably a $07 or $0F. In this case code changes baud to 1890

User sends $00 or break and it jumps to EEPROM and runs whatever is there.

-Tom

[Tom H]

Hi,
Yesterday I wrote some code that dumps out the content of flash in bootstrap mode. To do this, it was necessary to remove both bootstrap ROM and EEPROM from the memory map. This done, the routine works and is able to dump the entire content.

Should we want to include this in other software, the output format may need to be changed. I will rely on you to tell me the format that should be returned. For now, this is what I used:

[DEVICE]
$F4
[LENGTH]
$D7
[MODE]
$06
[MESSAGE …]
$AA

Followed by $80 hex bytes

[CHECKSUM]
$xx

Code for this is below. It is downloaded into the PRU at $1810 and executed there. Since it is a reply to download and execute, the reply is mode $06. I was not sure if the reply should start with $AA or $55 because there are a total of 448 replies.

Also, I have found the enable signal for the flash VPP generator. The actual regulator is on the Eside. There is a control on the Tside and perhaps (?) there could be one on the Eside. I will do a bit of investigation today and see what I can find. Please let me know if you have changes to suggest to the format of the replies. Code is below.

-Tom



ORG $0000 ; SET ORIGIN

DB $F4 ; TARGET DEVICE
DB $81 ; LENGTH
DB $06 ; UPLOAD AND EXECUTE PROGRAM SEGMENT
DB $18 ; ADDRESS H
DB $10 ; ADDRESS L

LDY #$2000 ; INITIAL LOCATION LESS $80

NEXT_BLOCK LDX #$1F7E ; BUFFER

LDD #$06AA ; MODE:MESSAGE BYTE 1
STD $00,X ; A-OK

LDAB #$80 ; SET THE BYTE COUNT

CPY #$0000 ; TEST FOR COMPLETE
BEQ COMPLETE ;


XFER_LOOP LDAA $00,Y ; READ FLASH
STAA $02,X ; SAVE TO BUFFER

INY ; INCREMENT SOURCE
INX ; INCREMENT DESTINATION

DECB ; DECREMENT COUNT
BNE XFER_LOOP ; LOOP TILL ZERO

LDX #$1F7E ; BUFFER HEAD

LDAB #$82 ; MESSAGE CONTENT LENGTH
JSR $0008 ; D_SEND_ALDL

BRA NEXT_BLOCK ;

COMPLETE RTS ;

DB $CD ; CHECKSUM

[kur4o]

The read format being used



f4 5c 06 02 00 20 0b 20 00 fd

f4 d9 06 aa 20 00 ?\... .?.???.??.
00 f7 3d ff 14 00 00 20 00 ff 00 40 40 40 40 40 .?=?... .?.@@@@@
40 40 40 40 40 40 40 40 40 40 40 02 02 50 f2 50 @@@@@@@@@@@..P?P
40 c5 50 60 20 50 ba fe fe fe fe 80 80 08 88 05 @?P` P???????.Ђ.
0b 60 05 10 00 00 00 00 11 44 44 44 44 44 44 44 .`.......DDDDDDD
44 44 39 33 2e 25 1f 1c 17 17 44 44 44 44 44 44 DD93.%....DDDDDD
44 44 44 39 33 2e 28 22 1c 17 17 44 44 44 44 44 DDD93.("...DDDDD
44 44 4a 47 39 33 2e 28 22 1c 1c 1c 47 50 50 50 DDJG93.("...GPPP
50 50 50 50 44 3f 3f 39 33 28 22 1c 1c 47 50 5b PPPPD??93("..GP[
2e


request
f4 5c 06 [02 00] [20 0b] [20 00] [xx]

[02 00]=load address
[20 0b]=code bra to
[20 00]=start address of data to be read
[xx]=chks


response
f4 d9 06 aa [20 00] [data ....] [chks]

[2000] is the memory offset the data is being read.

[Tom H]

The read format being used


Thank you. Is the device $F4 for both T & E sides?

-Tom

[kur4o]

It is f4=tside and e4=eside.

[Tom H]

I have had a look into the issue of lighting up VPP from the ESide. Not sure why it is so complex but I will explain what I see and request a little help...

On the Eside, the small 8pin soic between the cpu and the heat spreader is the VPP regulator. Output is pin 1. VPP is connected to both flash. It runs between boards on pin 13 of the ribbon.

Tside PRU port A bit 7 enables the regulator through a Rube Goldberg circuit that is to say: it connects to some un-identified philips chip marked 16127472 on pin 8. The philips chip outputs an OR function of that input and the one from the ESide that connects on pin 9. The connection to pin 9 crosses the ribbon on pin 15 of the cable and is sourced by Eside PRU Port A bit 7. The philips chip outputs the ORed enable on pin 10, this is a high going enable. The enable again crosses on the ribbon cable on pin 20. Now back on the Eside ribbon pin 20 drives the base of two NPN transistors, one of which enables the 12V VPP regulator.

I believe when the two boards are properly connected by a ribbon (mine are not at the moment) both sides can enable VPP.

The explanation above is almost too muddled to post, so here is my ask: I can't test this until my connector parts arrive. Could someone try enabling VPP from the Eside? All it would take is a write to location 1800 and 1801 with bit 7 high.
If this works out we can move to integrate UnBrick.

-Tom

[kur4o]

It looks like it will work in case the hardware links are there.

On both 94-95 and 96-97 pcms the vpp enable bit is at tside $1800 bit $80,
I checked the eside diss and 1800 $80 is not used anywhere in the code. So it is very likely that it will work. Do you think eside can sense vpp voltage.

1801 $80 is set high so it is useless to test.

Steveo should be able to make a quick code upload to eside with part of the vpp routine and modify the tside vpp to read the voltage after that to confirm.

I will also be able to test it but it have no idea when that can happen.

Edit:

I looked at some of the flash code and it looks like that the short_vpp is actually a read only vpp voltage routine. It can be used to read the vpp with it form tside.

[Tom H]

It looks like it will work in case the hardware links are there.

I think it is the way I stated in the rambling explanation BUT not 100% sure because my TSide is not connected or powered. I need to get this back working.



On both 94-95 and 96-97 pcms the vpp enable bit is at tside $1800 bit $80,
I checked the eside diss and 1800 $80 is not used anywhere in the code. So it is very likely that it will work.

All depends on the function of the Philips mystery chip



Do you think eside can sense vpp voltage.

Yes. Although different a/d converters are used. I have re-written the routine, it works.



1801 $80 is set high so it is useless to test.

It needs to be high to drive the output. In my case I am not running with GM code so none of the defaults are taken care of unless I do.



Steveo should be able to make a quick code upload to eside with part of the vpp routine and modify the tside vpp to read the voltage after that to confirm.

I will also be able to test it but it have no idea when that can happen.

Great. If you or Steveo would like my code for turn on from ESide, just ask

[/QUOTE]
Edit:
I looked at some of the flash code and it looks like that the short_vpp is actually a read only vpp voltage routine. It can be used to read the vpp with it form tside.
[/QUOTE]
For me, if the code in a PCM is trashed, best to work with one processor at a time. That way you don't rely on something that isn't solid.

[kur4o]

Yes. Although different a/d converters are used. I have re-written the routine, it works.

Can you post the code, I will try to adapt it for 94-95 eside.

I need mostly the port G config and the AD lookup for ign voltage and vpp voltage.

[Tom H]

Can you post the code, I will try to adapt it for 94-95 eside.

I need mostly the port G config and the AD lookup for ign voltage and vpp voltage.

Code you need is below, I included both turn on and off. Port G is a factor on the Tside but not here. Analog goes straight to the processor inputs. Let me know if there is anything else that can help.

-Tom





*************************************************
* APPLY VPP 12 VOLT: VPPH
*************************************************
SET_VPPH LDAA #$00 ; START A/D CONVERTER CH0
STAA CPU_ADCTL ;
ASLD ; TIME DELAY TO A/D COMPLETE
MUL ;
MUL ;
MUL ;
LDAA CPU_ADR1 ; ESIDE PCM IGNITION VOLTAGE

STAA @IGN_VOLTAGE ; IGNITION VOLTAGE FOR REPLY

CMPA #$66 ; 10.2 VOLTS
BCS VPPH_ERR_IVOOR ; IGNITION UNDER VOLTAGE

CMPA #$A1 ; 16.1 VOLTS
BLS VPPH_IVIR ; IGNITION VOLTAGE IN RANGE

VPPH_ERR_IVOOR LDD #$0602 ; MODE 6 MESSAGE: IGNITION VOLTAGE OUT OF RANGE
BRA VPPH_SEND_MSG ; SEND MESSAGE

VPPH_IVIR LDAA PRU_PA ; PRU PORT A
ORAA #$80 ; TURN ON VPP
STAA PRU_PA ; UPDATE AND WAIT FOR VPP TO SETTLE

JSR @D_RESET_COP ; RESET COP TIMERS
JSR @D_D10MS_DELAY ; 10MS DELAY
JSR @D_RESET_COP ; RESET COP TIMERS
JSR @D_D10MS_DELAY ; 10MS DELAY

LDAA #$01 ; START A/D CONVERTER CH1
STAA CPU_ADCTL ;
ASLD ; TIME DELAY TO A/D COMPLETE
MUL ;
MUL ;
MUL ;
LDAA CPU_ADR1 ; READ VPP VOLTAGE

STAA @VPP_VOLTAGE ; VPP VOLTAGE FOR REPLY

CMPA #$BC ; 10.5 VOLTS
BCS VPPH_ERR_PVOOR ; VPP UNDER VOLTAGE

CMPA #$E9 ; 13.0 VOLTS
BLS VPPH_PVIR ; VPP IN RANGE

VPPH_ERR_PVOOR LDAA PRU_PA ; VPP UNDER/OVER VOLTAGE
ANDA #$7F ; TURN OFF VPP
STAA PRU_PA ; UPDATE

LDD #$0603 ; MODE 6 MESSAGE: VPP 12V OUT OF RANGE
BRA VPPH_SEND_MSG ; SEND MESSAGE

VPPH_PVIR LDD #$06AA ; MODE 6 MESSAGE: APPLY VPP 12V SUCCESS

VPPH_SEND_MSG PSHX ; MAKE ROOM FOR MESSAGE CONTENT ON STACK
PSHX ;

TSX ; MESSAGE POINTER TO IX

STD $00,X ; SET MESSAGE CONTENT
LDAA @IGN_VOLTAGE ;
LDAB @VPP_VOLTAGE ;
STD $02,X ;


LDAB #$04 ; MESSAGE PAYLOAD 4 BYTES
JSR @D_SEND_ALDL ; SEND MESSAGE

PULX ; RESTORE STACK POSITION
PULX ;

RTS ; DONE




*************************************************
* REMOVE VPP 12 VOLT: VPPL
*************************************************
SET_VPPL LDAA PRU_PA ; PRU PORT A
ANDA #$7F ; TURN OFF VPP
STAA PRU_PA ; UPDATE

LDAA #$00 ; START A/D CONVERTER CH0
STAA CPU_ADCTL ;
ASLD ; TIME DELAY TO A/D COMPLETE
MUL ;
MUL ;
MUL ;
LDAA CPU_ADR1 ; ESIDE PCM IGNITION VOLTAGE

STAA @IGN_VOLTAGE ; IGNITION VOLTAGE FOR REPLY

LDAA #$C8 ; WAIT LOOP 200MS
JSR N_X_1MS_DELAY ;

LDAA #$01 ; START A/D CONVERTER CH1
STAA CPU_ADCTL ;
ASLD ; TIME DELAY TO A/D COMPLETE
MUL ;
MUL ;
MUL ;
LDAA CPU_ADR1 ; READ VPP VOLTAGE

STAA @VPP_VOLTAGE ; VPP VOLTAGE FOR REPLY

CMPA #$5A ; 9 VOLTS
BLS VPPL_PVIR ; VPP IN RANGE

LDD #$0604 ; MODE 6 MESSAGE: VPP OPERATIONAL OUT OF RANGE
BRA VPPL_SEND_MSG ; VPP OUT OF RANGE

VPPL_PVIR LDD #$06AA ; MODE 6 MESSAGE: REMOVE VPP 12V SUCCESS

VPPL_SEND_MSG PSHX ; MAKE ROOM FOR MESSAGE CONTENT ON STACK
PSHX ;

TSX ; MESSAGE POINTER TO IX

STD $00,X ; SET MESSAGE CONTENT
LDAA @IGN_VOLTAGE ;
LDAB @VPP_VOLTAGE ;
STD $02,X ; SET MESSAGE CONTENT


LDAB #$04 ; MESSAGE PAYLOAD 4 BYTES
JSR @D_SEND_ALDL ; SEND MESSAGE

PULX ; RESTORE STACK POSITION
PULX ;

RTS ; DONE

[Tom H]

The read format being used

request
f4 5c 06 [02 00] [20 0b] [20 00] [xx]

[02 00]=load address
[20 0b]=code bra to
[20 00]=start address of data to be read
[xx]=chks


response
f4 d9 06 aa [20 00] [data ....] [chks]

[2000] is the memory offset the data is being read.


It will be hard for me to get to that format. My loader takes: [DEVICE ID] [LENGTH] [MODE] [MESSAGE …] [CHECKSUM]

In the case of mode $06 (that is all I look for/process) the first two bytes of [Message ...] are taken to be the load address and the execute address. I think the loader plus the support for re-flash take up almost the whole internal ram. Perhaps we could use a reply with message starting with $55 to show more messages will follow. Last to have $AA. My intent here is to dump the whole flash to enable someone to see if it is corrupt. Another thought is to just dump the binary with an appended checksum thus bypassing all the GM format. Thoughts? I have about 16 bytes that remain before I need to start removing stuff.
-Tom

[kur4o]

That is great. I feel confident it will work at the end.

The channel 0 matches the ign lookup on eside and channel 1 is stored once but never used, so it is likely the vpp circuit there.

I will mod the tside vpp to work at eside and will give it a try later.

[kur4o]

It will be hard for me to get to that format. My loader takes: [DEVICE ID] [LENGTH] [MODE] [MESSAGE …] [CHECKSUM]

In the case of mode $06 (that is all I look for/process) the first two bytes of [Message ...] are taken to be the load address and the execute address. I think the loader plus the support for re-flash take up almost the whole internal ram. Perhaps we could use a reply with message starting with $55 to show more messages will follow. Last to have $AA. My intent here is to dump the whole flash to enable someone to see if it is corrupt. Another thought is to just dump the binary with an appended checksum thus bypassing all the GM format. Thoughts? I have about 16 bytes that remain before I need to start removing stuff.
-Tom


If there is no space just use what is possible, In the end it will be much easier to add different reading format on the app side than mod the pcm side to cover the existing one.

[kur4o]

Here is modded vpp for eside. Someone willing to upload to eside and report results.

[Tom H]

If there is no space just use what is possible, In the end it will be much easier to add different reading format on the app side than mod the pcm side to cover the existing one.

Done. Here is my proposed code. Execute and it sends 447 $80 byte messages with the reply $06 $55 and the last one is marked $06 $A0



D_SEND_ALDL EQU $0008 ; SEND ALDL MESSAGE
D_RESET_COP EQU $000B ; RESET COP TIMERS
D_F_OE_ACTIVE EQU $000E ; MAKE FLASH OE ACTIVE
D_F_OE_INACTIVE EQU $0011 ; MAKE FLASH OE INACTIVE
D_N_X_1MS_DELAY EQU $0014 ; DELAY: 1MS * ACCA
D_D10MS_DELAY EQU $0017 ; 10MS DELAY
D_CHK_CLR_OC1 EQU $001A ; CHECK AND CLEAR OC1
D_INIT_OC1_20MS EQU $001D ; INITIALIZE OC1: 20MS
D_SUCCESS_MSG EQU $0020 ; SEND SUCCESS MESSAGE
D_SET_VPPH EQU $0023 ; SET VPP TO VPPH: 12V
D_SET_VPPL EQU $0026 ; SET VPP TO VPPL
D_FLASH_IDMC EQU $0029 ; READ FLASH ID, MANUFACTURE CODES


ORG $0000 ; SET ORIGIN

START DB $E4 ; TARGET DEVICE
DB $8A ; LENGTH
DB $06 ; UPLOAD AND EXECUTE PROGRAM SEGMENT
DB $18 ; ADDRESS H
DB $10 ; ADDRESS L

LDY #$2000 ; INITIAL LOCATION LESS $80

NEXT_BLOCK LDX #$1F7E ; BUFFER

LDD #$06AA ; MODE:MESSAGE SUCCESS
CPY #$FF80 ;
BEQ XFER_LAST ;

LDD #$0655 ; MODE:MESSAGE PENDING
XFER_LAST STD $00,X ; SET MESSAGE CONTENT

LDAB #$80 ; SET THE BYTE COUNT

CPY #$0000 ; TEST FOR COMPLETE
BEQ COMPLETE ;


XFER_LOOP LDAA $00,Y ; READ FLASH
STAA $02,X ; SAVE TO BUFFER

INY ; INCREMENT SOURCE
INX ; INCREMENT DESTINATION

DECB ; DECREMENT COUNT
BNE XFER_LOOP ; LOOP TILL ZERO

LDX #$1F7E ; BUFFER HEAD

LDAB #$82 ; MESSAGE CONTENT LENGTH
JSR $0008 ; D_SEND_ALDL

BRA NEXT_BLOCK ;

COMPLETE RTS ;

DB $69 ; CHECKSUM

END START





-Tom

[In-Tech]

Here's some bit/bang stuff we wrote many many years ago to dump some stuff that had intentional clock jitter. Maybe give some ideas.



SaveA: equ $XX ;IO Register address

BTDelay: equ $F0 ;bit delay this can be any value ya like

;
;BootStrap code starts here
;
sei ;enable interrupts, not really necessary
lda #$55 ;55h is the response that basically says you are
;running this bootstrap, can be any value you like
bra Start ;run dumper

SendByte: sta SaveA
clra
bsr DecA ;Inter-Byte delay
ldx #$0A
coma ;invert byte

bclr0 $00 ;5 Zero Bit
bsr DelayBit ;1st Start Bit
bra SetIO ;3

SetIO: bset $00, #0 ;5 One Bit
bsr DelayBit
clc ;2nd Start Bit

SendBit: bcs Send1 ;3

bclr0 $00 ;5 Zero Bit |
bra bitdelay ;3 |count this for timing calc

Send1: bset $00, #0 ;5 One Bit |but not this
bra bitdelay ;3 |

bitdelay: bsr DelayBit
asla a ;3
decx ;3
bne SendBit ;3
bset $00, #0 ;Parity = 0, Stop bits = 1
rts ;6

DelayBit: ;standard 8 bit delay loop
sta SaveA
lda #BTDelay
DecA: deca
bne DecA
lda $XX ;SaveA This is the IO register
rts

Start: bsr SendByte
LongDelay: deca
bsr DelayBit
bne LongDelay
lda #$30 ;Start address of 3000
sta $47 ;Now address stored at 47,48 in ram
lda #$00
sta $48
; ---------------------------------------------------------------------------
dw $7180 ;Change page to eeprom
; ---------------------------------------------------------------------------
Loop: dw $92C6 ;Load A with the value of this next byte address 92C647
;Haven't fixed assembler to allow this new opcode yet
db $47
bsr SendByte
inc $48
bne Loop
inc $47
bne Loop
;need to create "reversible" idling loop here or rts
;
; | 1 STB | | 2 STB |
;
;I/O Pin >---------+ +--------+
; | | | ..... data bits
; +--------+ +--------+

[kur4o]

I just tested the eside vpp apply and it works flawless. It reads both voltages vpp and ign. Now I have to fix a vpp_remove eside one that will allow separate side flashing.

[Tom H]

I just tested the eside vpp apply and it works flawless. It reads both voltages vpp and ign. Now I have to fix a vpp_remove eside one that will allow separate side flashing.

Great news. I have tested routines for checking the ID, programming along with VPP On and Off. I assume that you have some different need but if not, I can just send you the VPP off.

Still waiting on parts from China. My hair is growing faster than things are moving.

I can now work with someone on "UnBrick for ESide". TSide should be easy once we have that experience. Wonder if anyone has a brick and some time on their hands??

-Tom

P.S. It would be even better if we had two volunteers: one with 94/5 and one with 96/7!

[In-Tech]

Hi Tom,
I'm still waiting on my '94/95 pcm to show up but I have a couple '96/97's that are bricked. I have flash chips(E and T), sockets, and programming equipment. I've been playing a little with software attacks but I have no need for these pcm's is why I haven't repaired them yet and plenty of other crapola to do :D Anyway, I can be a tester if you like as time permits.

[Tom H]

Hi Tom,
I'm still waiting on my '94/95 pcm to show up but I have a couple '96/97's that are bricked. I have flash chips(E and T), sockets, and programming equipment. I've been playing a little with software attacks but I have no need for these pcm's is why I haven't repaired them yet and plenty of other crapola to do :D Anyway, I can be a tester if you like as time permits.


Hi Carl,
Sounds OK. I will start working on instructions. Plan is that we will never need flash chips, sockets or programming equipment. I want to keep the conformal coating intact. Let's program in place!

This process is best managed in layers. Let's start with recovering an Eside board from your 96/7 PCM. On your side there are a number of things and setups needed:

- Bricked 96/7 PCM (which you have)
- Bench setup to power it
- USB-serial cable
- Various tools like soldering iron, pliers and so on
- Various electronic bits like resistors and hookup wire
- A PC with a terminal program with the capability to set baud rate to 1890 baud, send binary files to the port, receive and interpret incoming hex characters. I have been using Realterm but I am sure there are a bunch of terminals that will work.
It is also preferred that the terminal display when things like break are present.

I will get to work and post in a day or two. Q for you: Should this be in a separate thread in the forum? Continue here??

-Tom

[sherlock9c1]

Given the overall content so far, I suggest we get an admin to rename this thread and then I'll start another thread about the XDF. I've made progress on the XDF but life got in the way. Hopefully soon here I can get back to it.

[Tom H]

Given the overall content so far, I suggest we get an admin to rename this thread and then I'll start another thread about the XDF. I've made progress on the XDF but life got in the way. Hopefully soon here I can get back to it.
I will just start another thread. Regret the hijack actually. Somehow I inserted a focus of mine and the XDF is an important topic. Did you get anywhere understanding the vectors?

-Tom

[sherlock9c1]

I was getting my feet wet in the disassembly and then life got in the way. Not sure when I can get back to it but I'll update when I can.

[boxsport]

I was getting my feet wet in the disassembly and then life got in the way. Not sure when I can get back to it but I'll update when I can.


Hello guys...
I just read a couple of posts here (didnt haad time to read all completly but will try to) and for what i could read it seems that you guys are worrking on OBD2 LT1 ECMs...
If you allow me i can join the "test team" for the OBD2 LT1 ECMs...
I have one here that i would like to read / flash and see what we can do...
So, if you guys can point me out on where do i start, i will appreciate...
I also have a 95 LT1 ECM here, but there's some internal issues that dont allow to flash. I can read but when it comes to flash i have a VPP Error and it doesnt continue to flash...
For the OBD2 LT1, can we use the same USB-TTL cable or do we need anything else?

Thanks and i hope i can join in with the testing...

Thanks

[sherlock9c1]

Hey boxsport, there's really three parts of the approach here; one is the unbricking, for which more info can be found here: LT1 UnBrick (http://www.gearhead-efi.com/Fuel-Injection/showthread.php?8943-LT1-UnBrick). The read/write flash routine I think is figured out but not implemented (i'm leaving that up to Tom H, steveo and kur4o). The third part is actually defining where all the parameters are in the data files ("bin files"). I was brute force reverse engineering and quickly found the spark, VE, MAF, injector, and some transmission tables. Seeing as I had hundreds more parameters to go, I decided to write an automated finder tool (which then life pulled me away from). This will only find identical tables and non-zero scalars between '95 and '96 files; it won't work for scalars that are 00 or flags. So..

The last piece of the puzzle is actually learning disassembly and piecing through all the memory locations to figure out what scalars and flags are where. This part has the steepest learning curve; kur4o has provided me disassembly to work from but I'm not yet at the point of proficiency, and haven't had time.

If your OBD2 PCM is in a vehicle, you can buy any of these to communicate with it: OBDX PRO VT/ (https://obdxpro.com/product/obdx-pro-vt/). Be aware that every run is quickly selling out so you may have to get on the mailing list to get one.

[boxsport]

Hey boxsport, there's really three parts of the approach here; one is the unbricking, for which more info can be found here: LT1 UnBrick (http://www.gearhead-efi.com/Fuel-Injection/showthread.php?8943-LT1-UnBrick). The read/write flash routine I think is figured out but not implemented (i'm leaving that up to Tom H, steveo and kur4o). The third part is actually defining where all the parameters are in the data files ("bin files"). I was brute force reverse engineering and quickly found the spark, VE, MAF, injector, and some transmission tables. Seeing as I had hundreds more parameters to go, I decided to write an automated finder tool (which then life pulled me away from). This will only find identical tables and non-zero scalars between '95 and '96 files; it won't work for scalars that are 00 or flags. So..

The last piece of the puzzle is actually learning disassembly and piecing through all the memory locations to figure out what scalars and flags are where. This part has the steepest learning curve; kur4o has provided me disassembly to work from but I'm not yet at the point of proficiency, and haven't had time.

If your OBD2 PCM is in a vehicle, you can buy any of these to communicate with it: OBDX PRO VT/ (https://obdxpro.com/product/obdx-pro-vt/). Be aware that every run is quickly selling out so you may have to get on the mailing list to get one.

Thanks for the tips / answers...
Honestly most of the stuff you told me i'm not aware because this is also new to me and i´m trying to learn day by day.
i live in mexico and i´m trying to setup a business mainly for ECM / ECU / TCM / PCM programming / tune, but the learnign curve is VERY BIG... I´m still in the "nobb/dumm" stage...
I mentioned the ECMs i have, but they are not in the car. Its in my small "lab" at home so all the work i do, will be on the bench...
But i´m very interested in helping in anyway a can on your projects...
If i can use these ECMs as "Guinea Pigs" for your project i will be more than happy...
A couple of months ago Steveo and other users helped e out trying to program a 95 LT1 ECM, and for that i´m very thankfull (at the end i was not able to test the ECM on the car 100% because there were some other issues and the guy didnt wanted to spend more time and money on the car)
I'm trying to "fix" the 95 ECM i have here but i cant seem to find the reason for not allowing the Flash.
But the 97 ECM, it seems to be ok. And like i said, if you guys need a "Guinea Pig" for tests, you can count with me and with this ECM.
Regarging the Reading, do you guys have already any file i could use to start making some tests?
Because i´m also finishing my ECU/ECM tester / simulator, and it would be nice for me to test it with the ECM to...
This way i could do the bench test read/flash and try it with my "tester/simulator" to see if the flash work OK and if it works like it should (probably would need to do some updated to my project, but that would be fine).

Anyway, i´m glad i found this thread and i will be reading all the info to learn something with you guys...
PS: I have some tools / cables that might also work for testing (OBDLink SX / OBDLink EX, VagCom HexV2, Kess V2, Ktag, and some others) and see what we could use for this reading / flash / logging...

Cheers

[Tom H]

Hello guys...
I just read a couple of posts here (didnt haad time to read all completly but will try to) and for what i could read it seems that you guys are worrking on OBD2 LT1 ECMs...
If you allow me i can join the "test team" for the OBD2 LT1 ECMs...
I have one here that i would like to read / flash and see what we can do...
So, if you guys can point me out on where do i start, i will appreciate...
I also have a 95 LT1 ECM here, but there's some internal issues that dont allow to flash. I can read but when it comes to flash i have a VPP Error and it doesnt continue to flash...
For the OBD2 LT1, can we use the same USB-TTL cable or do we need anything else?

Thanks and i hope i can join in with the testing...

Thanks


Hi,
You are most welcome to the test team for both the LT1 ECMs. The procedure is for bricked (broken) ECMs and if your OBDII unit isn't broken, I think that there are much better tools to tune/work with the unit. Still if you want to try the UnBrick on it you absolutely can. So far I have just addressed the Eside, but that's a good start. I have not worked with the Tside because my test unit suffered a lobotomy. That is to say the ribbon cable that joins the two sides broke. I have been waiting for months for parts from china (now told that they are with Canada customs).
Regarding your '95 ecm with the VPP fault, this is interesting.You can use the UnBrick software to turn on VPP and debug the problem. The source of the problem may only be the A/D circuit that reads the value of VPP or it could be the actual level. A DVM reading from pin 13 of the ribbon cable will tell you quickly. Use the UnBrick and send the binary file that turns on VPP then take a reading on pin13. I have not yet discovered the part number for the regulator that produces VPP (perhaps someone knows??).



ESide Red/Black: Component side

|
| 29 1
| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
| 30 2
|
-----------------------------------

TSide Blue/Gray: Component side


1 29 |
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 |
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 |
2 30 |
|
-------------------------------------



There is a PDF among the files attached to the UnBrick discussion. Get the latest instruction pdf and work through it.

-Tom

PS: I should qualify the above, My info is based on a '97 unit. I believe the pin number will be the same. You can verify by testing for connection to the flash chip pin 1 on T or E side.