-
don't suppose you want to stick the questioned values into one of the datastreams that come from the E-side to see what they're doing while the engine is running?
i don't remember if EE primarily communicates through the E or T side though, either way, they can both chatter directly over ALDL.
-
that's a great idea! i'd be up for that
i do have to do a flash in the next few days to fine tune some other stuff anyway, and i could log it for a bit.
can you help me figure how to patch it? that might even become permanent, if L0196 is what it think it is, it would be really useful to have in the datastream all the time.
i think it's all T-side for datastream from what i've seen, this all seems to be done on the e-side. the comms between the boards part still trips me up a lot.
oil temp is a good one to override on EE i think, since f-bodies spit it out but dont really need it...
for now, i have to sleep
-
sorry for all the noob questions here, i think i'm getting it.
over coffee i managed to figure out some of the park/neutral and idle table selection routines,
i had a goal a while ago for my first actual code patch, trying to get p/n switch behavior in bins without the automatic trans bit set, just to enable selection between the two idle target tables. in my case, i could have 'show off the lope' as well as 'sleeper mode and/or wife is in the car' idle configurations.
it looks like there's only a single branch that checks the transmission type in that entire routine, and it seems to skip a small section of further branching if it's a manual trans:
Code:
557E F6 20 26 ldaB b_2026_b1_6spd_b6_auto
5581 C5 40 bitB #%01000000
5583 27 0C beq @87
reading the 68HC11 specs, i'm guessing i could just patch that 0x27 BEQ with 0x21 BRN, and it'll never branch.
is this a good way to skip a branch in this platform without screwing around too much? seems that way, since it would preserve the jump address, and make it a one-byte patch, right?
-
looks like the DS files only show communication with the F4 side, E-side appear to be E4, i'll have to work out how the streams are setup in it.... for some reason, it looks like a whole bunch of tiny streams, which may work out to your advantage.
-
BRN seems like a good idea.
-
cheers thanks, i'll give it a go! i'll look at the datastream stuff too but i think its a bit over my head right now.
before i get too far into this, im going to go on a campaign for a spare ecm donation
i think my flash is probably about due to expire if i dont brick it myself from noobcode :mad1:
if i dont find one, im going to have to break my ol' honda out of storage just so i can get to work if something goes south
-
i really do appreciate your help with this stuff robert, im going to try to educate myself pretty quickly so i can start figuring this crap out on my own. i have a really good chunk of the 68k instruction set memorized now.
-
hmm...... looking at the E-side, i'm not certain that all of the ALDL stuff is present.... i'm not finding a datalist that would get transmitted during a mode 1 request...
may have to do mode 3 on the E-side to get those bytes, assuming that is implimented. the other P66 applications allow mode 1 on both sides, i'm not sure why it isn't implimented here....
otherwise, may have to send out a generic mode 1 command to the E-side and see what it responds with. if it suddenly dumps a whole bunch of data, then will have to dig further to try and figure out where it is coming from.
-
ooh, is it possible the hard work i've put into a utility designed to make the ee datastream my bitch may be helpful here? ;)
that's how i stumbled on how to get it into flash mode before i could even stomach looking at the disassembly, i basically just fuzzed the thing.
looking back i guess im lucky i didnt accidently start the prom erase procedure or something.
i have a dump of the result of every mode combination, if i remember which laptop i used to get it. i'll check when i get home
-
assuming you sent commands to E4 as well, then that could certainly be useful.
-
i think i did? F4 t-side E4 e-side or some such thing?
-
that is how it appears to be setup.
-
i think i just ran all two and three byte combinations all the way from 0x00 to 0xff and logged the results.
unfortunately, this is just a theory, but those results i have on anything other than F4 might be unreliable.
my software is stateful enough now to know how long it's been since a valid reply, and resends F4 a disable comms and confirms silence if it's been too long.
.... but it wasn't back then, those were early days
i think it's only valid requests on F4 that reset the disable comms counter on the ecm (which seems approx 3 seconds long, so i consider 2500ms a good 'nuff threshold). i don't even know for sure that requests to E4 will make it maintain silence.
so i bet they're peppered with random idle chatter by the time it actually counted up to E4, which would have taken a hell of a lot longer than 3 seconds. that explains why i was getting weird short packets from requests that shouldn't have done anything.
i think i'll just do it again.
-
i found the files i had leftover, but no useful queries from E4. i'll do another run across E4 tonight see if anything comes out.
-
I tried a fairly large set of requests to e4 and couldn't get it to spit anything out at all; ill have to keep working on it;
Robert, the aldl comms would use the 68hc11 standard serial line register right? I haven't tried to look for them yet