I don't think Mitsu made a mistake. They want to use the same code for many vehicles, and rather than create a new piece of code that does not any refs to Table #2, they just make it so that Table #2 is never called, and so they don't worry about what is actually in the table. tephra, if you look below the active WGDC routine, you'll see there is another WGDC routine that is not used. All kinds of redundant/unused stuff in the ROM.

Table "#3" is a real table, and it can be called if someone sets the boost limiting vehicle speed to an attainable value. Suggest not deleting that table from the xml. Using the space in ROM where table "#2" is located could be good. Where are you storing your alt maps for fuel and ign?

 

hey mate,

#2 could definitely be used, just because we haven't seen it be used doesn't mean it wont.

I would actually consider #2 having a higher chance of being used than #3.

#3 only gets used if the ROM (and I haven't seen one yet) has "boost limiting speed" set low, ie not 0xFFFF.

yeah I saw the redundant WGDC routine... lots of unused code in the ECU

edit - my patch overwrites the code that selects map #3... I can't see anyone using the "boost limiting speed"

 

Just further to this, the variable that controls whether we choose map #1 or map #2 is the SAME variable/bit that controls whether we should use openloopload #1 or #2.

I am trying to trace it now, but its referenced about 300+ times so finding the right bit of code is difficult.. then you have to trace that code backwards

edit - interestingly enough this variable is set in the Read_Ports subroutine basically:
mov.l @(h'29C,pc), r10 ; [0000BC8C] = unk_FFDF
and r10, r13
mov #h'20, r10 ; ' '
or r10, r13

then later on it pushes r13 back into the variable in question.

Now for those that can't read assembly the above does nothing... LOL!!

However because of the complexness of the code it could be changed someplace else... either way I still stand by my original statement

 

You might have to do futher investigation on #2 then. Code is pretty stupid...either it can do something or it can't. Right now it sounds like you aren't sure about all the conditions that determine the branch into #2 .

 

well my logs indicate and the code indicates that it *should* never branch into #2, however I wouldn't consider this 100%.

IF IT DID branch into #2 then the data read back would be rubbish.

 

If the ECU ever choose table #2, the boost would go haywire because there is no viable data in the location location where table #2 is supposed to reside. Since it never goes haywire, its easy enough to know that the ECU never goes into table #2. Its more of an experimental result, but the answer is definite.

 

Fair enough . Sorry for giving you such a hard time but I always hear "should never" at work which usually lasts all of 3 minutes before it becomes "how the <insert favourite curse word here> did you get it to go down that code path?"

This is pretty common in release code though honestly. Code gets put in temporarily. Someone forgets to take it out, and by the time someone else finds it back its already to late to pull it without destabilizing the whole product. Cheaper to push it out the door as is.

 

Well I don't know how relevant the code in my 7 is to this, but I deffinatly refferance all the tables correctly. Though I am assuming we are looking at code doing a similar job.

MB

 

Also in EDM IX 88840016 and 17 #2 seems "incorrect".

 

Check post 19 in this thread, the plot thickens https://www.evolutionm.net/forums/sh...88#post5247888

MB

 

True but as a real tester I would say that tells me that in that particular test case the code is never hit, but it doesn't tell me whether that test case ever had a chance of being able to get the code to execute in the first place .

Unless the code is fully traced i wouldn't say the answer is definite. Thats a good way to find myself on the bread line

If it was me and I really wanted to find out if that code could ever be called I would:

1) look at the function that ends up pointing to #2.
2) Map all input parameters (if any) and look at all their bounds as well as any global variables used
3) Determine how those input parameters (if any) vary the running of that particular function
4) Map all other functions/code that call into this code as well as input parameters sent to the function
5) Map the functions that call those functions and so on and so forth

Doing the 5 steps above very thoroughly will with 100% certainty answer the question as to whether or not it can ever truly be called.

 

the function itself is very simple, however the control branch uses a VERY common variable, referenced in over 200 places... so going back and saying with 100% certaincy is very difficult.

its just easier to fix up the pointer like what I did in V5

 

Welcome to my world .