$EE Flash tool progress

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

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