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.
1995 Chevrolet Monte Carlo LS 3100 + 4T60E
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.
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.
you hit the nail on the head; i just wasn't seeing it.Originally Posted by RobertISaar
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.
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.the F1 does have some onboard EEPROM, exact address is code dependant, but I would expect to see it in the E00 range.
awesome! is the relay perhaps for erase?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.
im going to get the whole flash routine and start to disassemble it.
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.
1995 Chevrolet Monte Carlo LS 3100 + 4T60E
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.
1995 Chevrolet Monte Carlo LS 3100 + 4T60E
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:
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.Code:[addr] [length] 0x06 [low addr] [high addr] [data ...] [cksum]
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:
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.Code:86 aa 36 18 30 86 06 c6 01 fe ff bc ad 00 32 39
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:
e-side:Code: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
so how does it work? i haven't disassembled it yet, but i have confirmed the following...Code: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
another mode 6 request will write a payload to memory at 0x0300 (well past the range of the existing code):
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.Code:[addr] [len] 06 BD 02 1A [low_addr] [high_addr] [n_bytes] [payload ...] [cksum]
to read flash memory:
reply isCode:[addr] [len] 06 02 00 20 0B [low_addr] [high_addr] [cksum]
Code:[addr] [len] 06 AA ?? ?? [payload ...] ?? (CKSUM)
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 ; ---------------------------------------------------------------------------
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.
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.
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.
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.
could be. i think i'll just write a smart retry algorithm that'll eventually get the correct key.
yes please!I was trying to find fuel pump switch
Posting Permissions
Reply With Quote
Bookmarks