Unknown table for 88590015
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?
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>
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.
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.
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.
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.
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.
Trending Topics
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
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.
EvoM Guru
iTrader: (50)
Joined: Mar 2006
Posts: 9,675
Likes: 132
From: Tri-Cities, WA // Portland, OR
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.
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'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.
but my equation
2byte RPM = (y/8+1)/2
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.
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).
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 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.
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.
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 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.
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.


