Bringing TBI and Multi Port Fuel Injection to a New Level.     EFI Conversions and Tuning! Seattle to Portland! E-mail Tuning Consultant!
Page 6 of 6 FirstFirst 123456
Results 76 to 87 of 87

Thread: OBD2 LT1 XDF $EE EEX creation

  1. #76
    Fuel Injected! steveo's Avatar
    Join Date
    Aug 2013
    Posts
    3,144
    i do agree and observed it crashes although it's nice to have a theory why

    in practice sending a 7E jump only incurs 3 extra bytes of overhead, so that's what i ended up doing in flashhack

    thanks for reminding me of this, as some of my code doesn't check for empty mode 6 data payloads, it'd be nice to trap that error if i ever make a mistake somewhere

  2. #77
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    928
    Mode 6 is always download and execute.

    In that case

    $F4 $57 $06 $00 $00 $AE is

    download at $0000 address zero bytes and execute at $0000 address.

    I suspect that aldl chip verifies checksum and never sends checksum byte to PCM` cpu and also truncates the message if the checksum doesn`t match. If you are sending this straight to cpu without using aldl chip as a buffer you actually write AE at addess $0000 and than execute it as code. So opcode $ae is a crash for cpu.

    IN bootstrap mode some form of checksum should be implemented in the message receive loop, in case it doesn`t match than skip the jsr to download address.

  3. #78
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    928
    I figured why it crashes.

    You need at least $58 message length to save the jump buffer. Otherwise the code enters loops expecting more bytes that are never send.

    It is also unavoidable to write at least one bytes of data before jumping. There isn`t any length specified to skip on zero length and the code assumes there is at least 1 byte to write.

    So the best way to execute only is to overwrite the first byte of the jump location.

    $F4 $58 $06 $00 $00 $XX $YY

  4. #79
    Fuel Injected! steveo's Avatar
    Join Date
    Aug 2013
    Posts
    3,144
    oh, yeah! that's a good point! in my case while running the kernel, i always know what that first byte of a routine or subroutine is since i uploaded all of them. i can easily abuse this to save 2 bytes of bandwidth in a lot of cases. i'll give it a shot tonight.

  5. #80
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    928
    Use with care on code that reduce stack for the return address. It might crash as well.

  6. #81
    Fuel Injected!
    Join Date
    Nov 2017
    Age
    53
    Posts
    245
    What, you no like pop? <<<<< code humor
    -Carl

  7. #82
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    184
    Found one other Hmmmm in the code, this one doesn't matter at all, just a point of interest...

    I am not sure what the point of mode 5 is. What ever you send, it just replies 'AA' and does nothing else. Probably just completes a sequence for the tester or ??
    Thing I found is, in the programming code, the checksum is never tested. It needs to be there but the value isn't tested. So:

    $F4 $56 $05 $55 works just as well as
    $F4 $56 $05 $B1 with correct checksum.

    OK, so I am now through the code and starting changes needed for functioning code under bootstrap. When you enter bootstrap, no chip selects are defined thus FLASH and PRU are not in the memory map. There is a pesky rom to remove from the memory map. I intend to up the baud rate to reduce time and need a workable way to make the change. Qs for you all: do you have a feel for what baud to use? Faster is better VS. reliable comms. I need to turn off the Tside ALDL driver (not connected right now but later...) and a few other house keeping things.

    Do you feel that these setup things are better done in a subroutine? This permits NOT messing with the '95 programming code but has a downside of making the procedure of baud rate change more cumbersome. My current thinking is to start bootstrap in low speed. This is because bootstrap starts the SCI up in wire_or_mode. I don't want to hang too much of a pull-up resistor off the port, so starting at 1889baud makes sense to me. Once the housekeeping routine is run the rate can be upped because port D can now be driven. Thoughts?

    One other consideration, since bootstrap has no chip-selects enabled, the internal ram is all that is available. It may be unavoidable to modify the standard code just because I need the space.

    -Tom

    Give all that, programming in the standard rate is slow in human terms. Speeding it 4X if possible makes it much better, perhaps I should aim at around 32-64Kbps??

    -Tom

  8. #83
    Fuel Injected! steveo's Avatar
    Join Date
    Aug 2013
    Posts
    3,144
    Quote Originally Posted by Tom H View Post
    I am not sure what the point of mode 5 is. What ever you send, it just replies 'AA' and does nothing else. Probably just completes a sequence for the tester or ??
    yeah, completing a sequence for the tester is pretty much why it's there. before sending any mode 6 requests, the tester is supposed to send a mode 5 request, and the ECM either replies 05 AA or with a 0D if mode 5 is locked out. having mode 5 reply just satisfies that requirement so someone uploading code doesn't have to worry about whether they're executing from rom or ram and follow the same procedure. in my software i've changed the AA response byte to that command to something else, so we can branch on the condition that the kernel is loaded or not loaded (so we don't try to load a kernel over itself, which is a crashy thing to do)

    Qs for you all: do you have a feel for what baud to use? Faster is better VS. reliable comms. I need to turn off the Tside ALDL driver (not connected right now but later...) and a few other house keeping things
    your end goal here is just for recovering bricked ECMs, right? nobody will mind waiting for that, so i wouldn't focus too much on how fast it is. even if you can get it near 9600 baud or something it will serve its purpose well

  9. #84
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    184
    Quote Originally Posted by steveo View Post
    your end goal here is just for recovering bricked ECMs, right? nobody will mind waiting for that, so i wouldn't focus too much on how fast it is. even if you can get it near 9600 baud or something it will serve its purpose well
    Right. So the options are:

    118, 236, 384, 473, 512, 768, 945, 1024, 1536, 1890, 2048, 3072, 3781, 4096, 6144, 7562 --> all slower than the 8192 GM selected. 1890 is the default bootstrap speed in my config. I need to change gears before unbrick runs.

    8192 --> Tried and true

    12288, 15124, 16384, 24576, 32768 --> a bit faster but still within reason

    49152, 65536, 98304, 196608 --> Much faster but I don't know if my PC and serial cable can keep up. Not planning to test.

    I will try 32,768 and fall back to 16384 if it isn't solid enough. I expect it is OK though because GM doesn't use wire-or mode.

    -Tom

  10. #85
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    928
    I vote for the slowest most reliable option for recovery. $400 bytes of ram is plenty enough. Anyway the original code is set to use 0-1ff as comm loop 300-on as buffer for write message and 200-2ff for code buffer. Each routine is sent on demand. You send erase routine at $200, it is executed and you got positive response, Than send write routine at $200 and overwrite the write buffer.

    That way you can make small chunks of code that are send on demand to save ram.

    The change of speed can be handled that way. You send some code that change the baud with some wait time after that, for the tool to switch speed.

  11. #86
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    184
    Hi,

    I need a little help understanding the various configurations GM turned out for LT1 SFI. My overall is to help with s/w that un-bricks modules. One of the things I need is to parse binary files and turn them into aldl messages. I would like to understand how you identify the code sets. There are a bunch of questions that pop up...

    The computer used for the car is
    16188051 1994/5 LT1 OBD1
    16181333 1994/5 LT1 OBD1.5
    16214399 1996 LT1 OBD2
    16242921 1997 LT1 OBD2

    Correct?

    I see the term $EE and $EEB used for the code. I also see BCC and other terms. Is this explained somwhere? What code are the later 96/7 given.

    Once found, I plan to write some small code to extract/separate the Eside and Tside binary, producing files broken up into ALDL messages to drive my bootstrap code.

    If all this is explained somewhere, please send me a link.

    -Tom

  12. #87
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    928
    All 94-95 files and pcms are interchangeable. On the average bin you want to parse, first part is tside and second part is eside. there is also ram 0-2000 area in the files. You can cut these and parse 2000-ffff as tside and 12000-1ffff as eside.

    96 and 97 files are slightly different but have common structure. Not quite sure if 96 bin will work on 97 pcm.

    All 96 files are interchangeable for 96 pcm and all 97 files are interchangeable for 97 pcm.

    96-97 files are 0-56 kb tside bank0. 56-88kb bank1 tside. 88-144kb eside.

Similar Threads

  1. XDF Creation / Editing - How To????
    By B52Bombardier1 in forum OBDII Tuning
    Replies: 5
    Last Post: 02-28-2020, 02:04 AM
  2. new to obd2
    By myburb in forum OBDII Tuning
    Replies: 0
    Last Post: 05-28-2018, 05:54 AM
  3. DHP/AVT-852-002 Rev L OBD2 programmer $250
    By SappySE107 in forum Buy - Sell - Trade - Wanted
    Replies: 2
    Last Post: 02-03-2018, 09:25 AM
  4. flashing OBD2 ECU?
    By vwnut8392 in forum OBDII Tuning
    Replies: 4
    Last Post: 11-25-2017, 01:43 AM
  5. WTB TunerCats II (OBD2)
    By XRelapse13 in forum Buy - Sell - Trade - Wanted
    Replies: 0
    Last Post: 12-16-2014, 08:26 PM

Tags for this Thread

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
  •