No worries, just have the user disconnect the cable.
Printable View
No worries, just have the user disconnect the cable.
i think you're assuming a level of precision that doesn't exist consistently between interfaces and drivers. i'm done trying to 'time' the thing as i want an approach that works for everyone with every interface so i don't have to deal with everyone asking me why its not working. there's a reason no windows based aldl software is doing that. of course if someone else wants to develop and test that approach i will definitely use it upon success but it does have to use QSerialPort as i need this to be multi-platform as well
Thinking big picture, if the sledgehammer method works for now, there's more value add to be had in other areas. Smash away and move on.
i've been trying stuff all night and i'm just too burned out by this aldl crap to write a proper testing routine.
just try this i hope it works.
http://fbodytech.com/flashhack/
oh, to just test the connection routine, use 'load kernel' in the advanced tab or something, if it loads the kernel good, if not no good
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
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.
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.
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.
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.
Testing B.0.4.2 worked fine on my bench, no errors. Emailed you a log. Take a break!
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/
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
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!
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?
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?
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 toQuote:
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?
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.
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
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.
0.5.0 beta, highly recommended. please test it
http://fbodytech.com/flashhack/
Corvette compatibility is completely broken again. Won't talk to either car. Sometimes it won't seem to do anything, other times it'll make the digital dash freak out and display "SYS" and flash the SECURITY light but nothing else. Log of attempting to talk to my '95 is attached.
Haven't tried swapping PCMs to test the checksum thing with 0.4.3, will do that tomorrow if the weather isn't terrible. It rained today so I didn't want to go yanking the PCM out of the car in the driveway.
i haven't really changed anything between the last version and this one that should affect how things connect. please do experiment with the timing settings to see if any adjustments help.
Not sure what to tell you. No matter how many times I hit Read Calibration on either car, the same thing happens--it'll either time out nearly instantly and fail, or it'll send those burst messages like in the log and then complain about failing to become the bus master and fail.
I then switched back to 0.4.3 and it read without any issue on my '95 again. Then as soon as the PCM rebooted I swapped back to 0.5.0 and tried to read and it failed. So something changed between the two that the Corvettes don't like.
please do experiment with the timing settings to see if any adjustments help.
try burst length 6, timeout 10000, silence success 250, purge time 60
maybe the purge time being too high is making it wait too long between bursts
Flash hack 0.5.0 passes bench test on my B-body bin with no change in settings. No errors.
good to know at least b-bodies still work.
what i'd like to see is people playing with the timing on 'vettes since that's where the main trouble is, i really do think adjustment to those settings will yeild something that works, then make sure bbodies and fbodies work with those settings. i actually find the settings i posted above are quite a bit faster when i run a b-body bin. it should be safe to monkey around with those settings as long as you do not lower the "silence success" too low.
the whole reason for me exposing all those settings is so people with actual vehicles can figure it out
i obviously can't reproduce the problem on my test bench and reading logs all day wont tell me what the solution is
well i can't explain why it would matter, but does this one work? the connection code is 100% identical to 0.4.3 and with the new timing settings locked in.
http://fbodytech.com/flashhack/
so it works on both cars now?
guess we have our settings.
can you try with 16ms latency rather than 1ms for fun?
Upping the latency to 16ms caused all sorts of awful things to happen. It took three attempts to connect, and when it finally did connect and run it failed right at the end with a bad checksum error. I dropped it back to 1ms and reran the process. The first attempt after rerunning, the process failed at kernel upload. Then the second attempt failed to connect, then the third attempt connected just fine, identified what state the PCM was in, reset it and reloaded the kernels, and successfully read the BIN. That it is gracefully recovering and now successfully reads once it is fully connected convinces me that this is a solid program--assuming your serial adapter supports 1ms latency, anyway.
It works perfectly on my '95 without glitches, the above are just because the '94 has that weird noisy bus. I have a logic analyzer from Saleae on order, I'll see if I can't figure out what's going on using that once it arrives.
Anyway, now that we mostly have the comms stuff sorted (unless there are some improvements somewhere to make noisy stuff even more robust, but honestly it seems pretty darn good now), on to just housekeeping. First, it would be great if Flashhack could remember the selected COM port between runs. Even better if it could look at the available COM ports and select the most plausible one automatically (my laptop has a broadband wireless chip that exposes two COM ports; neither look anything like the FTDI adapter's virtual COM port, for example they don't expose their serial latency). There's a minor typo in the explanation for "Only write side(s) that have changed" and "Do not write 0xFF regions;" "recommended" has two Cs. In "Clear auto trans tables..." there is a reference to the setting "Patch unused regions," but this isn't the name of any option which can be confusing to an end-user. "Write T-SIDE" should have the same description as "Write E-SIDE" for consistency's sake.
Also, how does comparison writing work, currently? In EEHack it was obvious; you load the BIN you want to flash, you load the BIN that's already on the PCM (or use EEHack to read it), and then do the write. In Flashhack, "Load Bin" seems to be for loading the BIN you intend to write, so is performing a successful read sequence before writing the only way to do partial writes? For safety's sake that makes sense, but it would still be nice to have a way to manually specify a comparison BIN.
That's all I could think of from playing with the beta so far.
it does that. if that port is missing or if no port was ever selected, it then auto-selects the first FTDI interface. it should not autoselect a non-ftdi interface. is it not working?Quote:
First, it would be great if Flashhack could remember the selected COM port between runs. Even better if it could look at the available COM ports and select the most plausible one automatically (my laptop has a broadband wireless chip that exposes two COM ports; neither look anything like the FTDI adapter's virtual COM port, for example they don't expose their serial latency).
it's more idiot proof than that. every time you successfully read or write an eeprom and that has been verified, it stores the bin itself. when you go to write a new bin, it compares with the last known successful bin.Quote:
Also, how does comparison writing work, currently? In EEHack it was obvious; you load the BIN you want to flash, you load the BIN that's already on the PCM (or use EEHack to read it), and then do the write. In Flashhack, "Load Bin" seems to be for loading the BIN you intend to write, so is performing a successful read sequence before writing the only way to do partial writes? For safety's sake that makes sense, but it would still be nice to have a way to manually specify a comparison BIN.
it then runs a checksum algorithm on the ECM to verify the bin on the ECM hasn't changed (or we're not working on a different ECM entirely).
i guess i could make this per-vehicle but 99.9% of my users have one LT1, having the odd extra eeprom flashed isn't the end of the world, especially since this thing is pretty fast.
i've tested this pretty thorougly, although it's possible to doctor a bin so that checksum will think it's the same, since its not a complex hash or anything, in real-world tuning, that's unlikely.
thanks for the typos, i'll fix them eventually
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.
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 at work for a few more hours but once I'm off I'll test out that port selection stuff again. Cheers!
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.Quote:
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.
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.Quote:
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.
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.
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.
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.
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.