Hi Guys,

In my travels for boost control I found something rather strange:




This is for my ROM 88580014 but its exactly the same for 88590015.

You can see that 0x3f82 is being referenced as "Max Wastegate Duty # 2", however this is INCORRECT.

The ECU SHOULD be pointing to 0x3f6c.

Now I don't know if this has been discussed before, I've asked MrFred, but I thought I would post to the masses as well.

So what you put into ECUFlash in #2 doesn't actually do ANYTHING, in fact when the ECU uses "#2" it actually reads invalid crap from headers for "#3" and some of "#3".

WTF Mitsu???!?

 

Interesting, so the tags are linked to something else entirely, maybe a fuel or timing switch? I can see what the addresses you refer to but its odd that they dont even reference what they should.

I am with you, WTF Mitsu...whats the idea?

 

Yeah you can see that on a stock car if the ECU read from #2 it would actually be reading header info from #3 and part of #3.

on the left is what it *SHOULD* be (what ECUFlash is setup) and on the right is what the ECU *currently* sees:




fubar'd

Anyways it looks like under normal conditions #2 isn't ever read anyways. Same with #3.

So basically we need only modify #1 hehe

 

OMG they did the same thing for the BDEL code as well!

what the F Mitsu!

Same thing with BDEL, only #1 gets used!

#1 = NORMAL
#2 = Maybe CEL condition/Error cond
#3 = Car speed greater than @0x1e04 (0xFFFF mostly, ie NEVER!!)

Hence for a normal car #1 is the only Max/Baseline Wastegate Duty and BDEL map that gets used!

 

Ah but this comes back to the xml used in the reverse engineering. Reverse engineering is guessing and thats what those xmls do.

They guess as best as they can. Its also possible the tables were either there from an earlier model or will be used in a later one.

Or they were just plain old debugging tables that were never removed. Good information to know though

 

ECUFlash is a big guess, about half of it is correct. I bet those little engineers at mitsu have a blast viewing this stuff. I wish a disgruntled employee would enlighten us on what is really going on

 

That's good to know.

 

no guys the code is wrong, the tables are "correct" in EcuFlash, but the code is wrong

What I might do is get rid of 1/2/3 and just convert the code to all use #1
Then I can use the #2 ROM spot as my alternate map.

I'm guessing most people would prefer 1 BDEL and 1 WGDC map rather than 3x

 

Agree having to deal with one each is much simpler to deal with not to mention cleaner overall.

 

This was going to be my recommendation. Or remove 2 and 3 from the xml entirely.

 

You could remove that from the xml yourself. Him removing it won't do much for you since he doesn't own the next version of ECUFlash which unless colby and co are notified will probably have in the same error again.

 

Can it ever logically branch into the #2 table (its obvious it can't for #3)? If it can't then its irrelevant what they point to at the end of the day for most people. For your patching I suppose you've gained a bit more space to stuff other useful stuff.

 

yes, although all the logs I have done show it never does.

 

He he, sig material.

God I wish I could read all this code crap so I could help.

Back on topic.

 

Great idea.