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.
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.Originally Posted by Osiel Luna
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?
1990 Corvette (Manual)
1994 Corvette (Automatic)
1995 Corvette (Manual)
i'll throw those files in there soon, thanks. i don't know how that broken eside kernel made its way in there.
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.
1990 Corvette (Manual)
1994 Corvette (Automatic)
1995 Corvette (Manual)
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 whateverI 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!
1990 Corvette (Manual)
1994 Corvette (Automatic)
1995 Corvette (Manual)
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.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.
1990 Corvette (Manual)
1994 Corvette (Automatic)
1995 Corvette (Manual)
can you give me a copy of that bin? i'll find out what's going on thereOkay, 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
Posting Permissions
Reply With Quote
Bookmarks