$EE Flash tool progress

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