Notices
ECU Flash

Unknown table for 88590015

Thread Tools
 
Search this Thread
 
Old Dec 5, 2008 | 03:54 AM
  #1  
acamus's Avatar
Thread Starter
Evolved Member
 
Joined: Mar 2008
Posts: 730
Likes: 3
From: Lattitude 48.38°, Longitude 17.58°, Altitude 146m = Slovakia, for common dude
Unknown table for 88590015

I have found one table that I cant find the purpose of.
The axis are RPM and probably time (MUT_92). The value itself says
number of cycles for output port E bit 15 to be in high state and is loggable via MUT_8E.

Does anyone know the purpose?

Code:
	<table name="Unknown table" address="40b3" type="3D" level="1" scaling="uint8">
		<table name="Time" address="6f60" type="X Axis" elements="10" scaling="Time"/>
		<table name="RPM" address="6f7e" type="Y Axis" elements="9" scaling="RPMStatLimit"/>
	</table>
Reply
Old Dec 5, 2008 | 04:09 AM
  #2  
acamus's Avatar
Thread Starter
Evolved Member
 
Joined: Mar 2008
Posts: 730
Likes: 3
From: Lattitude 48.38°, Longitude 17.58°, Altitude 146m = Slovakia, for common dude
Here is the image
Attached Thumbnails Unknown table for 88590015-unknown.jpg  
Reply
Old Dec 6, 2008 | 11:18 AM
  #3  
acamus's Avatar
Thread Starter
Evolved Member
 
Joined: Mar 2008
Posts: 730
Likes: 3
From: Lattitude 48.38°, Longitude 17.58°, Altitude 146m = Slovakia, for common dude
bump
Reply
Old Dec 6, 2008 | 01:49 PM
  #4  
Mattjin's Avatar
Evolved Member
 
Joined: Apr 2008
Posts: 604
Likes: 0
From: Sydney, Australia
I have been trying to figure out what this map does for months! My first thought was that the x axis was in Volts and that maybe it was something to do with the MAP sensor, but having played with it recently I dont believe it is the case.

For my rom (80700010) it was in the original XML provided with ecuflash as Knock Filter 1, but of course it is nothing to do with knock from everything I have seen.
Reply
Old Dec 7, 2008 | 09:45 PM
  #5  
mrfred's Avatar
EvoM Guru
iTrader: (50)
 
Joined: Mar 2006
Posts: 9,675
Likes: 132
From: Tri-Cities, WA // Portland, OR
Just in case you didn't already know, that table is called from a region of the ROM that contains idle and ISCV subroutines, so its likely related to one of those functions. I don't know any more than that at the moment.
Reply
Old Dec 7, 2008 | 10:23 PM
  #6  
acamus's Avatar
Thread Starter
Evolved Member
 
Joined: Mar 2008
Posts: 730
Likes: 3
From: Lattitude 48.38°, Longitude 17.58°, Altitude 146m = Slovakia, for common dude
mrfred, I know that the values from that table are taken in time of idle calculation, but the value is used just before the knock sensor calculation, this is why I am confused as this might be triggering amplifier for knock.
Reply
Old Dec 7, 2008 | 11:23 PM
  #7  
mrfred's Avatar
EvoM Guru
iTrader: (50)
 
Joined: Mar 2006
Posts: 9,675
Likes: 132
From: Tri-Cities, WA // Portland, OR
Just taking another glance before going to bed. I think you may be using the wrong scaling for the rpm axis. That RAM variable is 16*(2-byte RPM), but it is divided by 16 just before going into the table, so it looks like the scaling should be "RPM" instead of "RPMStatLimit". With the "RPM" scaling, the max rpm value is 996 rpm. This seems to make it more likely to be idle related.
Reply
Old Dec 8, 2008 | 01:04 AM
  #8  
acamus's Avatar
Thread Starter
Evolved Member
 
Joined: Mar 2008
Posts: 730
Likes: 3
From: Lattitude 48.38°, Longitude 17.58°, Altitude 146m = Slovakia, for common dude
I am not sure about scaling, but what I can see is

2byte RPM = (y/8+1)/2

where is is y is RPM variable on Y axis.

Moreover the y = 30720000/RAW_RPM

Last edited by acamus; Dec 8, 2008 at 10:40 PM.
Reply
Old Dec 8, 2008 | 08:33 AM
  #9  
mrfred's Avatar
EvoM Guru
iTrader: (50)
 
Joined: Mar 2006
Posts: 9,675
Likes: 132
From: Tri-Cities, WA // Portland, OR
Originally Posted by acamus
I am not sure about scaling, but what I can see is

2byte RPM = (y/8+1)/2

where is is y is RPM variable on Y axis.

Moreover the y = RAW_RPM/30720000
I'm pretty sure about the scaling. If you are looking at my disassem, then the one you have is a little old. RPM is calculated from X/RAWRPM + 1/2. For the 2-byte RPM at FFFF6B2E (88590015 ROM), X = 0x1D4C000. For the 2-byte rpm used for fuel and timing (FFFF6B1E in 88590015 ROM), X=0x1D4C00, FFFF6B2E = 16*FFFF6B1E.
Reply
Old Dec 8, 2008 | 10:39 PM
  #10  
acamus's Avatar
Thread Starter
Evolved Member
 
Joined: Mar 2008
Posts: 730
Likes: 3
From: Lattitude 48.38°, Longitude 17.58°, Altitude 146m = Slovakia, for common dude
Originally Posted by mrfred
I'm pretty sure about the scaling. If you are looking at my disassem, then the one you have is a little old. RPM is calculated from X/RAWRPM + 1/2. For the 2-byte RPM at FFFF6B2E (88590015 ROM), X = 0x1D4C000. For the 2-byte rpm used for fuel and timing (FFFF6B1E in 88590015 ROM), X=0x1D4C00, FFFF6B2E = 16*FFFF6B1E.
I do not want to argue, you are probably right about scaling,
but my equation
2byte RPM = (y/8+1)/2
is also in your ROM, I made a mistake with RAW_RPM, y = 30720000/RAW_RPM.
I have corrected the post above.

For 88590015 it looks:

Code:
Comparison

ROM:0001E3D6                 mov.l   @(h'184,pc), r2 ; [0001E55C] = unk_FFFF6B2E = y
ROM:0001E3D8                 mov.w   @r2, r2
ROM:0001E3DA                 extu.w  r2, r2
ROM:0001E3DC                 shlr2   r2
ROM:0001E3DE                 shlr    r2
ROM:0001E3E0                 add     #1, r2
ROM:0001E3E2                 shlr    r2
ROM:0001E3E4                 extu.w  r2, r2
ROM:0001E3E6                 mov.l   @(h'17C,pc), r10 ; [0001E564] = unk_FFFF6B1E = 2 byte RPM
ROM:0001E3E8                 mov.w   @r10, r10
ROM:0001E3EA                 extu.w  r10, r10
ROM:0001E3EC                 cmp/hs  r10, r2

Assignment

ROM:00028A56                 mov.l   @(h'1E0,pc), r5 ; [00028C38] = unk_FFFF70EE = RAW_RPM
ROM:00028A58                 mov.w   @r5, r5
ROM:00028A5A                 extu.w  r5, r5
ROM:00028A5C                 mov.l   @(h'1D0,pc), r4 ; [00028C30] = h'1D4C000
ROM:00028A5E                 mov.l   @(h'1CC,pc), r10 ; [00028C2C] = sub_9F2
ROM:00028A60                 jsr     @r10 ; sub_9F2 = R4_DIVIDED_BY_R5_INTO_R0
ROM:00028A62                 nop
ROM:00028A64                 extu.w  r0, r1
....
ROM:00028A6E                 mov.l   @(h'1EC,pc), r10 ; [00028C5C] = unk_FFFF6B2E = y
ROM:00028A70                 mov.w   r1, @r10

Last edited by acamus; Dec 8, 2008 at 10:50 PM.
Reply
Old Dec 9, 2008 | 12:46 AM
  #11  
jcsbanks's Avatar
Evolved Member
 
Joined: May 2006
Posts: 2,399
Likes: 6
From: UK
There are variables from other routines that share the block of addresses with some knock processing stuff, but I don't think that means they are knock related, they are part of longsub_inj (which does loads of things, the one that is run off the 802Hz CMT0 interrupt).
Reply
Old Dec 9, 2008 | 02:50 AM
  #12  
acamus's Avatar
Thread Starter
Evolved Member
 
Joined: Mar 2008
Posts: 730
Likes: 3
From: Lattitude 48.38°, Longitude 17.58°, Altitude 146m = Slovakia, for common dude
Originally Posted by jcsbanks
There are variables from other routines that share the block of addresses with some knock processing stuff, but I don't think that means they are knock related, they are part of longsub_inj (which does loads of things, the one that is run off the 802Hz CMT0 interrupt).
Personally I think it has more to do with Idle. But actually I do not know, therefore I have started a thread
Reply
Old Dec 9, 2008 | 03:46 AM
  #13  
Mattjin's Avatar
Evolved Member
 
Joined: Apr 2008
Posts: 604
Likes: 0
From: Sydney, Australia
I double checked, the values in 88590015 are identical to my 80700010 rom. With my rom, this table is in the same sub with a map that control the ignition retard during decel fuel cut resumption. i.e. When the motor has slowed down and the fuel turns back on near idle, the timing is retarded to smooth the transition.

The scale addresses are known, but in what form is the question. I view mine with X and Y swapped, but for yours try viewing your Y axis in Volts 16 and it looks believable, and try with your x-axis in RPM.

Maybe the map has something to do with the idle ignition timing stability. Every noticed how the timing fluctuates at idle and uses values not in your maps. This is done to help limit the amount of movement the physical idle control system (in this case the stepper motor) has to do to keep idle on target. The systems that do this primarily are MAP sensor based, which is why I always thought the map may have been based on the MAP sensor. Trouble is, I remember playing with this map and never seeing any change in how the vehicle behaves, which is why it drives me crazy.
Reply
Old Dec 9, 2008 | 04:02 AM
  #14  
acamus's Avatar
Thread Starter
Evolved Member
 
Joined: Mar 2008
Posts: 730
Likes: 3
From: Lattitude 48.38°, Longitude 17.58°, Altitude 146m = Slovakia, for common dude
Originally Posted by Mattjin

The scale addresses are known, but in what form is the question. I view mine with X and Y swapped, but for yours try viewing your Y axis in Volts 16 and it looks believable, and try with your x-axis in RPM.
I am pretty sure about the RPM axis, it is RPM. The other one I am not sure the value is taken from Event_Counter_9A_ECNT9A (MUT_90), then processed (MUT_91) and used (MUT_92). I am sure that value controls bit 15 of port E.
Reply
Old Dec 9, 2008 | 04:52 AM
  #15  
Mattjin's Avatar
Evolved Member
 
Joined: Apr 2008
Posts: 604
Likes: 0
From: Sydney, Australia
I thought you may have mixed up the axis? Why would they choose such abnormal values though, especially when this decision is most likely up to the tuner? That is what lead me to believe that axis was not RPM. But if the code says so.... hmmm.
Reply



All times are GMT -7. The time now is 04:15 PM.