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
Printable View
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.