Next EEHack update

[kur4o]

Thanks for the reply, getting ready to order...are any of these "B" chips that read from the bottom or just as your part numbers?

Also, do I use only intel brand or does it matter since it's flash? I ask because I might already have some NOS in my stash pile/box.

Look for N28f010 or N28f512 , Intel brand in PLLC32 package. a is for automotive application, extended temp range, but they are nowhere to be found

Brand matters because of different command set. The pcm is set for use with intel brand.

There is different access time, the lower the better, anything below -120 ns will do the job.

You can also get the 128kb from a 96-97 blackbox pcm.

If you have something available give it a try, they will work. I am sure your onboard` ones will work too. So you might not really need them.

[In-Tech]

Thank You

[steveo]

flashhack is really behaving well with extreme testing. i unplugged the usb cable and then restarted the program, and it flashed again like nothing was wrong. i will do a resume flash feature too to avoid re-erasing.

even if your car battery goes low, if you keep ECM powered enough to stay running, you can go plug a battery charger in and try again, even days later. you just have to be careful not to drop ignition power.

if kur4o's ecm patch works i'm going to be so happy and it'll be insanely hard to brick one of these things.

[steveo]

fixed some more bugs. i'm not very good at math so this is all a struggle. the block mapping algorithm had a off-by-one error that took forever to track down (when you have tons of offsets/sizes/lengths its bound to happen) but it's finally writing all the blocks without re-rewriting anything.

one cool thing that testing has revealed, is re-writing a block doesn't seem to cause trouble (since you're setting a bit that's already set, and the it passes verification no problem) so if you failed a write due to a communication error or power failure, you could probably just safely continue on without re-erasing and causing further risk.

i'm also writing a new progress display that will show you more clearly what's going on, but since it uses matrix transforms and i suck with math, it's not going well yet. will be testing kur4o's recovery patch again tonight and lets hope for the best. once that's working i'll release a beta and let people try it out.

[steveo]

haven't tested that routine yet, but i've implemented the vin and calibration id setting stuff as well as unused region skipping.

i have some more massive to-do items for the user interface, but nothing that should affect getting this out for testing.

i also need some people to test kur4o's recovery patch on a running vehicle to make sure everything is alright, although i don't anticipate any problems

[steveo]

ok all.... happy easter.

please test it as i think it's good enough for release (there are still a few small things to do) but obviously i've only tested it on my bench. i'm pretty excited about how well it's working and i've spent an immense amount of time on it over the last few days.

unlike most flash tools it'll tolerate things like having you unplug and reconnect the aldl cable, and powering down your laptop even in the middle of an erase. the worst case is a USB bus freaks out, but you can reboot your computer and start over. as long as you keep ignition power alive it should be okay. i can't seem to make it fail as long as the ECM stays booted up. obviously don't test this part of the program unless you have a socketed ECM.

unlike eehack this one also tests the checksums of both sides properly and automatically reflashes the failed side without unloading the kernel which is very important since a failed checksum may mean corrupt code was programmed.

if you unplug your usb cable it'll require you to restart the program (because it isn't smart enough to know what's wrong with the interface yet) but it will still recover.

the best part is, the entire interface is abstract and general enough for me to start writing other flash tools with way less effort.

source included / GPL license / free as in (lots of) beer / special thanks to kur4o as usual.

http://fbodytech.com/files/flashhack_beta1.zip

[NomakeWan]

Nice! I'll test this out on the '94 later this evening, starting with a read operation and then a write operation. I don't have a socketed PCM, but I do have an experimental method to flash in situ, so I'll take that risk. Besides, the '94 sits in the garage the majority of the time so no big deal if it's down for a little bit. ;)

[steveo]

oh almost forgot, this is pretty much required on a bbody or ybody (everyone should do it)

with a high latency, the latency can be high enough where by the time we find the gap between packets so we can start talking, that gap is already gone. 1ms is close to a byte length in aldl terms so that lets us time things pretty much per-byte.

ftdi_latency.jpg

[NomakeWan]

Yep, had that set since first trying EEHack.

Anyway, tried flashhack out on the '94 and it wouldn't even connect. I've attached the verbose logs to this post. Seems like it's not correctly identifying the bus master.

[steveo]

0xF1 is the correct bus master for a 'vette CCM so that part is working, but somehow there's a ton of crap in your serial buffer. i'll try a few tweaks and we'll give it another shot.

[steveo]

ahhh. i just had a thought. does the corvette CCM even reply to a mode 8 request? my routine assumes it'll eventually reply but i don't think that's happening here.

[NomakeWan]

I've attached an old verbose log from EEHack doing a read attempt to this post. Hopefully it has the answer you're looking for. If not I can poke around for ya.

EDIT: Here is the datastream definition. It doesn't mention responding to a Mode 08 request.

http://gearhead-efi.com/gearhead-efi/def/aldl/A239.DS

[steveo]

i guess eehack never checks to see if the CCM responds, it just silences it and then pokes at the ECM to see there's solid communication. i guess it's possible some devices respond to the 0x08 request and some do not.

with how busy the ALDL busses are, if we have a half second of silence we're probably okay.

can you test this out? just use the new exe in the old directory. http://fbodytech.com/files/flashhacktmpnomakewan.zip

[NomakeWan]

No good. The one error message about not receiving a response is gone, but it still doesn't connect to the PCM. The car doesn't seem to be affected whatsoever (whereas connecting via TunerCat or EEHack causes the ASR and ABS lights to come on).

[steveo]

i really truly don't understand why the aldl bus on everything but the fbody is so hard to deal with. the logic with this new program is like eehack (but even better as far as i know) i'll need someone to do further testing to see what's going on since i don't have a vehicle, and mine is always just fine on the bench.