Bringing TBI and Multi Port Fuel Injection to a New Level.     EFI Conversions and Tuning! Seattle to Portland! E-mail Tuning Consultant!
Page 1 of 8 123456 ... LastLast
Results 1 to 15 of 113

Thread: $EE Flash tool progress

  1. #1
    Fuel Injected! steveo's Avatar
    Join Date
    Aug 2013
    Posts
    2,354

    $EE Flash tool progress

    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:

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

    Code:
    (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!

    Code:
    .. .. .. 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):
    Code:
    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......

  2. #2
    Fuel Injected! steveo's Avatar
    Join Date
    Aug 2013
    Posts
    2,354
    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.

  3. #3
    Fuel Injected! steveo's Avatar
    Join Date
    Aug 2013
    Posts
    2,354
    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)

  4. #4
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    409
    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

  5. #5
    Fuel Injected! steveo's Avatar
    Join Date
    Aug 2013
    Posts
    2,354
    Quote Originally Posted by kur4o View Post
    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.

    Code:
    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,:

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

  6. #6
    Fuel Injected! steveo's Avatar
    Join Date
    Aug 2013
    Posts
    2,354
    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=

  7. #7
    Super Moderator
    Join Date
    Mar 2011
    Location
    Camden, MI
    Age
    29
    Posts
    3,026
    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


  8. #8
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    409
    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.

  9. #9
    Fuel Injected! steveo's Avatar
    Join Date
    Aug 2013
    Posts
    2,354
    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.

  10. #10
    Fuel Injected! steveo's Avatar
    Join Date
    Aug 2013
    Posts
    2,354
    Quote Originally Posted by RobertISaar View Post
    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.

  11. #11
    Super Moderator
    Join Date
    Mar 2011
    Location
    Camden, MI
    Age
    29
    Posts
    3,026
    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


  12. #12
    Super Moderator
    Join Date
    Mar 2011
    Location
    Camden, MI
    Age
    29
    Posts
    3,026
    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


  13. #13
    Fuel Injected! steveo's Avatar
    Join Date
    Aug 2013
    Posts
    2,354
    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:

    Code:
    [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:

    Code:
    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:

    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
    e-side:

    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
    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):

    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:

    Code:
    [addr] [len] 06 02 00 20 0B [low_addr] [high_addr] [cksum]
    reply is

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

  14. #14
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    409
    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 ; ---------------------------------------------------------------------------

  15. #15
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    409
    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.

Similar Threads

  1. LS1 Flash Tool Released
    By antus in forum OBDII Tuning
    Replies: 113
    Last Post: 02-05-2016, 10:38 AM
  2. Group Buy for LS1 Flash Tool AVT 852 cable!
    By EagleMark in forum OBDII Tuning
    Replies: 73
    Last Post: 03-02-2014, 01:11 PM
  3. Replies: 8
    Last Post: 02-11-2014, 08:25 PM
  4. Open source GM OBD2 flash tool using a ELM327 device
    By EagleMark in forum OBDII Tuning
    Replies: 1
    Last Post: 06-21-2013, 04:00 PM
  5. Memcal Flash Tool
    By EagleMark in forum GM EFI Systems
    Replies: 6
    Last Post: 01-21-2013, 07:26 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •