the kernel does cycle the CCP solenoid
thats probably your clicking
been meaning to find out why
Printable View
the kernel does cycle the CCP solenoid
thats probably your clicking
been meaning to find out why
oh, is it stored on the eside or tside, though?
new version, played with the ui a bit. i realized that if you click the flash write button 10 times it tries to write 10 times, so now the ui handles the context of 'operation in progress' or 'operation finished' which has been built in from the start... no need to display any progress stuff it things aren't happening, right?
also bigger buttons for touchscreens etc.
set vin/calid imports existing values from the loaded bin too
like it or don't you know where to get it.
Tested it out on my '94, had to make some minor changes to my tune anyway. Worked perfectly, and I like the new interface a lot. Only tiny oops is that the title screen still says 0.5.9 but I mean...that doesn't affect functionality at all.
Being able to flash my troublemaker Corvette is awesome. Speedlogging has been great too!
yeah glad you got that working. higher sample rates were a great thing to attain for doing blm/wideband logging. i dont think a lot of people use it.
i did notice that i forgot to bump the version number...
im glad you like the interface, i feel like i know how to make a nice one but it takes a long time to figure out how to implement it so certain people can find the important stuff. i try to put myself in the mindset of a total computer illiterate person and put the most important buttons right there. it can lead to uglyness but way less support needed on my end.
Reporting back on my success with Flashhack_b0.5.9 on 95 B and F body LT1s.
Did full reads and writes as well as a selective T/E write - no issues.
Had a few minor suggestions - I see that two of them are already covered by b0.6.0 - pre-populating VIN and Cal ids. Still have to test changing these parameters.
For selective writes, an option to let the user specify the reference bin when the autosave doesn't match the PCM could be useful when the user knows the last bin that was loaded to this PCM.
Noticed this was in the $EEhack flash routine.
Took a quick look at b0.6.0 - nice clean interface. I will run some tests with it over the weekend.
Jim
thanks for the feedback and giving it a shot
can you explain when would this realistically happen, when it was flashed with a tool other than flashhack? or maybe a different computer? need a good use case to add yet another user input that could potentially screw something up if people don't use it properlyQuote:
For selective writes, an option to let the user specify the reference bin when the autosave doesn't match the PCM could be useful when the user knows the last bin that was loaded to this PCM.
the next version will fingerprint people with more than one LT1 to tune to allow the selective write function to work well
there is also a bug with the old eehack eside comms patch (disables the recovery rom) the next version will take care of.
will also remember last selected ECM type and allow user to switch at runtime instead of closing the program.
the code is done just need more testing
alright new version is up
- Remember last selected ECM as default because most people dont use it for more than one ecm
- Provide some fixes and a menu option to select a new ECM (so you don't have to restart the program)
- Add a workaround for the E-Side comms patch so the recovery rom works
- Add unique vehicle identifier to EE because nomakewan actually owns two LT1s for some reason
- Use .bin extension properly in save/load dialogs
Sweet, thank you for the unique vehicle identifier code! Tested it by reading both cars, and it saved the unique IDs just fine. Will need to actually make some changes to see if it recognizes them too but glancing at the code it should do that without any issues.
That said, this time I did manage to catch that "unable to reboot T-Side" error on the '94. I've attached a log to this post.
It doesn`t get response on the reboot request. Than the pcm reboots and response on second upload request that is locked. Flashhack assumes it lost comm and tries to unlock pcm. It manages to unlock pcm and enters mode5, than tries to upload reboot code which also crashes tside. Some death loop is triggered here out of nowhere.
Maybe we can increase the timeout before the pcm crashes on reboot upload, so there is enough time for the response to be send.
Thanks for the update Steveo - I'll skip ahead to the new version.
I'll check out the fingerprinting - that could take care of the multiple vehicles with multiple shared PCMs scenarios I had in mind.
Should be covered by having a unique id for each PCM and keeping the latest installed bin configuration for use as the reference.
I'll test out b0.6.1 this weekend.
Jim
just so you know how it works, the 'unique vehicle id' fingerprinting uses a slightly cascaded sum of the calibration id and checksum, which are both values that never change when uploading new bins. make sure your ECMs don't have the same vin and cal id set for some reason.
its a very weak fingerprint that i wrote but i think the odds of a collision exceed the likelyhood that an asteroid will hit the earth every hour for the next year or something. i'm not great with math.
if for some reason my weak sum fails and you run into a collision, it still checksums both the ecm and your local bin before flashing them, so in the worst case it'll just flash the other half of the ECM when it doesn't need to and waste a minute of your time.
Thanks for the info Steveo - the b0.6.1 read/write functions worked with no issues on a 95 F-body, as expected.
However, the vehicle fingerprint kept changing on each subsequent write to the same PCM. Since flashhack then couldn't find a matching fingerprinted bin, each time it defaulted to a full write. It did create and store a new reference bin for each write.
I wrote to the PCM four times alternating between two bins. The only difference between the bins is a spark tweak to test selective write. Here are the four fingerprints:
14MNAO5G24A25TWKA9F
14MML85G24A25TWKAXV
14MMNG5G24A25TWKAVN
14MNGN5G24A25TWKA3G
I verified the PCM vin and cal ids were unchanged using eehack, and read back the last two writes from the PCM using flashhack including the ram region and there were no differences in the cal / vin region.
Hopefully there's enough info above to help point you to the problem. Let me know if you need something more.
Jim
ah that was a typo. posted a new version should work better
Ooh, I'm gonna have to get me one of those OBDX devices. I don't yet have an OBDII $EE, but if I were to get really lucky I might someday. It'd be nice to be able to flash and tune those LT4s just like I do the LT1s.
Also looking forward to the new reboot routine, whenever that gets done. No big in the meantime, I can just load the kernel then unload it again to do the same thing. Cheers!
i had a thought about the reboot routine but i'm working on too much other stuff to play with it. i do want a proper response from it so we can maintain some protocol. its really nice to not have to make workarounds for a bunch of stuff.
the obdxpro seems really nice so far, i do have it talking just on its own, but there are bugs to iron out before i'll even bother hooking it to an ECM. the documentation is a bit incomplete. also there's the small matter that i know absolutely nothing about these ecms or their protocols but i'm sure i'll get there.
i've fixed the reset bug. the e-side was actually the issue. when first resetting it, seems to generate some SPI crap that hangs the tside for a moment, so just needed a small delay in between rebooting the eside and tside. also added a small delay to the reset code itself just to make sure the response has a chance to make it before we wipe the kernel out (probably unnecessary but whatever)
Steve, I have down loaded the new flashhack and tried to get my original bin loaded from the 94-Buick Roadmaster system I'm using. I've read it several times but when trying to save it the file it won't save as a .bin file. I've uploaded the saved files just to check the data into Tuner Pro but nothing was in the file. The "save as type" doesn't offer a bin type.
Want to save original before using an existing bin for the updates I need to make.
i don't understand what that means. do you mean the file is empty? have you pressed 'read calibration'? can you post the log of that?Quote:
I've uploaded the saved files just to check the data into Tuner Pro but nothing was in the file.
yeah it does and has for a few versions now. you might not be using the latest versionQuote:
The "save as type" doesn't offer a bin type.
im pretty sure it's 100% but if people report problems i can increase the delay further. i want you to test the multiple vehicle thing too.
You were right. I had version 5.9 loaded. I just loaded your 6.2 Clicked “read calibration”. Was a successful read and asked to save with a file name. This version does offer the .bin file. I saved it and loaded it into Tuner Pro to see the data. Looked at the “Spark Advance vs RPM vs Map” in the tables, the table had no data in it. When I loaded one of your bins from your site of Factory LT1 bins the same table is full of values.
In scalars the "vehicle speed limit" is 183 in your bin and 0 in mine.
how big is the file?
lets see the log
new version is up
reset thing should work
just use load/unload kernel to test while viewing comms log
Tested it out and it had zero issues reading either car this time. No reboot problems. The unique signature is significantly shorter in this version, and the first two digits of both my cars match, but the remainder is unique to each. I don't have any changes to commit to either vehicle just yet, but as soon as I do I'll see if it detects the signature and maintains the same signature after flashing.
right on
close is okay
like i said before if you run into a collision just change your cal id to something random
that bin is fine, 100% valid
edit: do you think it's factory stock? that calibration ID is a foreign export bin that we do not have. if you're pretty sure it's never been messed with i'd like to add it to my archive.
Was gonna say, looked at it myself and it looks perfectly fine. Are you sure you're using the correct XDF for $EE? Either use steveo's EEX tuning definition (it's in his signature), or use EExtra from http://www.gearhead-efi.com/Fuel-Inj...E-xdf-(EEXTRA)
steveo's is the best for just loading and going. EEXTRA includes a ton of random stuff that is probably unnecessary unless you are doing crazy hacking of functions 99% of people don't use.
Had a chance to flash a new BIN to my '95 today after a bit of a drive at work. Flashhack correctly identified that I had already flashed it, identified the parts of the BIN that were unnecessary, and ran a partial flash successfully. Total time from start of procedure to successful flash: 57 seconds.
Great work!!
nice that's good
i changed vin numbers on my test bench ecm a bunch of times and all my tests seemed successful but it's good to know it works in real life
Tested reading and writing full and partial bins using b0.6.3 on 95 F and B body - all successful with no issues. Full write, selective write to each side, and read bin. Checked out fingerprinting with modified cal id and/or vin on multiple pcms. Flashhack kept track of it all.
I did come across a hiccup only on F-body - I could not reconnect to the bus after a change to the vin or cal id. Needed to cycle ignition power to be able to reconnect. This also would happen after load/unload kernel and closing the interface. I would get a heartbeat timeout message and a report that the bus was still noisy. This would not happen after reading or writing the bin itself, but only after completing one of these three operations.
Flashhack is a great tool - glad to help out on the above however I can.
Jim
can't imagine why that would only happen on the fbody, i guess a comms log of when that happens might be good? i've tested it on the bench and no problemo
Here are some comm log excerpts from F body - I also included connection traffic using 'debug idle traffic'.Quote:
I could not reconnect to the bus after a change to the vin or cal id. Needed to cycle ignition power to be able to reconnect. This also would happen after load/unload kernel and closing the interface. I would get a heartbeat timeout message and a report that the bus was still noisy. This would not happen after reading or writing the bin itself, but only after completing one of these three operations.
I did some more tests to help isolate when this error does and does not occur. I found that for the kernel load/unload/close-interface case the error follows the use of the 'Close Interface' command. If I just load/unload and go to another operation it works without error.
This behavior with cal/vin/kernel-close is consistent and repeatable. Might there be a subtle difference between how these routines return control of the bus as compared to the bin read/write operations? Or how the PCM then re establishes communications with other modules?
F vs B body (9C1) might be due to differences in modules or timing. I have seen the same error on my 9C1 when I tried to connect too soon after key on and modules were apparently still chatting. Also, the 9C1 is kind of a bare bones B-body (no VATS, HVAC).
Hope this helps,
Jim
that's weird for sure. what's the latency set to for your FTDI interface? it's not finding the F056 message. i cannot reproduce the problem. i can only imagine the RX buffer is full of garbage for some reason,
can you do a test where after setting the vin you restart flashhack entirely?