Page 4 of 22 FirstFirst 12345678914 ... LastLast
Results 46 to 60 of 321

Thread: Flashhack - New LT1 flash tool

  1. #46
    Carb and Points!
    Join Date
    Apr 2020
    Age
    47
    Posts
    5
    Well received my cable today and read ecm with no problems using flashback .4.1 also made changes in tunerpro then wrote revised bin back to ecm and only error had during either was while writing had latency between boot up of t and e sides

  2. #47
    Carb and Points!
    Join Date
    Apr 2020
    Age
    47
    Posts
    5
    Also had some difficulty lowering the latency in com port settings. If I lowered to 1 when I would plug cable in I could not control my pointer until unplugged cable. Changed to 10 and had no more problems.

  3. #48
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    i've never seen that before. you might have some weird driver issue but i'm glad it worked for you. you might not have to lower your com port latency with the new connection routine, it works fine at 16ms for me.

  4. #49
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    757
    Testing 0.4.2, something different happens this time. It still can't connect to the PCM to load the kernel or download the BIN, but unlike previous attempts it's actually making changes to the car. My digital dash freaks out, the SERVICE ASR light comes on, and the auto climate control goes into error mode. SERVICE ABS does not illuminate. It's odd though, I don't recall WinFlash or EEHack causing the digital dash to freak out like that. Maybe I just didn't notice...but I think I would've noticed something like that.

    Anyway, as always, logs attached. First log is running as normal, second log is with "alternative ALDL connection routine" checked. The only difference appeared to be that one process was faster to error out than the other.
    Attached Files Attached Files
    1990 Corvette (Manual)
    1994 Corvette (Automatic)
    1995 Corvette (Manual)

  5. #50
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    im suprised as im pretty sure its the same method that winflash uses to connect. any research on your end with serial sniffing or whatever would be appreciated as i have no time to spend on this anymore. i am 20+ hours into this one part of the project. it works 100% perfectly on my bench as usual

    that alternate connection setting no longer works

    are you sure if you keep trying that eventually it wont connect? it should fluke out eventually.

  6. #51
    Fuel Injected!
    Join Date
    Sep 2012
    Location
    Huntsville, AL
    Posts
    237
    Testing B.0.4.2 worked fine on my bench, no errors. Emailed you a log. Take a break!

  7. #52
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    cleaned up some of the mess in the source code from playing with this bus master stuff (also forgot to upload the source code in the last release)

    i exposed a configuration interface if anyone wants to experiment further with the bus master routine to try to make it work better (without having to read the source code) see the settings menu

    http://fbodytech.com/flashhack/

  8. #53
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    for anyone playing with that timing, here's how it works.

    it checks if the bus has been quiet for "silence success" milliseconds.

    if not, it sends a 'burst' of requests to become the bus master. 'burst length' is the number of requests in a burst, it can be 1.

    the requests are spaced out in a burst at somewhat even intervals called the 'burst gap' (can be zero) and then spread incrementally further apart across the length of the packet by 'burst spread' (also can be zero).

    then any crap in the bus is purged for a maximum of 'purge time' and the bus is rechecked for up to 'silence success' length and repeated.

    this happens until "timeout" has been reached

    have fun

  9. #54
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    757
    At last, success!

    On my '95, Flashhack 0.4.3 just plain works. First try, hit the button, off to the races with zero hiccups.

    On my '94, it failed to connect the first try, then succeeded on the second try. Made it through the entire write process then failed the final checksum and rebooted the PCM. Tried a third time, same thing happened--connected, completed the read process, then failed the checksum.

    I've attached all three logs to this post. Hopefully this gives us a new angle to work from.

    Woohoo!
    Attached Files Attached Files
    1990 Corvette (Manual)
    1994 Corvette (Automatic)
    1995 Corvette (Manual)

  10. #55
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    that's really good to hear. what happens if you use the 95 pcm in your 94? are you sure the 94 doesn't actually have an invalid checksum?

  11. #56
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    757
    Putting the 95 PCM into the 94 PCM was something I did forever ago when we were first investigating EEHack's connection issues--the connection issues remained with the car. As I don't have an oscilloscope I can't tell if it's EMI on the data line or actual data on the data line causing the problem. I do see that the Service ABS does not illuminate on either car, though, and the 94 and 95 have different ABS units which may have different bus communication. That being said, WinFlash still has to hammer the '94 to get it to go through, so that could be a red herring. I really should get a scope, it'd come in real handy right about now...

    By the 94 actually having a bad checksum, do you mean that the program currently running on the PCM has an invalid checksum in and of itself? Is there a way other than flashing a new program to it to be sure of that?
    1990 Corvette (Manual)
    1994 Corvette (Automatic)
    1995 Corvette (Manual)

  12. #57
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    By the 94 actually having a bad checksum, do you mean that the program currently running on the PCM has an invalid checksum in and of itself? Is there a way other than flashing a new program to it to be sure of that?
    i guess swap the ecms and read again would be a good way to verify that, but that's a pain. i'm not too concerned with your '94 as it seems to have some one-off issues, but if you wanted to give it a shot, monkey around with the connection timing in that config menu. just screenshot it first so you know what to put it back to

  13. #58
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    next tasks (while i'm waiting for some more hardware to show up)

    start working on the P66 V6 ecms. it'll be good practice, and a good time to do some design tweaks so we can base one command processor on another more generic one, and re-use code more effectively when we dig into the next batch of ECMs.

    then in EE we are going towards a model that will upload all the critical programming code in advance, instead of during the procedure and for each retry we have to do.

    for example right now to erase, it uploads and executes the erase program in a few chunks... we use the same chunks of ram for new routines, so each routine has to be uploaded again when it's used. but kur4o and i have done some work and found that we have a huge area of unused ram in the 8051 that's totally accessible and executable while the kernel is loaded. we can store all of the critical erase/write/vpp/checksum routines in advance, then we can 'call' each segment with a simple jump instruction when it's needed.

    it should take the same amount of time but if we have to retry anything, the code is already there waiting for us, also it'll be nice to know that all of our programs (especially the erase and write ones.....) are valid before we start.

    i plan to play around and find a way to verify that the kernel and this chunk of subroutines is totally intact in ram before starting as well.

  14. #59
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    preloading all of the write/erase/vpp subroutines and calling them from flashhack is a done deal. i've been testing it for an hour and it's good to go.
    failure potential keeps going down

  15. #60
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    managed to handle usb disconnections!

    i yanked the usb cable in the middle of the ESIDE being erased. flashhack realized that the cable was toast, and threw an error, informed the user to try to write again.

    plugged it back in and hit write.

    it realized that the tside has already been written, and that the kernel was already loaded, and verified the written data.

    it resumed the eside like nothing happened. this all happened at an insanely fast speed because all the executable code was already in ram and was just run again.

Similar Threads

  1. LS1 Flash Tool Released
    By antus in forum OBDII Tuning
    Replies: 118
    Last Post: 4 Weeks Ago, 07:02 PM
  2. 24x7 flash tool
    By myburb in forum OBDII Tuning
    Replies: 11
    Last Post: 09-30-2018, 01:17 AM
  3. Dimented24x7's LS1 flash tool issue
    By dzidaV8 in forum OBDII Tuning
    Replies: 1
    Last Post: 07-29-2017, 06:22 PM
  4. $EE Flash tool progress
    By steveo in forum GM EFI Systems
    Replies: 112
    Last Post: 12-17-2015, 06:30 PM
  5. Memcal Flash Tool
    By EagleMark in forum GM EFI Systems
    Replies: 6
    Last Post: 01-22-2013, 05:26 AM

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
  •