there's nothing linear about sound levels anywhere, once you've implemented a non-uniform hole in a sack of meat with a meat flap connected to a series of nerves as your mic
there's nothing linear about sound levels anywhere, once you've implemented a non-uniform hole in a sack of meat with a meat flap connected to a series of nerves as your mic
well, i'm stuck for now. the kernel works, reset works, read works, the write routine transfers and executes, but the VPP code itself crashes the ECM and doesn't reach the reply subroutine even though it seems like its identical to the 68K code i was using with eehack.... this might take some time to debug. once that's done i will work on a bit of an interface to load/save bins and let you all play with it.
we're winning!
it reads and writes.
the new logic for handling unknown kernel state on program reboot works perfectly, i made some major mistakes in the flash logic itself, and when i had to quit and recompile flash hack a bunch of times, as long as i didn't cut ECM power, i could re-erase and start over. the eehack bugs regarding re-erase are gone.
it does reboot nicely which means at the very least kur4o's patch goes back to normal execution when we set 'the switch'.
now to test kur4o's patch properly and see if it does hardware recovery on ecm power failure. i'll just yank the plug halfway through and see what happens.
Wooohooo, now that's testing.Originally Posted by steveo
-Carl
the first attempt to do a hard power fail recovery was no good. i've been in touch with kur4o and we'll figure out what happened and try again
things are going very well with testing. it recovers from all manner of crazy serial noise or whatever. the aldl bus is hard to manage during failure as you can have an arbitrary number of bytes dumped into your 'serial echo', thereby extending it..
i have it in a state where unplugging the serial cable and plugging it back in at random seems to resume okay, and killing the program during a flash is also okay. i even killed it in the middle of an erase and started the program again, and it's good to go.
if it times out from being unplugged too long, you can just press 'flash write' again and it'll start over. if another bus master device takes over, it'll kill that too. it's getting really hard to brick.
there's no recovery from ECM power failure yet but i think we'll get there, as all the technology is there (it uses write block maps, so we can prioritize certain blocks) i just don't think i quite understand how to use the method kur4o came up with yet, and it's probably me.
I haven't followed along with the LT1 stuff as well as I should have. I don't have one of those vehicles to play with. I do, however, have at least 2 bricked pcm's. I was at a dyno shop a few years ago and a guy bricked a couple during flash and ended up giving them to me. I'll have to look if they are obd1 or 2. I'm not even sure these have the gm service stickers on them to identify. Are these recoverable without a hardware attack?
-Carl
Posting Permissions
Reply With Quote
Bookmarks