I'm not sure if I actually have a 5v or 3.3v cable because a friend sold it to me and don't use the link I posted in that thread.
can I check it with a voltage meter I guess?
Printable View
Attachment 15539Attachment 15540
negative, the cable is the 5v version
The problem that I have when executing to start writing or reading my ECM also have other users or only me?
Ah okay, well glad you didn't use the cable you linked to because it wouldn't work.
As for reading/writing, I don't have any issues but I'm not using the V6, I have an LT1.
Well, I'll keep an eye out for any updates,
Well now I am really looking for a method to restore the flash chip without removing it from the board so I would avoid the fatigue of taking my ECM to an electronics workshop to have the flash chip changed
it is having trouble communicating with your ECM, what ECM do you have exactly? are you sure you have the correct port selected? do any other aldl programs work?
load the Comm log from when this happens and post its contents.
.... also why did you check every option in 'parameters?' did you read them? there should be no reason to use small blocks or ignore oddball chip ids.
It is affecting all users that use the latest download link.
There are some leftover bugs in 2 files that didn`t get updated in the official release.
You can use the provided files and overwrite them in 6811/p66v6 directory.
First try reading the pcm, confirm that the read file is valid and use the read file as a writing file to avoid any files` format differences.
steveo, I've been looking into perhaps implementing some sort of selection or automatic VIN detection routine in Flashhack as you suggested, but upon trying to figure out how it works presently, I may have found a bug. Either that or I just don't know what I'm doing, either one is possible.
So if you read your BIN, it's supposed to save the read BIN to 6811\EE\Storage, right? Well, that doesn't appear to be happening. For one, the modify date on the binaries in that folder never change. And if I load them into the EE Bin Converter and save them as a standard BIN and then load that into TunerPro, it appears to be a stock calibration for...something EE. A manual trans with skip shift enabled, I guess, and the VIN and CAL ID blanked out. This was from my old test of 0.4.3. So I went out and downloaded the BIN from my '94 using 0.5.7, and indeed again the ESIDE_PREVIOUS and TSIDE_PREVIOUS files did not change. I then converted them as I had the ones from 0.4.3 and loaded them in TunerPro. They were almost exactly the same, though oddly two values were different (not counting the checksum). I've attached a screenshot below.
What's going on?
looks like i inadvertently removed the function call that remembers your last bin that was read. it was still remembering on write. i've fixed it and i'll post that new version in a bit
if you want to see how it works or improve/change its detection, the following function in processor_ee would be worth looking at. it returns true if the bin for device_id has changed (or is in an unknown state, which we just assume is 'changed' to be safe)
Code:bool processor_ee::has_bin_changed(int device_id) {
eeprom_ee last_bin = get_local_bin(device_id,"PREVIOUS");
if(last_bin.is_valid() == false) return true; // no previous valid bin
eeprom_ee *this_bin = (eeprom_ee*)bin_for_device(device_id);
// compare
region compare_region(0x2000,0xE000);
region_map compare_map(0x10000);
compare_map.append(compare_region);
if(this_bin->is_identical_to(last_bin,compare_map) == false) {
detailmsg(device_name(device_id) + " does not match the new bin.");
return true;
}
// verify checksum
quint16 bin_checksum = this_bin->generate_simple_checksum(0x2000,0xFFFF);
quint16 ecm_checksum = get_checksum(device_id,0x2000,0xFFFF);
if(bin_checksum == ecm_checksum) return false; // unchanged according to checksum
detailmsg(device_name(device_id) + " checksum mismatch, considering altered.");
return true;
}
the functions to store/retrieve the current bin are right above it. store_invalid_previous_bin just stores a 0 filled bin so future compares would always fail (it's called on erase as the contents are now unknown until a successful write)
if you're wanting the vin, here's how to write a message 4 request and return it as an array
but now the hard partCode:QByteArray processor_ee::get_vin() {
// construct request
datastream_request req(TSIDE,0x01); // mode 1
req.set_first(0x04); // message 4
// submit request
datastream_reply repl = interface->request(req); // send request
// handle errors by returning empty array
if(repl.success == false) return QByteArray();
if(repl.size() < 17) return QByteArray();
// extract vin
QByteArray vin = repl.get_data().mid(0,17); // first 17 bytes
// validate vin here ?
return vin;
}
the kernel or recovery rom will not respond to this request for the current vin, the ecm has to be in a normal state to respond to it.
the current design of flashhack tries its best to treat three possible states equally well so only one 'flash write' button need be pressed and the user doesn't have to know what state the ecm is in after 'something goes wrong' and 'press the correct button or else'. it'd be a shame to lose that
these states are:
- normal (ecm booted up)
- kernel loaded (running in a limited fashion from ram)
- recovery rom loaded (ecm booted but fairly crippled)
and your code needs to behave itself in all three
so if you retrieve the vin this way, the best case might be asking for the vin and just having the request time out if it's not in a normal state
but do you retry? how long will you wait and how much extra time added to the routine would be acceptable? and if it does time out, what do you do, do you assume the bin has changed and flash both sides? if we're in a recovery state, obviously a problem occurred, so is that something we want to do?
to handle all possible states properly we'd need an executable 68hc11 routine we can upload to the ecm after we're in programming mode and running the kernel that reads the value from the eeprom and returns it.
so to do it properly you'd best start with that
i did write thing where you can specify two memory locations and it returns them if you wanted to use it as a base
new version is up to fix those two things, let me know how that goes.
i successfully built it on linux and macos but building it with CLANG on linux did throw some errors because of some casting, so i had to fix a few things up and i'll post that update later.
nomakewan i did have a thought about being able to uniquely identify, you could just use a sum of the vin and cal id. all the code is already there to do so and it would be very fast. the chances of two cars having the same vin and cal id sum is low enough.
Tested 0.5.8. Looks like there's some sort of race condition concerning the saving of the ESIDE_PREVIOUS and TSIDE_PREVIOUS; saving them works, but the time lag between those two operations appears to be able to cause the TSIDE to hang. I did a read operation and everything seemed to work perfectly, except that it didn't actually attempt to reboot the TSIDE until after I clicked "OK" on the "Read procedure complete" prompt, at which point it failed to reboot. I then had to load kernel followed by unload kernel in order to fix it.
I had a look at the code but couldn't figure out why this would be. I've always thought it was weird however that the "Read procedure complete" prompt would pop before the save prompt would since that felt a little jittery, but I mean, unload_kernel is a single function so I can't explain why it seemed to reboot the ESIDE and then wait to do TSIDE and fail. Unfortunately I don't have a log, and it didn't do it on my second try, but I did notice that after clicking "OK" it reentered programming mode (both said it in the text box and the fans kicked on for a longer period), after which it gave up and said it failed to reboot TSIDE. Hopefully that gives a hint as to what happened.
the flash processor doesn't know whether you've clicked ok or not, it runs in a separate thread, and it just signals the operation is complete. it (on purpose) doesn't have any mechanism to wait for the user to click ok or whateverQuote:
I did a read operation and everything seemed to work perfectly, except that it didn't actually attempt to reboot the TSIDE until after I clicked "OK" on the "Read procedure complete" prompt, at which point it failed to reboot.
what happens in fact is the reboot executes while the dialog was open but the log doesn't update (because the dialog is blocking the gui)
the dialog is a bit annoying, i might get rid of it anyway and make something better to signal that an operation is complete. i still have the horn honking thing on standby.
i guess we can wait till the operation is over to see if that helps
Ah, I hadn't thought that the log update would be blocked like that. Good to know!
The horn thing would be kind of funny, but it's too bad it only works on Corvettes. :P
I'm gonna try to log my commutes a bit this week on my '95, make a few adjustments, and then test Flashhack's flash routine on it. First time I'll be doing something other than reading with it. I'll let ya know how it goes!
Ur PM if full, steveo :)
yeah i cleared it. this flashhack thing is really blowing up my inbox.. luckily none of the emails have said 'your crappy program bricked my ecm you rat bastard'
right on, i'm pretty sure it wont let you down if you don't lose power. i haven't been able to botch a flash with it despite my best attempts. flash is actually 1000x more tested than read is, i've barely used the flash read thing, maybe 20 tests, but i've looped the flash routine overnight a few times. i was worried it failed once but it was actually just solder breaking loose on the socket.Quote:
I'm gonna try to log my commutes a bit this week on my '95, make a few adjustments, and then test Flashhack's flash routine on it. First time I'll be doing something other than reading with it. I'll let ya know how it goes!
Okay, I went ahead and flashed a new program. All I did was change some fan-related settings and the VE table. First attempt to flash failed because the program noticed that my E-Side code had patches and thus was incompatible. Something to work on going forward, perhaps, to make sure that community patches from EEHack/TunerPro work with the recovery patch, I guess. So then I disabled just the E-Side recovery patch and flashed. I think leaving the T-Side recovery patch enabled may have caused the complete re-write. Perhaps had I disabled that too, it would've flashed less. Not sure.
Either way, here's the first write to a Corvette using Flashhack, which was a success.
The '94 doesn't use any patches from EEHack since it was unsafe to flash using that program in the past, so I'll make a few minor changes to its BIN as well and try to flash and see what happens. Perhaps tomorrow.
can you give me a copy of that bin? i'll find out what's going on thereQuote:
Okay, I went ahead and flashed a new program. All I did was change some fan-related settings and the VE table. First attempt to flash failed because the program noticed that my E-Side code had patches and thus was incompatible
Sure thing. I've attached the before (read_test) and after (read_test_write) BINs to this post.
I'm gonna make a shot in the dark and say it's the E-SIDE comms patch. I was never actually interested in that particular patch for my purposes but it's installed as part of the EEHack package, so.
Thanks for the assistance!
The same thing happen to me, it is the FFs that are filled at the end of the eside. No need to worry I make sure that the minirom patch is compatible with all the other patches that are floating around. It is not compatible only with eeb eside revision bins.
i'll work on this tonight, thanks for the example bin. someone else reported this but never sent me their bin
don't know if this has been mentioned but is it possible to add Flashhack as additional folder in EEhack program and change in EEhack so that Flash buton will just run Flashhack form sub-folder ?
bes regards
honestly, there would be hours of my time spent to just save you the few seconds it takes for you to close eehack and open flashhack.
logging and flashing are rarely something you would need to access from a unified interface for any real purpose
another problem is flashhack is under active development and eehack isnt
and flashhack will handle more than the lt1
thats why bundling them makes zero sense
ok i've had a quick review and i agree that it's totally safe, if you know your bin hasn't been customized by any crazy patches that we don't know about, that you can just unset the 'verify patch regions against reference' parameter. that'll allow the thing to install.
the reason i do a strict compare by default is i'm fearful that someone else will try to upload a bin that has been customized in an unknown way, and our 'recovery' patch will somehow cause that bin to be unbootable or not enter programming mode. for that purpose it compares the comms code against a stock f-body bin.
i'll work on a workaround that allows it to work as designed while still protecting against such things. i thought for sure i had checked against eehack's patches but i guess thinking back, i never got around to doing that properly.....
by the way the new EEX xdf does have those eehack patches in it, so if you want speed logging or whatever in eehack in the future, that's how you get it.
Oh, thanks for the EEX! I forgot it got updated to 4.0. Grabbed that and used it to patch my '94 for flash testing later. I did notice though that there's no "remove patch" in EEX for the EEHack patches. Intentional or oversight?
I'll go ahead and use that workaround for now and test flashing on both cars again over the weekend and let you know how it goes. Thanks!
I mean for me personally? No not really. Just I'm used to being able to revert stuff. :P
if someone wanted to take the time to fix that, i'll put it in. i still haven't copied over the eside comms patch yet either. might be nice to get some help with that
new version should solve that eside patch issue, maybe get V6 read working, probably compile for linux. you know where to get it. no warranty
Hilariously enough spotted it while looking for some stuff on your website and grabbed it.
I've got the "Remove Patch" functionality for the EEHack stuff done, and am working on implementing the same for kur4o's E-Side Comms stuff. I took a break for dinner but as soon as I'm done eating I should be able to have it ready in an hour or so.
cool, thanks for pitching in with that. im stretched a bit thin right now so EEX isn't really on my radar but i'll trust any changes you've made and post 'em on my site.
All done. Turns out you had in fact ported over his E-Side comms stuff; you just accidentally placed an incomplete version under "Miscellaneous" that only included the MODE2/MODE3 message, while the full E-Side patch (including the MODE2/MODE3 message) was listed under Experimental. I have removed the erroneous entry under Miscellaneous, and added the base data for the EEHack patches so that they are removable. Just in case, I dunno, some Corvette owner wants to datalog oil temperatures while racing or something.
Is it the last EEX version and is recommended to use instead of steveos's from his website?
they're the same now
i can't join the 60 degree v6 forum to try to get some new testers, it seems i never get a verification email.
if anyone has a membership over there can you make a post to try to find some more testers for the P66 flash tool?
does the set vin and calibration id thing work for the V6? i assumed the commands are the same..
Hey steveo, just wanted to let you know that I tested 0.5.9 on my '95 and yes, it fixed the T-Side recovery patch bug. Flashed without any issues. So that being the case, I tried it on my '94. Didn't change any settings, just loaded the new BIN and hit write. Worked absolutely perfectly. There was a weird repetetive clicking noise somewhere in the engine bay after the fans kicked back down that I couldn't trace because I was in the car with the door closed and wanted to stay that way, so I'm not sure what it was, but it didn't affect the process any. Despite the noisy bus, Flashhack had no issues flashing the car, and she fired right up afterwards. Now I have speedlogging on the '94 finally!
Congratulations, flashhack is amazing work. I hope the OBDII stuff works out too, it'd be amazing to be able to support the 96-97 LT1/LT4 cars!