$EE Flash tool progress

[steveo]

so i'm getting more work done with understanding the flash routines.

figured i'd start documenting my progress

while googling around i found this on the aussie forums, and some of the modes seemed familiar from readin' the code, although not identical; for example modes 2 and 3 are different... it seems there are some standards for flash ECMs:



Mode 0 – Clear All ALDL Modes
Mode 1 – Data Frames (There are many different message frames)
Mode 2 – Request 64 Bytes of Memory
Mode 3 – Request 6 Particular Bytes of Memory
Mode 4 – Control Mode
Mode 5 – Enter Download Mode (GM Development)
Mode 6 – Address Of Routine to Execute (GM Development)
Mode 7 – Broadcast Mode (GM Development)
Mode 8 – Disable Bus Chatter
Mode 9 – Enable Bus Chatter
Mode 10 – Clear Malfunction Error Codes
Mode 13 - Security Seed/Key on Flash PCMs
Mode 16 - Flash PCM Write


Now, although there is code for modes 5 and 6 that appear to be related to the flash program, they would not respond in any sane way in $EE

I sniffed a tech tool and found a 0xE4 (length) 0x0D request/response when entering any flash related routine; which corresponded to mode 13. This is definitely a 'challenge/response keyed' ecm.. and I am horrible with math.

First thing i noticed is the key and response is static within a particular bin flash. My test bench ecm always sends/recieves the same code; but my car's ecm has a different 'seed value'. I think it must be generated from some static data in the bin.

I looked at the code and asked kur4o for some insight, he tipped me off where the key/seed are likely stored in memory. I found a 16 bit compare from 0x0E02 on the t-side to the incoming two bytes in a mode 0x02 request that confirms that's where the key is stored..

We noted they are passed from t-side to e-side unmodified, meaning the two halves of the ECM always share a key, which makes life easier.



(T-Side)
L0E00_M13SEED = $0E00 ; 16bit
L0E02_M13KEY = $0E02 ; 16bit


Then I read the code again myself.

After some staring and writing pseudo-code, I couldn't figure out where the hell the seed/key math is, or how it works, although it must be simple. Flashing some new bins on my test bench ECM seemed to cycle the key a bit, so i used the opportunity to gather some data and see if i could reverse the math that way.

Then my coffee kicked in and I thought up a great workaround. Since the generated keys are stored in memory and not a register, and not cleared after being generated.. Just grab them with mode 3 requests!



.. .. .. xx xx ..
f4 58 03 0e 00 [CKSUM] ; low byte of seed
f4 58 03 0e 01 [CKSUM] ; high byte of seed
f4 58 03 0e 02 [CKSUM] ; low byte of key
f4 58 03 0e 03 [CKSUM] ; high byte of key


Seems to work with one caveat, on a cold boot, you have to make a request for the key first before it'll hit the mode 13 subroutine and generate a challenge/response in memory.

So here's the mode 13 synopsis (where ecm_addr is 0xF4 for t-side and 0xE4 for e-side):


request seed: you->ecm [ECM_ADDR] [MSG_LEN] 0x0D 0x01 [CHECKSUM]
get seed: ecm->you [ECM_ADDR] [MSG_LEN] 0x0D 0x01 [SEED_LOW] [SEED_HIGH] [CHECKSUM]
(or if ecm already unlocked) ecm->you [ECM_ADDR] [MSG_LEN] 0x0D 0x01 0x00 0x00 [CHECKSUM]
sumit key: you->ecm [ECM_ADDR] [MSG_LEN] 0x0D 0x02 [KEY_LOW] [KEY_HIGH] [CHECKSUM]
if unlocked successfully: ecm->you [ECM_ADDR] [MSG_LEN] 0x0D 0x02 0xAA [CHECKSUM]


Now that mode 5/6/etc are working and the ecm is in development mode we can have some real fun......

[steveo]

Seems to work with one caveat, on a cold boot, you have to make a request for the key first before it'll hit the mode 13 subroutine and generate a challenge/response in memory.

I take that back, it was a timing issue. Works first time every time.

[steveo]

looks like you need to use mode 0x05 to enable any of the mode 6 comms with a simple request to both the t-side and e-side. you send 0x05 and you get back 0x05 0xAA if successful.

it appears that 0x05 does a whole bunch of checks, and probably sends something other than 0xAA if it's unsafe to program (car running or whatever)

[kur4o]

I was wondering all day what algorithm is used.
Dig through alot of bins to get the seed key pairs.
Than I remeber i have a list with 256 gm algos for seed key request used with obd2 pcm, with short description stating they were developed in 1993. I look through them and still couldn`t figure out anything.
After staring at the pairs for a long time I found some patterns and here is the algorithm
swap algorithm;
seed digit =key digit or vice versa
7=8
6=9
5=a
4=b
3=c
2=d
1=e
0=f

example seed 5c60
key a39f

Funny thing I found if PCM denies mode 5 and 6 it sends answer $33, which is also used in OBD2 PCM which means Security access denied.
I guess $aa means security access granted.

05 mode do some big loop routine, still very unclear what`s the purpose for it.

Have you figure out how mode 6 works. Do you think it can be used to modify single memory bytes.


There is some list for ALDL modes from EFilive v4 program

11 write programm data
10 download and execute 3 byte address
0f examine memory 3byte address
0e memory dump 64/3 byte address
0d security access mode
0c modify memory
0b normal communication
0a clear codes
09 resume
08 suspend
07 command message (MODULE TO MODULE COMMUNICATION)
06 download and execute
05 download
04 device contol
03 examine 2 bytes address
02 memory dump 64/2bytes address
01 request aldl frame
00 normal communication

Mode 0c is used for writing vin and CALid to PCM eeprom memory

[steveo]

After staring at the pairs for a long time I found some patterns and here is the algorithm
swap algorithm;
seed digit =key digit or vice versa
7=8
6=9
5=a
4=b
3=c
2=d
1=e
0=f


nice work buddy!! i was fully staring at it in 8 bits... i never thought to look at it in 4 bit nibbles, where it becomes so clear.

i might just keep my mode3 method for eehack, though, i think it's hilarious that it works so well


05 mode do some big loop routine, still very unclear what`s the purpose for it.

i'm staring at it too. i have no idea. once entering mode 5 the ecm seems to happily resume normal operation.


Have you figure out how mode 6 works. Do you think it can be used to modify single memory bytes.

i'll bet it can, it seems to be used for loading a certain amount of indiscriminate code into ram which you can pass execution to.

i have a log of a tech flash routine, so i know what it looks like...

it seems that message 0x00 and 0x01 are used to load executable code into ram for execution? it seems to load a chunk of the bin file itself into ram before it flashes? im not sure, it might also be how it erases EEPROM since there's no specific instruction for that.



you->ecm:
f4 d8 06 01 6d 86 aa 36 18 30 86 06 c6 01 fe ff bc ad 00 32 39
33 1d 2d 08 18 38 32 39 bd 01 93 1f 2e 80 f9 a7 2f 9b 2e 97 2e 39 37 c6 55 f7 10 3a 53 f7 10 3a c6 50 f7 18 06 c6 a0 f7 18 06 33 39 3c ce 10 02 1d 00 08 38 39 3c ce 10 02 1c 00 08 38 39 36 20 03 36 86 0a 37 4d 27 0b c6 4b bd 01 93 5a 26 fa 4a 26 f5 33 32 39 37 fc 10 0e fd 10 16 33 7f 10 22 20 07 b6 10 23 84 80 27 05 86 80 b7 10 23 39
e9 -> f4 57 06 aa 05


if you look closely at it, you'll see that 33 1d 2d 08 and so on are taken right from an $EE bin file; this forms a 128 byte chunk. this continues until all of the code from the bin from 0x0000-0x01FE is written backwards, THEN it seems the flash procedure begins using message 0x03 chunks? this may be a bootstrapping procedure, as obviously execution from flash memory is impossible once it's erased.

my theory is it then passes control flow to that code, then it uses messsage 0x03 to send chunks of the bin file itself 128 bytes at a time into ram, including an offset parameter; then perhaps the executable code sent earlier reads it and flashes it.

the flash data itself is written as follows using message 0x03,:



F4 DE 06 03 00 BD 02 1a (ADDR) (ADDR) (NUMBER OF BYTES) [ 128 BYTES OF DATA ] CKSUM

[steveo]

i love a good mystery. mode 6 is obviously used to transmit data, but the flash routine itself is still elusive; and it makes very little sense that it would be obvious.. you can't flash something you're already running on.

so the e-side and t-side code and data starts at 0x2000, and 0x0000-0x1FFF is addressed as RAM, correct?

so what the hell is in the first 8KB of the bin that can never be addresed during normal operation? im not sure how a 68k works in this respect, is that boot code?

my disassembler won't recognize it, but at least the first 400 bytes or so seem to be code. it's possible some of this code is used to bootstrap the ecm into an alternate operating mode to be run during flash read/write. i think im on the right track digging into that a bit more. the tech tool definitely sent a bunch of data from that section of the bin.

it's also possible 0x0000-0x1fff is addressed to the onboard flash memory of the 68k chip (which does have its own small flash, afaik) and that's what runs during flashing. that might make some sense; flash the external by passing control flow to the small onboard flash, which contains just enough swag to manage communication?

then there's the big hunk of glaringly obvious string table at 0x3C89 which is a smoking gun for sure, as a pointer to anything that might be an actual flash routine... but i can't find references to it in other parts of the code (yet!).

..2.9..ERASING FLASH ON TIME SIDE. ..PROGRAMMING FLASH ON TIME SIDE. @.ERASE VPP HI ERROR - TIME SIDE. @.ERASE VPP LO ERROR - TIME SIDE. @.PROGRAMMING VPP HI ERROR - TIME SIDE. @.PROGRAMMING VPP LO ERROR - TIME SIDE. @.FLASH ERASE FAILED - TIME SIDE. @.FLASH PROGRAMMING FAILED - TIME SIDE. @.FLASH FAILED TO PGM TO ZERO - TIME SIDE..FLASH ERASED OK - TIME SIDE. @.FLASH PROGRAMMED OK - TIME SIDE. @.FLASH MAY NOT BE PROGRAMMED WITH THE ENGINE RUNNING - PLEASE TURN OFF ENGINE @.IMPROPER MANUFACTURER - TIME SIDE @.IMPROPER DEVICE CODE - TIME SIDE ADDR= RD= WR=

[RobertISaar]

up to 1FFF is RAM and "RAM"... I want to say a few auxiliary chips are addressed in that range in addition to some of the internal functions of the 6811F1 itself.

what you see in a pulled BIN in the earliest sections of RAM is likely whatever the flash tool has uploaded to the PCM as a download routine, that's why it looks like code.

the F1 does have some onboard EEPROM, exact address is code dependant, but I would expect to see it in the E00 range.

[kur4o]

You are right there is some code stored at the beginnig of the bin. I made a quick dissasembly. It looks like the main programm for the processor with its own stack and some memory bytes.
I also found the address that points to jump location when download is complete and is time for execute, on tside is 1990, on eside 1887. I guess it is loaded from ALDL message. In that case it points to 0000 where the code starts.

The flash chip has some vpp pin that needs to have 12V for read write to happen.

I guess 12v is applied via a relay and is commanded from main processor.
I check board schematics and on the two flash chips this pin is connected to same locations and points to pin 1 on m36av chip on eside.
That is why there is some relay engaged in the code and points to 1803 and 1806 addresses.
I am still digging in the board so expect more updates.

Here is the disassembly.

[steveo]

thanks to both of you, that's great info. i'll ponder it. i can just replicate the behavior of the tech's flashing routine but i'd rather understand the process before i even try.

so it's pretty obvious that we're loading actual code into ram, executing it, and then that code will respond to mode 6 requests. so we have to write our own flashing routine (or yoink one from GM....)

i want to figure out exactly what mode 0x06 does.

so far i've observed four messages, 0x00, 0x01, 0x02, and 0x03.

just from observation, 0x02 is definitely 'execute code'. this is super awesome. we can do ANYTHING with it. dropping assembly into empty memory could allow jumping off to practically any other instruction or whatever. this message also seems to have an optional reply? instead of f4 57 06 aa [checksum] for example, i also see f4 59 06 aa xx xx [checksum] as a reply. i could make my eehack program do practically anything.

0x03 only seems to be used for programming during the flash routine for programming.

0x01 and 0x00 are confusing to me, they seem to be for loading stuff to memory that's not directly executed, but executed later.

so that's it for external observations, im off to disassemble the actual mode 6 code and see what i can find.

[steveo]

up to 1FFF is RAM and "RAM"... I want to say a few auxiliary chips are addressed in that range in addition to some of the internal functions of the 6811F1 itself.

what you see in a pulled BIN in the earliest sections of RAM is likely whatever the flash tool has uploaded to the PCM as a download routine, that's why it looks like code.

you hit the nail on the head; i just wasn't seeing it.

so it seems like since all the bins on the internets are pulled using tunercat's winflash tool; and they have data in all of those sections; although an $EE bin file itself could be all 0x00 in that area....this also means theoretically that most bins on the internet have tunercat's bin read program still stuck in their first bytes, but with any volatile memory in a different state. i have compared most of my bins and found they're mostly identical in that area.

i find it suprising none of the programmers of these tools just 0x00 those areas? since lt1edit's read bins have identical code as bins from tunercat's tools, i can only assume that download routine was taken directly from a gm tool and probably is not original code.

so, all the flash read/write code is stored on the TECH tool and sent to the ecm with mode 6 then executed. i really need to get the entire flash routine now and pick it apart a bit.

one thing that bugs me is what's with the string tables in the data section of all EE bin files? i can theorize that the tech tool reads those just for convenience during flashes so it has the messages to display; but it still seems im missing something.


the F1 does have some onboard EEPROM, exact address is code dependant, but I would expect to see it in the E00 range.

yep! 0x0E00 seems to be the onboard memory, there's the vin number there on t-side.. e-side has one too but it's all 0xFF. 256 bytes i assume? this may be a cool spot to store stuff that's saved between flashes, or for a quick flash of some kind; perhaps store a table there to be reflashed in short without having to reflash the entire bin; as i'm sure this can be programmed independantly in the same way that vin changing tools work. i think i remember kur4o mentioning this before too.


I guess 12v is applied via a relay and is commanded from main processor.
I check board schematics and on the two flash chips this pin is connected to same locations and points to pin 1 on m36av chip on eside.
That is why there is some relay engaged in the code and points to 1803 and 1806 addresses.
I am still digging in the board so expect more updates.

awesome! is the relay perhaps for erase?

im going to get the whole flash routine and start to disassemble it.

[RobertISaar]

being a F1 variant, it SHOULD have 512 bytes of EEPROM. being built to GM's specifications, hard to say until you play around and potentially misuse some of the area that is or isn't EEPROM. see what sticks and what doesn't. being at E00, it should cover all the way to FFF, where aux stuff should pick up.

[RobertISaar]

also, I don't know if I would want to be using that area as essentially a scratch pad unless you can store 2 copies of a table in it... pretty sure the erase/write process takes quite some time for all 512 bytes, but considering the documentation Motorola gave, it seems like you can do row erases and essentially only update what is needed.... while writing new values, reference old ones, which would then get updated once the new values are written to another table, buffering to keep them both up to date.

[steveo]

i made a poor assumption about mode 6, that it had different operating 'messages' kind of like a mode 1. it made me totally ignore the fact that the addresses are right in front of me, and it only does one thing: 'write and execute'.

i also can only assume that it's 'execute only' because i can write a jump instruction to memory and it works, but if i write something that doesn't jump, the ecm locks up. i bet this is because control flow simply tries to go through memory from its new entry point and it goes haywire....

anyway, write and execute:



[addr] [length] 0x06 [low addr] [high addr] [data ...] [cksum]


there is no seperate 'data length' specifier like you'd expect, i can only assume that the mode6 sub uses the standard msg length header byte to figure how long the payload is.

so perhaps to actually write arbitrary ram with mode 6, you'd have to write some code that stores your values then jumps back to the main event loop after; and write that to an unused portion of ram somewhere.

now, how is the (relatively large) flash routine is loaded in multiple messages then executed when complete?

took me a few minutes to understand, but makes sense.

its' written to memory backwards, starting at the top, with a small prefix of code that seems like it jumps back to the mode6 code, or some such thing. each following payload is offset to write over the previous's loader prefix. this loader is as follows:


86 aa 36 18 30 86 06 c6 01 fe ff bc ad 00 32 39

it continues to load the routine into early ram until it reaches 0x00 where no loader is placed in memory, and the entire payload can be executed starting at 0x0000. so that's how you load a large routine.

so using that loading knowledge, i peiced together the code binary for each side by yanking it right out of the datastream.

i really want to disassemble it and see how it works.

t-side:



20 49 20 47 00 00 00 00 00 00 00 00 00 00 00 00 20 00 ff ff 7e 01 2c 7e 01 93 7e 01 a9 7e 01 b2 7e 01 bb 7e 01 be 7e 01 e0 7e 01 d3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8e 00 4a 0f b6 18 01 8a 80 b7 18 01 b6 18 00 84 7f b7 18 00 b6 18 03 84 bf b7 18 03 b6 10 09 8a 01 b7 10 09 b6 10 08 84 fd b7 10 08 b6 10 03 8a 08 b7 10 03 bd 01 a9 3c 30 13 32 01 07 cc 06 01 ed 00 20 08 14 32 01 cc 06 aa ed 00 c6 02 bd 01 2c 38 ce 10 00 86 04 a7 2d ec 2e 4f 97 2e 1c 2d 02 8d 52 81 f4 26 eb 8d 4c 80 56 25 e5 97 31 8d 44 81 05 27 2e 81 06 26 d9 8d 3a 97 2c 7a 00 31 8d 33 97 2d 7a 00 31 18 de 2c 8d 29 18 a7 00 18 08 7a 00 31 26 f4 8d 1d 5d 26 b7 18 de 2c 18 ad 00 20 af 8d 10 3c 30 cc 05 aa ed 00 c6 02 bd 01 2c 38 7e 00 9d 18 3c 18 ce 05 75 7f 00 2f 7a 00 2f 26 04 18 09 27 07 bd 01 93 1f 2e 0e 05 38 38 7e 00 9d 1f 2e 20 e7 a6 2f 16 db 2e d7 2e 18 38 39 36 18 3c 3c 18 38 ce 10 00 86 08 a7 2d 37 c6 0b 5a 26 fd 33 b6 18 03 8a 40 b7 18 03 b6 18 02 8a 40 b7 18 02 4f 97 2e 86 f4 8d 2e 17 8b 55 8d 29 18 a6 00 8d 24 18 08 5a 26 f6 96 2e 40 8d 1a 1f 2e 40 fc b6 18 03 84 bf b7 18 03 37 c6 0b 5a 26 fd 33 1d 2d 08 18 38 32 39 bd 01 93 1f 2e 80 f9 a7 2f 9b 2e 97 2e 39 37 c6 55 f7 10 3a 53 f7 10 3a c6 50 f7 18 06 c6 a0 f7 18 06 33 39 3c ce 10 02 1d 00 08 38 39 3c ce 10 02 1c 00 08 38 39 36 20 03 36 86 0a 37 4d 27 0b c6 4b bd 01 93 5a 26 fa 4a 26 f5 33 32 39 37 fc 10 0e fd 10 16 33 7f 10 22 20 07 b6 10 23 84 80 27 05 86 80 b7 10 23 39


e-side:



20 3c 20 47 00 00 00 00 00 00 00 00 00 00 00 00 20 00 ff ff 7e 01 24 7e 01 8b 7e 01 a1 7e 01 aa 7e 01 b3 7e 01 b6 7e 01 d8 7e 01 cb 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0f b6 18 02 84 fc b7 18 02 86 49 97 01 8e 00 4a 0f b6 18 01 8a 7f b7 18 01 b6 18 03 84 fb b7 18 03 b6 10 09 8a 01 b7 10 09 b6 10 08 84 fd b7 10 08 b6 10 03 8a 08 b7 10 03 bd 01 a1 3c 30 13 32 01 07 cc 06 01 ed 00 20 08 14 32 01 cc 06 aa ed 00 c6 02 bd 01 24 38 ce 10 00 86 04 a7 2d ec 2e 4f 97 2e 1c 2d 02 8d 52 81 e4 26 eb 8d 4c 80 56 25 e5 97 31 8d 44 81 05 27 2e 81 06 26 d9 8d 3a 97 2c 7a 00 31 8d 33 97 2d 7a 00 31 18 de 2c 8d 29 18 a7 00 18 08 7a 00 31 26 f4 8d 1d 5d 26 b7 18 de 2c 18 ad 00 20 af 8d 10 3c 30 cc 05 aa ed 00 c6 02 bd 01 24 38 7e 00 95 18 3c 18 ce 05 75 7f 00 2f 7a 00 2f 26 04 18 09 27 07 bd 01 8b 1f 2e 0e 05 38 38 7e 00 95 1f 2e 20 e7 a6 2f 16 db 2e d7 2e 18 38 39 36 18 3c 3c 18 38 ce 10 00 86 08 a7 2d 37 c6 0b 5a 26 fd 33 b6 18 03 8a 04 b7 18 03 b6 18 02 8a 04 b7 18 02 4f 97 2e 86 e4 8d 2e 17 8b 55 8d 29 18 a6 00 8d 24 18 08 5a 26 f6 96 2e 40 8d 1a 1f 2e 40 fc b6 18 03 84 fb b7 18 03 37 c6 0b 5a 26 fd 33 1d 2d 08 18 38 32 39 bd 01 8b 1f 2e 80 f9 a7 2f 9b 2e 97 2e 39 37 c6 55 f7 10 3a 53 f7 10 3a c6 50 f7 18 06 c6 a0 f7 18 06 33 39 3c ce 10 02 1d 00 08 38 39 3c ce 10 02 1c 00 08 38 39 36 20 03 36 86 0a 37 4d 27 0b c6 4b bd 01 8b 5a 26 fa 4a 26 f5 33 32 39 37 fc 10 0e fd 10 16 33 7f 10 22 20 07 b6 10 23 84 80 27 05 86 80 b7 10 23 39


so how does it work? i haven't disassembled it yet, but i have confirmed the following...

another mode 6 request will write a payload to memory at 0x0300 (well past the range of the existing code):



[addr] [len] 06 BD 02 1A [low_addr] [high_addr] [n_bytes] [payload ...] [cksum]


i think 0xBD is 'jump to subroutine'. so after placing the data there, it calls what i can only presume is the flash sub, which comes back and writes that data before exiting. that way it can drop its data payload without executing it.

to read flash memory:



[addr] [len] 06 02 00 20 0B [low_addr] [high_addr] [cksum]


reply is



[addr] [len] 06 AA ?? ?? [payload ...] ?? (CKSUM)

[kur4o]

Now it becomes crystal clear for mode 5 and 6.

When you send mode 5 request you enter in some infinite loop (mode 5 loop), maybe with some timers to disable interupts and when they expire main code takes control.
Mode 6 is allowed through mode 5 loop and is executed inside it, because on main programm there is nothing for mode 6.

Mode 6 writes to ram and execute from the first byte of written data. So if it`s only data you need to enter 3 bytes header jump to location( some vectors or main programm).

Now back to loader routine
Disassembly of the first line
RAM:030C ; ---------------------------------------------------------------------------
RAM:030C ldaa #$AA ; 'ê'
RAM:030E psha
RAM:030F tsy
RAM:0311 ldaa #6
RAM:0313 ldab #1
RAM:0315 ldx off_FFBC
RAM:0318 jsr 0,x
RAM:031A pula
RAM:031B rts
RAM:031B ; ---------------------------------------------------------------------------

The jump location points to subroutine inside mode 5 loop, so this handles back control to mode 5 loop for more loads.
When you reach to 0000 it execute from there in our case

RAM:0000 loc_0: ; DATA XREF: SOFTr XIRQr ...
RAM:0000 bra sub_4B
RAM:0002 ; ---------------------------------------------------------------------------

[kur4o]

This modes open some very interesting points for real time tunning with some minor tweeks in the code. It must be loaded real fast before the engine hangs or ram is loaded with ignition on, engine off. On running engine and moving car is not possible to enter mode 5 due to rpm and mph check. Good news is mode 0d can be bypassed and rpm and mph limits raised to access directly mode 5. It must be tested on engine runnig first.
I am starting new task to find all free memory locations.

Will try to find the status on vpp pin on idle and on read.
Manual says voltage must be above 6.5V or chips can`t be erased.

[steveo]

yeah that's awesome!

i actually have yet to see the "flash erase" routine. whatever it is, it's contained in that large chunk o' code somewhere.

i have to look more carefully over my serial dumps; but it seems like once that program is loaded, procedurally it seems you just start throwing the bin at it and hope for the best; so im not sure where the success/fail code is. perhaps it only sends 'flash failed' response somewhere if it flunks, we need to find that and dissect how errors are done.. it may contain a pointer to the string table as a dead giveaway, as when it fails it should point to the error string for the TECH tool to display.

as far as doing 'fun things' with mode 6, i think if you're going to hack it to make running changes, it might be more advantageous to just patch in an alternative mode, basically a mode 3 that writes a few bytes instead of reading them. that way you dont have to deal with all those loop entry/exit bullshit that only seems necessary if you need to exit control flow from flash.

[steveo]

there's quite a bit i missed in those serial dumps. i have to do a lot more reconstruction. i think i did find the flash erase routine.

[steveo]

I was wondering all day what algorithm is used.
Dig through alot of bins to get the seed key pairs.
Than I remeber i have a list with 256 gm algos for seed key request used with obd2 pcm, with short description stating they were developed in 1993. I look through them and still couldn`t figure out anything.
After staring at the pairs for a long time I found some patterns and here is the algorithm
swap algorithm;
seed digit =key digit or vice versa
7=8
6=9
5=a
4=b
3=c
2=d
1=e
0=f

example seed 5c60
key a39f

after trying like an idiot to express that mathematically with actual math so i didn't have to use a reference table, i realize that the $EE seed/key 'algorithm' is simply a binary NOT.



SEED 5C60=0101 1100 0110 0000
.KEY A39F=1010 0011 1001 1111

[steveo]

the 'routine' executed and stored at 0x0000 is mostly just for collecting mode6 data and executing it. it's like a really basic gm development operating system just so further programming can be done without any use of the flash memory. it doesn't seem to do much but communications and 'waiting', it's kind of like the big mode 5 loop.

this loop appears to be infinite

the flash routine, erase routine, etc. is written later in the clear to 0x0200, and after each 'command' is finished, control is passed back to control loop earlier in memory.

[kur4o]

That`s exactly as my observation.
The flash data is send with some code in front that points to sub address.
I guess at 0200 can be send multiple sub which are overwritten, like flash erase. flash read or flash write.
The sub I have on bin at 0200 looks like some checksum routine. I guess it is for reading bin file, since it is taken during reading.
Maybe the flash process is : load mini mode 5 loop, start communication from there, load erase sub at 0200, handle control to the loop, load flash sub at 0200, handle control at loop, start sending bin with first few bytes point to flash sub, hanle control to loop,and so untill flash is done, than send reset sub and start normal communication.

As for tuning options, I have been thinking for loading big tables with switch bit that change loading point for table.
It can be done very easy for ve maf or spark tables, The only obstacle will be enough free ram region.
It is really good that commands can be executed, that way you can send mini routines that load some byte, change its value and than handle control to some main routine. the only problem will be entering mode 5. I leave the interface for you and will hack mode 5 for easy access, handle the loading points and do the bin patches.

Mode 4 can be hacked with submodes but when bytes are loaded to memory they need to have fixed location.
I will compile some mini sub to test various switches and relays but for that I will need some good interface to send commands.
Can I ask you what are using for that purpose?

[steveo]

I will compile some mini sub to test various switches and relays but for that I will need some good interface to send commands.
Can I ask you what are using for that purpose?

i mostly just add code to my eehack program directly to test things.

i think i will make an interface for that soon, but what would you like? type into a field in hex? automatic checksum byte? automatic length byte?

for the reply, is raw hex ok? or would you like conversion?

[kur4o]

Auto checksum and lenght will be awesome.

I have tried some comm port programs for sending data and couldnt make them to work properly, so what you offer will work as long it has custom timing settings.
Raw hex is fine, hopefully it can be arranged in blocks 16 bytes long and a time stamp and identifier data send, data recieved and be color coded if that`s possible.
Repeat switch with pause delay, or sending different commands in array, every commands with its own repeat settings.
I know these are only ideas, and will be happy with whatever is possible.

I found some free memory space long enough to take the main VE table, it`s 0245-03ff on eside. It still needs to be checked on running engine.

[RobertISaar]

odd that the 245-3FF block was left open from the looks of it, that's nearly 450 bytes of RAM.

[kur4o]

That region is used during flashing the chip for temporary data storage. Maybe that`s why they left it empty, didn`t want anything to interfere with. On Tside is smaller around 258 bytes.
Writing to processor eeprom is not possible without loading it first to memory and than execute special routine to transfer data to the eeprom.
Checked the vpp pin. On idle is 0.05 V, during flash it goes to 12 V. So the relay must be activated by 1806 or 1803 switch bytes.
Also managed to disable mode 0d and it works well. Now it goes to mode 5 without security isssues.

I also played with one v6 flash pcm of that era and it looks that mode 5, 6 and 0d are coded the same way.
They share most of the transmission code too.
I wonder, what other PCM of that years have these routines implemented . It will be real fun to play with these.

[RobertISaar]

there were only two series of OBD1 P66 PCMs with flash PROMs that I'm aware of, you've got both. the only other OBD1 P66 I'm aware of is the northstar PCM, but that has two EPROMs in a single MEMCAL.

[steveo]

i can't imagine that memory hole is related to flash/development. once the development routines are loaded and executing, all the rest of that memory is pretty much up for grabs as the ordinary code doesn't execute anymore, right?

perhaps we can increase the resolution of something using that extra memory; what about increasing the size of the blm grid?

anyway i am experimenting a bit more, but flash read is working great; i can't make it fail. timing optimization was a bit odd, execution time of some routines used is oddly long.. you have to wait quite a while before sending the next request or it simply won't read, but the read requests themselves exist in a very short loop so i have pretty much saturated 8192 baud (obviously minus the time that it takes to send the mode 0x06 code itself...)

the one odd peice of trivia i've run into is mode 0x0D t-side doesn't always send the correct key after a cold ECM boot; and in fact requesting it again before the timer expires doesn't help either.

but if you make a request, fail, wait, then make a few mode 1 requests or something to kick it back into the loop, the next 0x0D challenge/response will succeed every time. making a bunch of initial mode 1 requests doesn't help either. i can't quite explain it.

i ran into this when using my 'cheat' reading the challenge/response directly from memory with mode 0x04 too.

any idea what's going on there? i wonder what conditions have to be met to generate the key?

[kur4o]

There are lots of other memory regions that are not used but are not that long. I was looking for something long enough to take at least the main ve table.

What exactly do you mean with cold boot. I was trying to find fuel pump switch, logging the first couple seconds after ignition is on and always got corrupted data. I guess there is some initializing time from reset when aldl is not working right. I left it logging for long time and still couldn`t get right data unless disconnect and wait some time.
Another problem could be that the seed is stored at the eeprom memory of processor and the seed is transfered via spi to eside. Reading eeprom might take time after reset is done or the ALDL chip needs some time to reset itself.

[steveo]

Another problem could be that the seed is stored at the eeprom memory of processor and the seed is transfered via spi to eside. Reading eeprom might take time after reset is done or the ALDL chip needs some time to reset itself.

could be. i think i'll just write a smart retry algorithm that'll eventually get the correct key.


I was trying to find fuel pump switch

yes please!

[steveo]

here we go, this reads the bin for me every time (except sometimes doesn't break security and you have to reconnect), also has a custom command mode for kur4o, just two mode/message fields with a log! please help me test it!

http://fbodytech.com/files/eehack-3.3.zip

[steveo]

so it seems as if the ecm has no problem just dumping its entire flash memory via mode 0x02 requests.

obviously this only works on t-side, so if we patch mode 0x02 to work on e-side.. we can read with no programming or special modes, 64 bytes at a time.

this is super awesome, since now my eehack tool can load entire tables and constants!

[kur4o]

I have a patch for eside for mode 02 and 03, tested and working. You can add it as mandatory for some extended parameters.
It is as simple as two bytes changed. I have it in the Eside ALDL patch included, but also can make a separate only 2 and 3.

[steveo]

i'd prefer a seperate patch, just let me know what needs to be changed

[kur4o]

For mode 02 change byte_1824C to $41 (default is $80)
For mode 03 change byte_18256 to $11 (default is $80)

[jthompson122183]

here is what is in the tunercats tdf editor for flash programming

9785

[steveo]

here's my idea for the day.

im already planning on selective tside/eside flashes (if the user presents the 'old' bin for comparison, program only flashes eside/tside selectively).

half as much flashing is potentially twice as much safety, less wear and tear, and lots of saved time.

but i had one more idea

in an eeprom like this ecm has, erasing it effectively SETS all bits, right? and 'programming' it is the act of unsetting any bits that are zero?

so technically, if after erasing, the entire eeprom is 0xFF?

so i could map out areas of the bin that are continuous areas of 0xFF (there are quite a few) or areas which are known to be ignored/unused, and selectively not flash them?

[RobertISaar]

i don't see why not, but then you'll be stuck if you want to upload a patched BIN, or at least need to allow for changes to the flashed area.

if these PROMs supported selective erasure(I don't think they do), then you could have something like what most of the OBD2 programs do and only bother erasing and updating calibration blocks. safer too, since if there were an issue, code would still exist to allow for a flash without having to pull the PROMs.

[steveo]

yeah i think they're 'apply voltage and erase the whole thing' style eeproms.


i don't see why not, but then you'll be stuck if you want to upload a patched BIN, or at least need to allow for changes to the flashed area.

i was thinking probably skipping 'unused' areas is generally a bad idea, but the e-side has TONS of unused space, so i'll have an accelerated e-side flash routine that can be disabled for people that patch that side.

that's on top of checking each bin for sequences of 0xff and determine optimal spots to skip there

[steveo]

at the point where i'll need testers with socketed ecms (or spares), any takers please post or pm me

[lionelhutz]

I just looked at the datasheet for the AN28F512. You have to send the chip an erase command and that erases the whole chip. Then, you have to verify it's erased by using the erase verify command on each address. checking for FF. The datasheet says to attempt erasing up to 6000 times if you encounter a byte that isn't FF during the erase verify. Basically, if the 11th address fails to read FF then you hit it with another erase command and then start using the erase verify commands at the 11th address until you've read them all or you find another failure and then you erase again and keep going.

Then you have to use the write command and the write verify commands to write each byte, repeating the write command each type the write verify fails to return the correct data. The datasheet says to attempt programming each byte up to 25 times, but the first or second time usually verifies correctly.

[steveo]

sounds like what i read last night!

from the tool's perspective, once the code is run, it sends message 0x55 repeatedly (one would assume while erase is still not done), then sends 0xAA when finished.

i'm working on disassembling the GM erase routine right now to see what's done on the code level.

the amount of time seems to vary, probably while it's repeatedly erasing the chip and re-testing. i have figured out the structure of the code but not exactly what it's doing. i'll post a disassembly when it's ready.

understanding this routine is important, since the erase operation seems to be a common time for it to fail.

[kur4o]

In the disassembly there is alot of mystery aa and 55 bytes compare. Today I found in an eeprom soft that there is option to fill empty chip with 00(00000000) 55(01010101) aa(10101010) or ff(11111111). These are equally spaced, and I guess are state of the bits or maybe erase the bits in cross patern. Maybe these checks are to verify the chip got erased and written successfully. At least I have a starting point now.

[steveo]

big news! i ordered some sockets n chips off ebay for my spare ecm, so i decided to just bite the bullett and try the flash routine

and it kinda worked! it got all the way to 0xFFFF! .... but tried to write a few bytes out of bounds and failed due to a math error on my part

however i did learn three things..

1. it's almost perfect!
2. writing out of bounds does produce an error
3. my write failure mode worked perfectly! if it gets a series of write retry failures (which it did in this case), it assumes either a flash error or communication error, then jumps back to the main routine, tries to erase that chip again, and start over. since i knew it was done for anyway, i let it run for an hour and had no errors except that final write failure.

so i'm almost there!

[steveo]

so i redid it and bricked kur4o's ecm too

on reivew, it worked perfectly up until the last packet again (0xff80-0xffff), until an off-by-one error occurred in a check in the 'write' packet builder that i'd placed to prevent writing out of bounds. it returned an error and the last 0x80 bytes never got written.

im really sucking at off-by-one errors lately.

but i think i have it nailed now!

to make matters worse my 'retry' routine kicked in since it hit a fail condition, and constantly tried to re-erase that side and try again to get a successful completion. i do like that failure mode but as mentioned, i think it needs to give up after a few tries.. i'll build that into the logic somewhere.

[steveo]

kur4o tried again and it wrote the t-side image to both sides.

i found the problem; just an equals sign.

in c++, == compares two values, and = stores a value. i had stored 0xF4 when i meant to compare it and figure out which side to flash... derp!

i fixed that and gambled my car's ecm on it, and it worked!

also tried selective write (only eside and only tside) and it seemed to work well, which is great, because it cuts flashing time in half if you just tweak one table...

so, more testing required, but i think we're about one or two bugs away from a free (and awesome) flash tool for $EE!

[fastacton]

Good work!

[fbody_Brian]

Snagged a spare ecm at the pick and pull today!
$30.
I got the connectors with it, so I have a bunch of extra pins and the possibility to hook it up on the bench.
There are never any LT1 cars out there, so I got pretty lucky.
Anyway, whenever you feel fairly good about it I can test flashing, as if I brick it it's not a total loss.

[steveo]

that's really nice of ya!

here's the latest beta version if you want to try it, im pretty sure it's safe now.

http://fbodytech.com/download/223/

to be extra helpful, please enable debugging and leave the debug window open when flashing. if something goes wrong, please copy/paste the entire log into a notepad document or something

anyone else that wants to try it is welcome..

[fbody_Brian]

Flash successful!

I did notice at the end of the debug log there is this:


REPLY MATCH OK: =F45706AA05 WRITE=F46204000000000000000000000000A6
Write buffer too slow !
WRITE=F46204000000000000000000000000A6
Write buffer too slow !
WRITE=F46204000000000000000000000000A6
Write buffer too slow !
WRITE=F46204000000000000000000000000A6
Write buffer too slow !
WRITE=F45609AD
Write buffer too slow !


I don't know if that is expected or not, but it flashed properly anyway.
I did the whole bin, both sides. have not tested flashing a single side.

[steveo]

Flash successful!

awesome! i really appreciate you taking a chance on it.



I did notice at the end of the debug log there is this:


REPLY MATCH OK: =F45706AA05 WRITE=F46204000000000000000000000000A6
Write buffer too slow !
WRITE=F46204000000000000000000000000A6
Write buffer too slow !
WRITE=F46204000000000000000000000000A6
Write buffer too slow !
WRITE=F46204000000000000000000000000A6
Write buffer too slow !
WRITE=F45609AD
Write buffer too slow !


I don't know if that is expected or not, but it flashed properly anyway.
I did the whole bin, both sides. have not tested flashing a single side.
[/quote]

that's sort of expected. those are messages intended for normal 'disconnection' that cancel any mode4 effects (and make damn sure they're cancelled), and resume normal comms. in this case, they don't work, which is no big deal.

thanks again for testing! it's great news. my test ECM is bricked right now (until my chinese sockets n chips arrive), and i only have one car, so i'm unable to do any testing myself.

[fbody_Brian]

I was hoping I wouldn't be out there in the driveway in the dark swapping out my ecm. lol
It's my only car and I have to work in the morning.

I really like the progress meters and that it shows each side and you have an idea what's happening. It's definitely already better than what else is available. How confident are you about just flashing one side, using the previous bin?
I'm usually making just small changes, so it would be a welcome change.

[steveo]

I really like the progress meters and that it shows each side and you have an idea what's happening.

thanks, that's exactly what i was going for... i'm not hiding anything about the operation, and it's open source, so the entire flashing routine is publicly exposed.

along those lines, i've found the 'erase' procedure to be a bit 'scary looking' since it just kinda freezes while erasing, im going to improve that so you see some activity and know that it's still trying to erase. (the program actually does get status updates during that time)


How confident are you about just flashing one side, using the previous bin?

it should work fine, in fact since it only erases one side, it should carry half the risk (and take half as much time).

that's why i made the compare feature, if you use it properly makes such operations safe if you don't quite know what you've changed and what side that code is on. i have a fairly good understanding of how the flash procedure works now, and what it does, and i can't forsee any problems.

of course the compare feature itself is only lightly tested at this point, as is flashing, so again, use at your own risk.

i can't wait till i get sockets, im going to test the hell out of it in every possible condition.

[fbody_Brian]

Changed a small bit in my bin file, loaded write bin and prev bin, it showed just e-side checked. I clicked upload bin file to ecm. It then proceeded to erase and write t-side, followed by the e-side. And it may be just in my head, but I swear that the fans didn't cut on at the beginning. I was sure that it was going to be ecm swap time. It finished successfully though.

[steveo]

i just realized the beta i posted has force enable of both sides, so im not suprised that happened..

here's the latest

http://fbodytech.com/download/223/

[fbody_Brian]

well, just writing e-side failed...

[steveo]

damn what happened? did you get a log?

[fbody_Brian]

it sat there saying erasing forever, I thought it was going to fail. Then it said writing e-side, then it popped up a message saying that the write failed and that my ecm was probably toast. lol


WRITE=F45608AE
WRITE=F45608AE
WRITE=F45608AE
WRITE=F45608AE
READ =F456
READ =08AE
WRITE=F4570100B4
READ =F492
READ =0100000000000000003C2F00000040004000FFFF00FF02560 8446A21FD1C0075FE666600000080808080000000000000008 72000000000D0000000000093
WRITE=F4570100B4
READ =F492
READ =0100000000000000003C2F00000040004000FFFF00FF02560 7436A20FD1C0076FE666601000080808080000000000000008 72000000000EE000000000076
WRITE=F4570100B4
READ =F492
READ =0100000000000000003C2F00000040004000FFFF00FF02560 6446A20FD1C0075FE666600000080808080000000000000008 72000000000EC00000000007A
WRITE=F4570100B4
READ =F492
READ =0100000000000000003C2F00000040004000FFFF00FF02560 6436E21FD1C0075FE666600000080808080000000000000008 72000000000EC000000000076
WRITE=F4570100B4
READ =F492
READ =0100000000000000003C2F00000040004000FFFF00FF02560 5436E20FC1C0076FE666501000080808080000000000000008 72000000000D500000000008F
WRITE=F4570100B4
READ =F492
READ =0100000000000000003C2F00000040004000FFFF00FF02560 5446A21FD1C0075FE666500000080808080000000000000008 72000000000E3000000000084
WRITE=F4570100B4
READ =F492
READ =0100000000000000003C2F00000040004000FFFF00FF02560 5446A21FD1C0075FE666500000080808080000000000000008 72000000000D4000000000093
WRITE=F4570100B4
READ =F492
READ =0100000000000000003C2F00000040004000FFFF00FF02560 4446B21FC1C0075FE676500000080808080000000000000008 72000000000D4000000000093
WRITE=F4570100B4
READ =F492
READ =0100000000000000003C2F00000040004000FFFF00FF02560 4466E20FD1C0075FE666501000080808080000000000000008 72000000000D0000000000092
WRITE=F4570100B4
READ =F492
READ =0100000000000000003C2F00000040004000FFFF00FF02560 6436A21FD1C0078FE676600000080808080000000000000008 72000000000CF000000000093
WRITE=F4570100B4
READ =F492
READ =0100000000000000003C2F00000040004000FFFF00FF02560 7446B21FD1C0077FE666600000080808080000000000000008 72000000000CF000000000092
WRITE=F4570100B4
READ =F492
READ =0100000000000000003C2F00000040004000FFFF00FF02560 6446B20FD1C0077FE676500000080808080000000000000008 72000000000CC000000000097
WRITE=F4570D01A7
READ =F459
READ =0D0150EF66
WRITE=F4590D02AF10E5
READ =F458
READ =0D02AAFB
Successful unlock routine!
WRITE=F45605B1
READ =F457
READ =05AA06
WRITE=E4570D01B7
READ =E459
READ =0D0150EF76
WRITE=E4590D02AF10F5
READ =E458
READ =0D02AA0B
Successful unlock routine!
WRITE=E45605C1
READ =E457
READ =05AA16
Sending MEMORY CONTROL LOOP to t-side:
WRITE=F4FF06014686AA3618308606C601FEFFBCAD0032392E 178B558D2918A6008D2418085A26F6962E408D1A1F2E40FCB6 180384BFB7180337C60B5A26FD331D2D0818383239BD01931F 2E80F9A72F9B2E972E3937C655F7103A53F7103AC650F71806 C6A0F7180633393CCE10021D000838393CCE10021C00083839 36200336860A374D270BC64BBD01935A26FA4A26F533323937 FC100EFD1016337F10222007B61023848027058680B7102339 6A
READ =F457
READ =06AA05
WRITE=F4FF0600AF86AA3618308606C601FEFFBCAD0032392E 810626D98D3A972C7A00318D33972D7A003118DE2C8D2918A7 0018087A003126F48D1D5D26B718DE2C18AD0020AF8D103C30 CC05AAED00C602BD012C387E009D183C18CE05757F002F7A00 2F260418092707BD01931F2E0E0538387E009D1F2E20E7A62F 16DB2ED72E18383936183C3C1838CE10008608A72D37C60B5A 26FD33B618038A40B71803B618028A40B718024F972E86F48D 4B
READ =F457
READ =06AA05
WRITE=F4FF06001886AA3618308606C601FEFFBCAD003239E0 7E01D300000000000000000000000000000000000000000000 0000000000000000008E004A0FB618018A80B71801B6180084 7FB71800B6180384BFB71803B610098A01B71009B6100884FD B71008B610038A08B71003BD01A93C3013320107CC0601ED00 2008143201CC06AAED00C602BD012C38CE10008604A72DEC2E 4F972E1C2D028D5281F426EB8D4C805625E597318D44810527 AD
READ =F457
READ =06AA05
WRITE=F4800600002049204700000000000000000000000020 00FFFF7E012C7E01937E01A97E01B27E01BB7E01BE7E018C
READ =F457
READ =06AA05
Sending MEMORY CONTROL LOOP to e-side:
WRITE=E4FF06013E86AA3618308606C601FEFFBCAD0032392E 178B558D2918A6008D2418085A26F6962E408D1A1F2E40FCB6 180384FBB7180337C60B5A26FD331D2D0818383239BD018B1F 2E80F9A72F9B2E972E3937C655F7103A53F7103AC650F71806 C6A0F7180633393CCE10021D000838393CCE10021C00083839 36200336860A374D270BC64BBD018B5A26FA4A26F533323937 FC100EFD1016337F10222007B61023848027058680B7102339 56
READ =E457
READ =06AA15
WRITE=E4FF0600A786AA3618308606C601FEFFBCAD0032392E 810626D98D3A972C7A00318D33972D7A003118DE2C8D2918A7 0018087A003126F48D1D5D26B718DE2C18AD0020AF8D103C30 CC05AAED00C602BD0124387E0095183C18CE05757F002F7A00 2F260418092707BD018B1F2E0E0538387E00951F2E20E7A62F 16DB2ED72E18383936183C3C1838CE10008608A72D37C60B5A 26FD33B618038A04B71803B618028A04B718024F972E86E48D 0B
READ =E457
READ =06AA15
WRITE=E4FF06001086AA3618308606C601FEFFBCAD0032397E 01B37E01B67E01D87E01CB0000000000000000000000000000 000000000FB6180284FCB71802864997018E004A0FB618018A 7FB71801B6180384FBB71803B610098A01B71009B6100884FD B71008B610038A08B71003BD01A13C3013320107CC0601ED00 2008143201CC06AAED00C602BD012438CE10008604A72DEC2E 4F972E1C2D028D5281E426EB8D4C805625E597318D44810527 DD
READ =E457
READ =06AA15
WRITE=E478060000203C204700000000000000000000000020 00FFFF7E01247E018B7E01A17E01AAC7
READ =E457
READ =06AA15
WRITE=E47F0602009D1D86AAB755558655B7AAAA8690B75555 9D1A3C3C30FC2000ED02CC06AAED00C6049D14383839F6
READ =E459
READ =06AA000013
WRITE=E4D80602493C30CC06AAED00C6029D143839CC06AA20 03CC06073C30ED00C6029D14389D1A3936373C3C30CC0655ED 00C6029D1438383332399D294FB702C8DE1208094F369D2632 270F7C02C8F602C8C10525058DD07F02C89D1DC640E700C600 E7009D17C6C0E7009D1AE60027074C811923E520099C1026C8 CC00002003CC06063900003E
READ =E457
READ =06AA15
WRITE=E4AE060200BD027D1A83000027037E025E4FB702C7DE 109D1DC620E700E7009D230908C6A0E7009D179D1A369D2632 270F7C02C8F602C8C10525058D327F02C8C6FFE100270F4C26 CE7C02C7F602C7C10C23C4200B9D1D9C1226C71E
READ =E457
READ =0606B9
WAITED_TOO_LONG in serial_read_packet: Bytes =0
WAITED_TOO_LONG in serial_read_packet: Bytes =0
WAITED_TOO_LONG in serial_read_packet: Bytes =0
WAITED_TOO_LONG in serial_read_packet: Bytes =0
WAITED_TOO_LONG in serial_read_packet: Bytes =0
WAITED_TOO_LONG in serial_read_packet: Bytes =0
WAITED_TOO_LONG in serial_read_packet: Bytes =0
WAITED_TOO_LONG in serial_read_packet: Bytes =0
WAITED_TOO_LONG in serial_read_packet: Bytes =0
WRITE=F46204000000000000000000000000A6
WRITE=F46204000000000000000000000000A6
WRITE=F45609AD

[fbody_Brian]

Do you have part numbers for the chips and sockets?

[kur4o]

You will need sockets only of the following type PLLC32 smt(surfice mount)
Flash chips will be reuseable. In the rare case of chip failure PN is an28f512 -120
Also you will need some programmer and raw rom image of the chips.

[fbody_Brian]

You will need sockets only of the following type PLLC32 smt(surfice mount)
Flash chips will be reuseable. In the rare case of chip failure PN is an28f512 -120
Also you will need some programmer and raw rom image of the chips.
I ordered some sockets. I have the equipment to do the chip removal and solder the socket on. I'll need to get a chip programmer. I have one for pic micro-controllers, but don't think that will work.
Where or how do I get a basic raw rom image, something just to get it talking?

[steveo]

it sat there saying erasing forever, I thought it was going to fail. Then it said writing e-side, then it popped up a message saying that the write failed and that my ecm was probably toast. lol



...
WRITE=E4AE060200BD027D1A83000027037E025E4FB702C7DE 109D1DC620E700E7009D230908C6A0E7009D179D1A369D2632 270F7C02C8F602C8C10525058D327F02C8C6FFE100270F4C26 CE7C02C7F602C7C10C23C4200B9D1D9C1226C71E
READ =E457
READ =0606B9
WAITED_TOO_LONG in serial_read_packet: Bytes =0
WAITED_TOO_LONG in serial_read_packet: Bytes =0
WAITED_TOO_LONG in serial_read_packet: Bytes =0


so what happened is the second part of the erase program was uploaded. usually it would respond with a message 0x55 for each stage of the erase procedure, and 0xAA when complete. i've never seen a message 0x06 response, but the checksum is correct, so it's a legit message.. i'll have to do some disassembly and try to figure out what makes that occur.

this might be the program bitching about starting the erase procedure, but that means your ECM should still be in a useable state? so it's more likely it started trying to erase and something went horribly wrong

[fbody_Brian]

so what happened is the second part of the erase program was uploaded. usually it would respond with a message 0x55 for each stage of the erase procedure, and 0xAA when complete. i've never seen a message 0x06 response, but the checksum is correct, so it's a legit message.. i'll have to do some disassembly and try to figure out what makes that occur.

this might be the program bitching about starting the erase procedure, but that means your ECM should still be in a useable state? so it's more likely it started trying to erase and something went horribly wrong
The car wouldn't start, just turn over. I also couldn't get the program to connect any more.
The fans didn't come on, which I understand happens when you brick the ecm. I didn't try resetting it by removing power or pulling the fuse. I didn't have the time though, I just swapped out my spare so the car would run.

[steveo]

I didn't try resetting it by removing power or pulling the fuse. I didn't have the time though, I just swapped out my spare so the car would run.

it never reached a point where it tried to "reset" and resume the normal program, the only way to do that manually is to pull the pcm bat fuse for a bit. see until you run reset code, even turning the key on and off it'll always execute the program stored in ram; that is until you clear the ram by cutting power for a bit.

can you try for me when you have a chance, just pop it back in there and see if it works? my hunch is that the ecm is still alive, and whether it is or not will tell me a bit about what that message means...

[steveo]

i think i need to do a bit of an 'expect the unexpected' logic update for this thing

an unexpected response there should have at least tried to figure out if it had returned to mode5 and restarted the current operation

in this case it looped infinitely waiting for 0x55 or 0xAA responses, since they were the only ones i was aware of in this context, which was super dumb. if it was a failed flash, it could have tried again. i feel its always best to try again rather than leave a bricked ecm.

[fbody_Brian]

it never reached a point where it tried to "reset" and resume the normal program, the only way to do that manually is to pull the pcm bat fuse for a bit. see until you run reset code, even turning the key on and off it'll always execute the program stored in ram; that is until you clear the ram by cutting power for a bit.

can you try for me when you have a chance, just pop it back in there and see if it works? my hunch is that the ecm is still alive, and whether it is or not will tell me a bit about what that message means...
I will check it when I can. Probably will be tomorrow.

[steveo]

Thanks again for your help. If it hadnt actually started writing yet it may be a response that means failed to execute or something, perhaps timing is too tight. I should put the delay times in the log too.

[fbody_Brian]

I put spare pcm back in and it fired right up, so you were correct, it is still alive.

[steveo]

ok awesome

what i need is a warning for the user if the reset routine is unsuccessful, to tell them that they'll have to disconnect power from the ecm to reset it manually.

i also think that error may be from a timing issue; i will loosen up timing in that area a bit; brian out of curiousity what operating system are you using on the laptop that you're testing with?

[steveo]

try this new version (8th beta) with relaxed timing see how it goes!

still can't wait till my sockets get here.

http://fbodytech.com/download/223/

[fbody_Brian]

i also think that error may be from a timing issue; i will loosen up timing in that area a bit; brian out of curiousity what operating system are you using on the laptop that you're testing with?
Windows 7. I never got it to work under nix.
Another thing of note. I realized today that my wideband is drawing current when the ignition is on. I can see it causing the volt meter to fluctuate. From now on I'm going to disconnect it when flashing.
Really need to set up that bench.

[fbody_Brian]

try this new version (8th beta) with relaxed timing see how it goes!

still can't wait till my sockets get here.

http://fbodytech.com/download/223/

I'll give it a try tomorrow. I'll get you the log.
Thanks again for all the work you're putting in.

[steveo]

thanks for all the testing. until my test ecm is back up, development is at a grinding halt without your (somewhat risky) testing.

[fbody_Brian]

Tried again

Seemed like it was just stuck in a loop. I ended up just turning the key off. I Pulled the pcm fuse to reset and the car runs. It appears to be having an issue erasing.

[steveo]

ok that's a very helpful test; I'll review it when I get home. thanks again!

[kur4o]

It looks like there is no vpp voltage. I am not sure which processor turns the switch on but i think it is at 1800 $80.

[steveo]

same problem as before: the ecm responds with message 0x06.

i need to dissect that flash erase routine and determine its error states. it's proving difficult since there seems to be function callouts to the 'development routine' at 0x0000 as well, and i haven't fully dissected that either.

and yes it got stuck in a loop, sorry about that, i inserted a catch for 0x06 as an error state where it just tries again when it detects it, just in case it happened to be a 'tried erasing but failed' state where re-erasing was the only option to possibly not have a bricked ecm. obviously this isn't the case. it'll behave better when i figure out what it's doing.

so, this only has happened when we've tried to flash e-side alone. i've never seen the response when t-side is erased first.

i was under the impression that once the development routine at 0x0000 was loaded, the spi link was inactive, but perhaps some intercommunication is still required, or perhaps VPP voltage is passed through a hard wire to both sides from the t-side, and the t-side routine turns on vpp to both sides? or what the hell?

the flash erase routine is nearly identical between the two sides, so i'm still trying to wrap my head around how this could be.

more study required. for now i must consider 'e-side only' flashes to be a broken feature and even t-side only flashes to be potentially risky. i would like more tests that flash both sides in order, though.

the last thing on my mind, i wonder if i can find a correlation between these mode6 messages (0x06=novpp, 0x55=erasing in progress 0xaa=erase complete) and the ascii strings stored in the bin itself. you'd figure they'd be mapped so the programmer gets the response byte and just displays the appropriate string. im still unsure why they are stored in the bin rather than the tech tool cartridge rom too? understanding this would be excellent since i could understand error states i have not yet encountered during testing.

lots to ponder.

thanks again for your time and risking your 30 buck ecm on our behalf, brian

[kur4o]

vpp is hardwire shorted between 2 chips and when it`s turn on, it` on for both chips.

You might try tside only to see if the problem persist.

[steveo]

vpp is hardwire shorted between 2 chips and when it`s turn on, it` on for both chips.

i was kind of afraid of that.

first this does mean that the other side, even if you don't want to program it, has vpp applied to it for the entire programming duration. i don't think that has any negative effects, but im unsure at this point, it definitely does decrease the safety margin a tiny bit?

so the question for the day is, does sending high vpp to an eeprom of this type for a few minutes have any negative effects, if you don't write anything to it during that time?

it's very possible (and now seems likely) that the t-side supplies vpp for both sides. since vpp must be applied during erase, i can only assume that the t-side erase code is when VPP is turned on; so to program e-side only will require hacking the erase routine for t-side to remove the part that actually erases it.

i'll do more research

it also might be possible that single-sided flash is more trouble than it's worth

[kur4o]

vpp is the voltage that erase and program chip. It must be above 6.5v for any of this to happen.
If it is applied and not used, It is not harmful because software execute the process.

Also I measured vpp during read cycle and it is also applied, even it is not needed. My eeprom programmer only applies during erase and write.

[fbody_Brian]

i was kind of afraid of that.

so the question for the day is, does sending high vpp to an eeprom of this type for a few minutes have any negative effects, if you don't write anything to it during that time?


I don't think so,
From the data sheet:
Or, the system designer may choose to ‘‘hardwire’’ VPP , making the high voltage supply constantly available. In this case, all Command Register functions are inhibited whenever VCC is below the write lockout voltage VLK0
The 28F512 is designed to accommodate either design practice, and to encourage optimization of the processor-memory interface

[steveo]

From the data sheet:
Or, the system designer may choose to ‘‘hardwire’’ VPP , making the high voltage supply constantly available. In this case, all Command Register functions are inhibited whenever VCC is below the write lockout voltage VLK0

ok, i assumed as much. that's good news.


Also I measured vpp during read cycle and it is also applied

that's actually really helpful since it narrows down where the code is that applies the voltage. i assumed it would just be part of the erase code that toggles it.

with that in mind, there's something that's run on t-side that isn't run on e-side

it used to be run during a read operation, but i tried removing it and it still read successfully, so i left it out in the latest beta versions.

have you tried the latest beta of eehack to see if read still applies VPP voltage? my hunch is that it doesn't anymore, due to lack of this routine, executed at offset 0x0200 on t-side:


b6 10 02 84 f8 b7 10 02 86 07 b7 10 30 05 3d 3d 3d b6 10 31 81 66 25 04 81 a1 23 05 cc 06 02 20 3e b6 18 00 8a 80 b7 18 00 9d 17 9d 23 9d 17 9d 23 b6 10 02 84 f8 8a 05 b7 10 02 86 07 b7 10 30 05 3d 3d 3d b6 10 31 81 bc 25 04 81 e9 23 0d b6 18 00 84 7f b7 18 00 cc 06 03 20 03 cc 06 aa 3c 30 ed 00 c6 02 9d 14 38 39

i just checked and it's not run during an e-side flash, that might be my bug!

i just thought of one other thing. what turns VPP off after, is a reset procedure at the end (i'll try and find that too). if you lose flow control and the main loader loop at 0x0000 stops executing, you can't run the reset routine and turn VPP off. this creates an operating state where vpp is permanently on until ecm reset, but the ecm is locked up so should be safe.

attached is the last beta; can someone check for VPP during READ in this version?

[kur4o]

I am almost sure this turns vpp

ldaa 1800
bset $80

At reset or
ldaa 1800
bclr $80

is cleared.

Address 1800 is processor relay control
bit $80 is internally wired on board with vpp voltage.
Not sure which processor turns it on, or both can.

[steveo]

i'm glad you understand the hardware end of this board. that does look viable

i can't get ida working for these segments due to offsets, disassemblers hate me, so here's my hand disassembly:



b6 18 00 : LDAA 0x1800 ; A=0x1800
8a 80 : ORAA $0x80 ; A=A~$0X80 (set bit 0x80 of 0x1800 on)
b7 18 00 : STAA 0x1800 ; 0x1800=A
9d 17 : JSR 0x17 ; execute subroutine 23 bytes ahead, SUB:A


here's a good one for you kur4o, what are the hardware bits for the fans or CCP solenoid? i'd love to find where the diagnostic routine at 0x0000 actuates them, i find the constant CCP clicking and fan noise to be annoying when flashing.

[steveo]

i think i found the vpp disable routine too:



b6 18 00 : LDAA 0x1800 (should be 10000000)
84 7f : ANDA $0x7F (0x7f is 01111111, so only disables our VPP bit)
b7 18 00 : STAA 0x1800

[steveo]

anyone care to try my latest attempt?

http://fbodytech.com/download/223/

i hope this is it.

i added a bit more verbose error handling to a lot of the routines too (hope I didn't break anything in the process....)

[steveo]

did a bit more work, i reviewed kur4o's logs where it failed to upload the programming routine "sometimes", and decided to try something different that might help. now it loads the mode 5 loop immediately before uploading the development routine at 0x0000 so there's no delay, before it placed both ecms into mode 5 at the same time, which, on a slow computer, has the opportunity to time out the mode5 loop. i dont know why i wrote it like that in the first place.

flash read is now a bit...behind...but i think it's less important, nobody uses flash read during actual tuning sessions, it's more of a novelty.

also spent some time rewriting the progress log so it displays more useful errors and less verbosity in areas where not required.

i covered a bunch of edge cases in responses and recovery to try to ensure nothing goes crazy if an unexpected reply happens too.

finally you can now cancel a flash operation during initialization and it'll bail at the appropriate time, so you have time to change your mind.

i fixed the bin compare feature too, it was a bit buggy, single-sided flash should be good to go now.

i'm hoping this is a stable flash write program now, but lets test 'er out! still hesitant to officially release as stable until my sockets arrive and I can stress test, though.

http://fbodytech.com/download/223/

[kur4o]

I did multiple single side test and full flash and couldn`t make it fail.
I did have some connection problems on cold boot with no connection made(open the program and go straight to flash.).


I couldn`t make it read the bin also.

Here are some logs.

[steveo]

awesome!

i think i broke read support (since they share lots of functions and i wasn't paying attention). i'll fix it.

write is the priority, since read was already working before.


I did have some connection problems on cold boot with no connection made(open the program and go straight to flash.).

i wonder why? i'll keep working on that. whether it's connected or not, it always does a bunch of mode 1 requests, so the connection should be in the same state when it starts. i do my own checks for voltage, rpm, etc, which are redundant, but it's mostly an excuse to check for bad checksums so i can go 'hey, your connection is no good, we aren't flashing anything today...'

[steveo]

that zip is invalid

[jthompson122183]

Anyway of rewriting the bootloader to run at 10.1 volts instead of 12.1? Most lead cell batterys that I've seen hover around 12.5 resting voltage. By the time the fans and ccp get done doing what there doing that voltage drops. Just a possible idea?

[fbody_Brian]

Tested single e-side write and it worked!
Read was also broken for me. After an attempted read I had to reset the pcm or the car wouldn't start.

I'd get you the logs, but I couldn't seem to find the debug window or the option.


Ensuring that conditions are ideal for programming...
Testing connection stability...
Stability OK!
Executing Flash Read Routine!
F4 Disabling security...
F4 Entering programming mode...
E4 Disabling security...
E4 Entering programming mode...
Uploading T-Side Development Routine...
Uploading E-Side Development Routine...
Uploading E-Side Read Routine..
Uploading T-Side Read Routine..
Reading flash memory...
It's safe to cancel this operation if you'd like!
<-- See Progress
Can't read ECM data, giving up!
*************************
Unfortunately, the development routine is now stuck in ram :(
This means you need to disconnect power from your ecm for a bit
to reset it before it'll function normally; pulling the PCM BAT
fuse would do the trick!!
*************************
Press CANCEL to exit. Will disconnect automatically.

[RobertISaar]

with the LT1 PCM, the fans turn on during a flash? with the P66 V6 PCM and using the madtuner software, the fan(s) turn on after a flash.

[fbody_Brian]

that zip is invalid


hmmm
i was able to open it

[fbody_Brian]

with the LT1 PCM, the fans turn on during a flash? with the P66 V6 PCM and using the madtuner software, the fan(s) turn on after a flash.


The fans kick on before the flash on the lt1.

[fbody_Brian]

well, I found the debug window option. I'll give it another shot with the log enabled.

[kur4o]

The archive is .rar, I had to rename it because of upload restrictions.

Fan switch is located at Eside 1802 $01 -fan 1; 1802 $02 -fan 2.
I don`t recommend flashing with lower voltage. To program the chip at analog level you need good solid 12v and a little higher.
Anyway the check is done when you enter loop 5 and it doesn`t matter when flash starts.

[steveo]

Anyway of rewriting the bootloader to run at 10.1 volts instead of 12.1? Most lead cell batterys that I've seen hover around 12.5 resting voltage. By the time the fans and ccp get done doing what there doing that voltage drops. Just a possible idea?

i will consider widing that threshold; but 10.1 volts at the pcm is WAY too low to be safely flashing, imo.

[steveo]

The archive is .rar, I had to rename it because of upload restrictions.

that explains it. i'll look into it when i get home.


Fan switch is located at Eside 1802 $01 -fan 1; 1802 $02 -fan 2.
I don`t recommend flashing with lower voltage. To program the chip at analog level you need good solid 12v and a little higher.
Anyway the check is done when you enter loop 5 and it doesn`t matter when flash starts.

thanks, it's patch time on that routine for sure! any idea on the canister purge solenoid? it cycles during the 0x0000 loop somewhere, i want to kill it too.


with the LT1 PCM, the fans turn on during a flash? with the P66 V6 PCM and using the madtuner software, the fan(s) turn on after a flash.

not during, it seems it happens when first loading that mode6 loader routine into ram, though... now that i have some addresses i'll look into it more.

[steveo]

i think i know exactly why read is failing, guys.... i can fix that with a one-liner when i get home. just a stupid oversight as usual.

... very bad programming practice to make major api changes like that

[steveo]

any more testing of write would be greatly appreciated, im still waiting for my chinese sockets to arrive. im so happy the battle for a free LT1 flash tool is close to an end.

[steveo]

kur4o, when the initialization fails for you:

the ecm sends 0x0000 as a key challenge. my experiments showed that only happened when the ECM was already 'unlocked', so my program stops trying to unlock it. and when it tries to program the t-side, no problems.. seems unlocked.

then when it tries to program the e-side, entering mode 0x05 responds with 0xAA message, meaning success, right?

but then it replies to a mode 0x06 request with mode 0x05 message 0xAA again?

i can't figure out why it's doing that. do you have any ideas?

edit: can you try this version to see if you can make it fail? (read support should be working again too..)

[kur4o]

Well that may explain the problem. I have disabled mode 0d and now it is skipped. It can load mode 5 without seed key request.
Interesting that it is intermitten problem with my bin.

CCP is engaged with timer interupt routine and there is no address to disable so for now it`s not possible to switch off.

[steveo]

yeah, the flash routine definitely won't work if mode 13 isn't functioning as expected; but you should check your patch. it's responding to a mode 0x06 message with mode 0x05, which seems to be against aldl message protocols in general. something must be broken.

[lionelhutz]

Anyway of rewriting the bootloader to run at 10.1 volts instead of 12.1? Most lead cell batterys that I've seen hover around 12.5 resting voltage. By the time the fans and ccp get done doing what there doing that voltage drops. Just a possible idea?

It's a hardware limitation. The flash chip datasheet says 11.4V is the lowest programming voltage so the routine should not be re-written to use such a low voltage.

I wouldn't even modify it to use 12V or 11.5V. That level of voltage is indicating the battery is well below a full charge and you don't want to attempt flashing with the battery at a 60% to 40% state of charge.

[steveo]

my flash routine actually goes a step further and does its own checks first just in case:



if(eedata.get_volts() < 11.5 || eedata.get_volts() > 15) {
progress->append_error("ERROR: PCM VOLTAGE is out of range (too low or too high). Programming is unsafe.");
return false;
}


it's checked against a sample size of 8 packets.

[RobertISaar]

VPP is specified as 12 +/-5%... there might be a zener or something on the VPP circuit to clamp it at a maximum of 12.6 volts, but I couldn't confirm that.

[steveo]

i just did some flash testing on my own car,

i introduced a serial error on purpose (which is scary to do on your last working ecm...), and it failed, went into recovery mode, re-erased, and managed to flash successfully.

i'm about to consider this tool stable enough for release

[steveo]

released (also added wideband analyzer in non-pe mode!)

http://fbodytech.com/eehack-3-5-flash-write-wideband/

[fbody_Brian]

released (also added wideband analyzer in non-pe mode!) http://fbodytech.com/eehack-3-5-flash-write-wideband/ Sweet!

[fbody_Brian]

Been flashing, downloading, and logging. It appears pretty stable.
I have yet to do a t-side only flash. I'll probably test that this evening.
Awesome tool.

[fbody_Brian]

Been doing a lot of flashing and reading. E-side, T-side, complete bin.
No errors. It's been working great for me. Just wanted to let you know. I much prefer it to winflash. The feedback during flashing is nice.

Once again, thanks for the great work.

[steveo]

that's great news. i honestly haven't had time to test it more, and i reeaally don't want to brick my only vehicle.

the next version will probably flash a bit more quickly as i start to write a routine that maps out flash blocks in an optimal way instead of just iterating through them.

it's a bit tricky:

- there are 16 bytes of tx/rx overhead and a linear amount of time for each flash 'chunk' written
- the chunk size is variable
- we can skip anything that's 0xFF since the chip starts out being filled with 0xFF.

so obviously if your chunk starts with one or more 0xFF bytes, (the start of our chunk has coincidentally landed on it), in which case it's dumb NOT to advance the write offset until there's no more 0xFF bytes. same if the end of the chunk lands on a 0xFF, it's smarter to just shorten the length and not write them.

those two are basically free time saved and trivial to calculate but very rare to encounter.

finding longer strings of 0XFF in the middle of chunks is the really tricky part of the algorithm, since sending a chunk carries a relatively high price; you need to ensure your algorithm doesn't end up with small chunk sizes, or the routine will end up taking longer despite your efforts. if skipping a few 0xFF bytes saves two bytes it could cost us 16 bytes of extra overhead by splitting a chunk, which is bad. but if the algorithm is smart, it'll only works when it's reducing the size of serial comms.

this will only speed up writing by a few percent, but once this algorithm is optimized, we can 'speed patch' a bin, basically to be 0xFF in any unused region, which should greatly reduce the time needed to write it.. perhaps even by 40%+ on the e-side, which has HUGE unused sections.

[kur4o]

I just scored a dump from oem tool programming 8051 PCM.
You may find it interesting.

[steveo]

i'll have a look later today, thanks kur4o!