Flashhack - New LT1 flash tool

[steveo]

As for the check, that is great for the folks you're talking about who are hobbyists in a garage with a single LT1, but for those of us with multiple (or folks who might want to help work on other cars), it would be nice to have an advanced feature where we could specify a BIN like in EEHack. Or like you mentioned, have Flashhack able to store multiple BINs based on the VIN, so that it can keep track of any VIN it has previously interacted with. That would be super great.

i'm not really into adding that complexity and choice and extra ui stuff to something that works fine in most cases and in the worst case just takes longer to flash, but if you wanted to try to write it, it's open source and i'll consider adding it to the main branch once its tested.

Hm, I thought I caught it trying to talk to one of my other COM ports during one of my tests, so I got into the habit of manually selecting on every start. I'll run some more tests later today to see if it's actually choosing the correct port on startup.

it goes by com port number, of course, so if you had a device assigned to a comp port and later a different device is assigned the same com port number, it'll use that port without question. this is unavoidable, otherwise there would be no way for people to use non-ftdi interfaces.

but if your port is no longer valid, it shouldn't be auto-selecting a non ftdi port.

it's possible there's a bug somewhere, so let me know what you figure what's happening, but if it's just using a com port you selected due to moving interfaces around there's not much i can do about that. i think the detail log specifies when it's auto-selected an interface because yours was unavailable.

[steveo]

one other thing worth mentioning if you're testing the routine is an auto-selected FTDI port is never 'remembered'. that way if your manually selected interface shows up again, it is preferred. again i do not want to add too much complexity here, i expect people that have unusual things going on in their serial config to be cable of manually selecting the correct port if the program does not cover their edge case.

[steveo]

it seems no matter what we do, one of my users can't connect.

i am nearing giving up on it

this version does everything. waits for bus master heartbeat but doesn't rely on its timing but tries time it preemptively. checks responses but doesn't rely on them as long as the bus stays silent. tries to reject floods of bus junk on slow interfaces. logs all junk traffic so we know whats going on.

as usual works fine for me, but all these versions do.

i really hope puts the whole aldl connection issue to bed so i can work on other things.

http://fbodytech.com/flashhack/

if you are testing just to see if it connects, don't run a whole big operation just click 'load kernel' in advanced tab. if it works, awesome. you can run your read/write then (or something else) or just unload the kernel.

[NomakeWan]

Then I hate to have to yet again be the bearer of bad news, but this version actually managed to leave my 94's PCM in a hung state. Not unrecoverable--I just yanked the ECM fuse to clear the RAM and was back in business. But in a state where the E-side was stuck and the T-side wasn't, and the PCM was no longer talking over the serial bus to any devices (including the ABS/ASR and the digital dash).

I did confirm however that Flashhack is automatically detecting the FTDI interface by not touching the config section.

As always, log is attached. It took forever to connect initially, then once it connected all seemed well. I then tried to unload the kernel and things went bad. It wouldn't let me reattempt to unload unless I loaded again, so I did that, then attempted to unload. After that second attempt, the PCM stopped communicating entirely.

[kur4o]

Then I hate to have to yet again be the bearer of bad news, but this version actually managed to leave my 94's PCM in a hung state. Not unrecoverable--I just yanked the ECM fuse to clear the RAM and was back in business. But in a state where the E-side was stuck and the T-side wasn't, and the PCM was no longer talking over the serial bus to any devices (including the ABS/ASR and the digital dash).

I did confirm however that Flashhack is automatically detecting the FTDI interface by not touching the config section.

As always, log is attached. It took forever to connect initially, then once it connected all seemed well. I then tried to unload the kernel and things went bad. It wouldn't let me reattempt to unload unless I loaded again, so I did that, then attempted to unload. After that second attempt, the PCM stopped communicating entirely.

The log doesn`t look that bad as you thought. I can clearly see that ccm is waking in the middle of nowhere and starts spamming the bus.

Initial connection is also slow but the end it make it through.

There is a slight chance that the ccm sends request to pcm, at that point the ccm is shut down, than pcm response to ccm and ccm is awake again.
I suggest sending both modules m8 msg so they shut together. Or the m8 command must be send when pcm response back. On eeack logs I found that some f9 module is also quieted.

NomakeWan can you remove ccm fuse and try it again just to confirm that the issue is indeed in the ccm module.

Best will be to plug another aldl device and log the real serial communication over the bus, to see when ccm is brought back to life.

[steveo]

im not convinced your ‘94 is a good test subject
how about the ‘95?

[steveo]

actually i reviewed the log and i know what's wrong here. i'll release a fix tonight.

[NomakeWan]

The log doesn`t look that bad as you thought. I can clearly see that ccm is waking in the middle of nowhere and starts spamming the bus.

Initial connection is also slow but the end it make it through.

There is a slight chance that the ccm sends request to pcm, at that point the ccm is shut down, than pcm response to ccm and ccm is awake again.
I suggest sending both modules m8 msg so they shut together. Or the m8 command must be send when pcm response back. On eeack logs I found that some f9 module is also quieted.

NomakeWan can you remove ccm fuse and try it again just to confirm that the issue is indeed in the ccm module.

Best will be to plug another aldl device and log the real serial communication over the bus, to see when ccm is brought back to life.

The thing is, 0.5.1 actually worked pretty much perfectly even on my '94. It had an occasional initial connection issue, but once it was connected it could read without major issues and could disconnect and reboot the PCM gracefully. So while I absolutely agree that the '94 has some other issue that's making this a major PITA for all involved, that's kind of the whole point.

Once I get back from work I can yank the CCM fuse just to see what happens, sure.

I also received my Saleae Logic 8 the other day, so I can now do snooping on the ALDL bus while communication is going on. I do need to get my other laptop out of storage to do it though--can't run the data acquisition software on the same machine that's talking to the bus because there's a fairly good chance I'll run out of CPU cycles on the poor little netbook, hahaha. No big, I should be able to work that out tonight.

actually i reviewed the log and i know what's wrong here. i'll release a fix tonight.

Sweet! I look forward to testing the new one.

im not convinced your ‘94 is a good test subject
how about the ‘95?

I always test on the '94 first because it's the problem child, and because it's in the garage. If the idea is to have a robust flash program, I know that the '94 will be the real test to see if it works. The '95 is great as a control just to see if everything works the same way, but yeah.

[steveo]

ok this problem has been bothering me day and night but the universe wants me to win.

i was driving around and found some dude with a 95 vette acting like a chump smoking his tires and whatever, so i ran him off the road with my jeep and confronted him.

i managed to lure him to my house with beer and the promise of a free tune.

i somehow convinced him i was going to secretly supercharge his car with my computer.... (i did nothing...)

i managed to simultaneously 'scope and log flashhack with one of those horrible CCM devices, trying lots of iterations with various serial latency settings.

i threw the last algorithm out.

the new one should be a win.

[sherlock9c1]

0.5.3 tested fine on my bench harness with a B-body tune. I'll email you a log in case you're interested.

[steveo]

this works for me with a vette with 1ms, 3ms, and 16ms latency.

works on the bench with a b-body bin with 1ms, 3ms, and 16ms latency.

works in a ybody with a b-body bin with 1ms, 3ms, and 16ms latency.

works on the bench with an b-body bin with 1ms, 3ms, and 16ms latency.

works on the bench with an f-body bin with 1ms, 3ms, and 16ms latency.

basically if this doesn't work your car must be broken.

i did have a fun thing where my laptop freezes at 1ms latency with this ftdi interface sometimes, just like someone earlier in this thread noted. it's totally a driver issue. flashhack wasn't even open at the time. maybe changing the latency warrants a reboot ?

oh yeah here's the file

http://fbodytech.com/download/1269/

[steveo]

0.5.3 tested fine on my bench harness with a B-body tune. I'll email you a log in case you're interested.

no need for the whole log,

: Found heartbeat, sending mode 8 request with predelay (x)

what's the greatest value of x before it connects?

for anyone testing, the advanced tab DBG_B button is a good way to test just connection, it sends a single datalog packet request so you'll know if the routine works without much reprogramming drama.

[NomakeWan]

Apologies for the delay in reporting back--got caught up in some real life stuff. Anyway I tested out b0.5.3 and it was a resounding success on both cars. Had no trouble connecting and staying connected to the '94, and absolutely no problem whatsoever on the '95. Even bothered to load and unload kernels several times just for good measure, and downloaded the BINs from both cars too. Looks great!

The greatest value of predelay on the both cars is 1, and that's only on initial connection. Subsequent connection attempts (such as clicking "unload kernel" after "load kernel") result in a predelay of 0.

Woohoo! Cheers to some rando on the street with a Corvette, and congratulations on slaying this dragon, steveo!!

[steveo]

my test bench ecm is about to die, which is awesome, it survived fire and abuse and pulling and prying and drunken mischief for the entire duration of making this flash tool. if it died tomorrow i think we're in a good position to continue other work and just have me make small improvements that don't really require in house testing.

so far the new connection code is looking good too, no reports of slow or unstable connections from the very few brave people that are testing this thing.

but there's been a weird bug come up a few times, though, i noticed it once during testing and it never happened again so i figured it was just an odd serial nose thing..but kur4o says it hit him a few times too.

everything looks good, the bus is silent, then we go to make our first command, and there is no serial echo (usually by the time the write is complete, the echo is pretty much waiting in the buffer for us...). then reply comes back ages later with the echo with our next command reply, like a massive lag time, and screws our next command up. it's really intermittent and only seems to happen after we've recently connected to the bus so i doubt it would happen mid-procedure, it's like some oddball leftover buffer issue from the connection algorithm.

just in case it's a real thing, i've gone ahead dropped a new version and increased the time we wait for a serial echo quite a bit, and re-enabled the code that requires the serial echo to be valid to proceed after initial connection, which gives us a larger bucket to try to snag any erroneous bytes from a bus master device waking up out of nowhere (...like corvettes or whatever) but also allows some retry logic to overcome this intermittent bug if it comes up.

as the bug makes no sense and i can't find a real cause, i'm sure this will squish it, but if anyone sees it happening....let me know ?

i think kur4o and i have almost managed to figure out how to make the P66 v6 work properly, which opens up a whole new user base... as usual he's trying to help by making it more awesome than it needs to be, so we'll be waiting a bit for that. i think he's planning to test write it with his bench ecm with no sockets, so i really hope my ameture code doesn't eat the poor thing alive.

then i'll be getting a few prototypes of these in the mail very soon: https://obdxpro.com/
.. and will start work implementing some 96+ VPW ecms.
i'll be the third tool to the party as pcmhammer and LSDroid are functional but i think having another option will be cool, and i don't plan to share or even really look at any of their code base because what's the fun in that!?

[NomakeWan]

Tested the new version just to make sure nothing broke,and sure enough nothing did. Sweet! I also bothered to check the times between my two cars. It takes 3 minutes and 7 seconds to read my '95, and 3 minutes 37 seconds to read the '94. So an extra 30 seconds just for the bus being noisy. However this doesn't affect the outcome whatsoever--communications errors and checksum failures appear to be a thing of the past.

I'm super excited to hear that you're planning on working to support the 96-97 LT1/LT4 PCMs. I doubt I'll ever be lucky enough to find a reasonably-priced '96 Corvette, but if I am, it sure would be amazing to be able to use your software rather than go through the trouble of converting to the '95 PCM.

Looking forward to it!