ROM disassembly as raw text file
Jul 26, 2011, 08:20 AM
#16
Evolved Member
Thread Starter
Hiya.
I'm looking for someone to double-check my work - someone familiar with m32r disassembly and "Direct PSI Based Boost Control"...
Could you please take a look at my newly minted 53610010 ROM defs below, and see if I've got everything right.
If I have, then these are Direct PSI Based Boost Control defs for Ralliart 2009 AUDM/EDM 53610010. And I will do a happy dance.
...and no rush! I'm not in a hurry to apply this to my ROM and drive, as I've just spent FOREVER getting load-based boost control dialled in. This is largely an exercise to see if I'm on track.
But if it's all good, I'll post it up in the relevant thread, and we'll have one more ROM supporting this boost control mode.
Here's how these tables look in EcuFlash...
...but note that I have NOT adjusted a single thing, so it's really showing my old load-based "Boost Control Load Offset" byte value as "Atmospheric Boost".
Ditto for "Boost Target #1A", which is showing my current "Boost Target Engine Load #1A" data, reinterpreted.
Please let me know if I've got this right. I'm not feeling bolshie enough to make the changes in my ROM and drive on it. Not without a review from someone more experienced.
Rich
I'm looking for someone to double-check my work - someone familiar with m32r disassembly and "Direct PSI Based Boost Control"...
Could you please take a look at my newly minted 53610010 ROM defs below, and see if I've got everything right.
If I have, then these are Direct PSI Based Boost Control defs for Ralliart 2009 AUDM/EDM 53610010. And I will do a happy dance.
Code:
<table name="Atmospheric Boost" address="53484" category="Direct Boost" type="1D" scaling="psia16"/> <table name="Boost Target #1A (High Gear Range)" address="58e8d" category="Direct Boost" type="3D" swapxy="true" scaling="psia8"> <table name="Throttle" address="62672" type="X Axis" elements="9" scaling="Throttle_Main - Stored Minimum Throttle %"/> <table name="RPM" address="625f0" type="Y Axis" elements="18" scaling="RPM"/> </table> <table name="Boost Target #1B (High Gear Range)" address="58f37" category="Direct Boost" type="3D" swapxy="true" scaling="psia8"> <table name="Throttle" address="62672" type="X Axis" elements="9" scaling="Throttle_Main - Stored Minimum Throttle %"/> <table name="RPM" address="625f0" type="Y Axis" elements="18" scaling="RPM"/> </table> <table name="Boost Target #2 (Low Gear Range)" address="5743d" category="Direct Boost" type="3D" swapxy="true" scaling="psia8"> <table name="Throttle" address="62672" type="X Axis" elements="9" scaling="Throttle_Main - Stored Minimum Throttle %"/> <table name="RPM" address="625f0" type="Y Axis" elements="18" scaling="RPM"/> </table> <table name="Target Boost Error Correction" address="58d20" category="Direct Boost" type="2D" scaling="OffsetWGDC"> <table name="Boost Error" address="6261a" type="Y Axis" elements="17" scaling="BoostErrorPsi"/> </table> <table name="Variable for Boost Control 0xC774 -> 0xC71A" address="9f516" category="Direct Boost" type="1D" scaling="Hex16"/> <table name="SHLR->SHLR2 0x5101 -> 0x5102" address="9f518" category="Direct Boost" type="1D" scaling="Hex16"/> <table name="Boost Error RAM Address 0xC590 -> 0xC58E (is 0x80858e for logging)" address="9f53e" category="Direct Boost" type="1D" scaling="Hex16"/> <table name="Boost Error RAM Address in Load Error Table 0xC590 -> 0xC58E" address="62616" category="Direct Boost" type="1D" scaling="Hex16"/>
...and no rush! I'm not in a hurry to apply this to my ROM and drive, as I've just spent FOREVER getting load-based boost control dialled in. This is largely an exercise to see if I'm on track.
But if it's all good, I'll post it up in the relevant thread, and we'll have one more ROM supporting this boost control mode.
Here's how these tables look in EcuFlash...
...but note that I have NOT adjusted a single thing, so it's really showing my old load-based "Boost Control Load Offset" byte value as "Atmospheric Boost".
Ditto for "Boost Target #1A", which is showing my current "Boost Target Engine Load #1A" data, reinterpreted.
Please let me know if I've got this right. I'm not feeling bolshie enough to make the changes in my ROM and drive on it. Not without a review from someone more experienced.
Rich
Jul 27, 2011, 09:41 AM
#17
Evolved Member
Thread Starter
This wading through disassembly following breadcrumbs stuff is quite fun.
I think I've just come across a subroutine that retards timing based on overboost, ie. depending on how much over your boost target. Cool.
It uses a small 2D table, but the timing offsets are all zeroed out... so it's dormant.
If it were brought into play, it wouldn't play nice with "Direct Boost Control" - it'd need an additional patch to point at boost instead of engine load.
Still, neat.
In my travels, I've also fixed a few dodgy EcuFlash address errors in the 53610010 definition, found some funky looking 3D tables, matched up and defined a number of stock-evo-def tables in 53610010, etc. etc.
The Aus Ralliart ROM is getting some TLC...
Rich
I think I've just come across a subroutine that retards timing based on overboost, ie. depending on how much over your boost target. Cool.
It uses a small 2D table, but the timing offsets are all zeroed out... so it's dormant.
If it were brought into play, it wouldn't play nice with "Direct Boost Control" - it'd need an additional patch to point at boost instead of engine load.
Still, neat.
In my travels, I've also fixed a few dodgy EcuFlash address errors in the 53610010 definition, found some funky looking 3D tables, matched up and defined a number of stock-evo-def tables in 53610010, etc. etc.
The Aus Ralliart ROM is getting some TLC...
Rich
Jul 27, 2011, 09:52 AM
#19
This wading through disassembly following breadcrumbs stuff is quite fun.
I think I've just come across a subroutine that retards timing based on overboost, ie. depending on how much over your boost target. Cool.
It uses a small 2D table, but the timing offsets are all zeroed out... so it's dormant.
If it were brought into play, it wouldn't play nice with "Direct Boost Control" - it'd need an additional patch to point at boost instead of engine load.
Still, neat.
In my travels, I've also fixed a few dodgy EcuFlash address errors in the 53610010 definition, found some funky looking 3D tables, matched up and defined a number of stock-evo-def tables in 53610010, etc. etc.
The Aus Ralliart ROM is getting some TLC...
Rich
I think I've just come across a subroutine that retards timing based on overboost, ie. depending on how much over your boost target. Cool.
It uses a small 2D table, but the timing offsets are all zeroed out... so it's dormant.
If it were brought into play, it wouldn't play nice with "Direct Boost Control" - it'd need an additional patch to point at boost instead of engine load.
Still, neat.
In my travels, I've also fixed a few dodgy EcuFlash address errors in the 53610010 definition, found some funky looking 3D tables, matched up and defined a number of stock-evo-def tables in 53610010, etc. etc.
The Aus Ralliart ROM is getting some TLC...
Rich
Found any fan control stuff yet?
Jul 27, 2011, 10:31 AM
#20
Evolved Member
Thread Starter
Hi Bryan.
Afraid not - haven't been looking at fan stuff. I'm concentrating on sussing out a few things in the area of timing.
Particularly interested in finding the logic that decides when it's an SST upshift, and therefore when to use the Lower Boundary Spark Map. Because mine usually doesn't do that! Apparently, everyone else's does.
That still eludes me, but I've already ticked off some other stuff on my "to-do" list, like:
Rich
Afraid not - haven't been looking at fan stuff. I'm concentrating on sussing out a few things in the area of timing.
Particularly interested in finding the logic that decides when it's an SST upshift, and therefore when to use the Lower Boundary Spark Map. Because mine usually doesn't do that! Apparently, everyone else's does.
That still eludes me, but I've already ticked off some other stuff on my "to-do" list, like:
- Finding a better timing-based load to log. Now I have the "final" load address, which will be EITHER the baro OR the baro+temp adjusted load, depending on temp. And I have the temp switchover point too, for good measure.
- IAT based timing compensation table.
- Baro based timing compensation table.
- Direct Boost Control tweaks... untested, as yet.
- The CORRECT address for boost control "Xover Gear Based" value for my ROM.
Rich
Jul 27, 2011, 10:37 AM
#21
Hi Bryan.
Afraid not - haven't been looking at fan stuff. I'm concentrating on sussing out a few things in the area of timing.
Particularly interested in finding the logic that decides when it's an SST upshift, and therefore when to use the Lower Boundary Spark Map. Because mine usually doesn't do that! Apparently, everyone else's does.
That still eludes me, but I've already ticked off some other stuff on my "to-do" list, like:
Rich
Afraid not - haven't been looking at fan stuff. I'm concentrating on sussing out a few things in the area of timing.
Particularly interested in finding the logic that decides when it's an SST upshift, and therefore when to use the Lower Boundary Spark Map. Because mine usually doesn't do that! Apparently, everyone else's does.
That still eludes me, but I've already ticked off some other stuff on my "to-do" list, like:
- Finding a better timing-based load to log. Now I have the "final" load address, which will be EITHER the baro OR the baro+temp adjusted load, depending on temp. And I have the temp switchover point too, for good measure.
- IAT based timing compensation table.
- Baro based timing compensation table.
- Direct Boost Control tweaks... untested, as yet.
- The CORRECT address for boost control "Xover Gear Based" value for my ROM.
Rich
Jul 27, 2011, 03:58 PM
#22
Evolved Member
Thread Starter
Jul 27, 2011, 05:16 PM
#23
Evolved Member
Thread Starter
...yeah, unless I've really got my conditional branches downside-up, it's operational until timing is less than zero (ie. 20 in ROM-speak)...
Everyone's obviously done just fine without this mechanism, as they just tune the spark map appropriately above the target load/boost area.
But I still think it's neat.
Rich
Code:
tag- SUBR: subr_timing_retard_on_overboost
tag- : Supplied: r0 (timing).
0x21d4c: 2e 7f 2a 7f st lr,@-sp -> st r10,@-sp tag- : Returned: r0 (modified timing).
0x21d50: 29 7f 28 7f st r9,@-sp -> st r8,@-sp
0x21d54: 18 80 50 50 mv r8,r0 -> slli r0,#0x10 tag- : Put r0 into r8, then limit r0 to...
0x21d58: 50 10 1a 80 srli r0,#0x10 -> mv r10,r0 tag- : ...0xffff. Then put r0 into r10
0x21d5c: 61 14 0a 51 ldi r1,#20 -> cmpu r10,r1 tag- : Set r1 to 20. If r10 < r1 (20) then...
0x21d60: 7c 17 f0 00 bc 0x21dbc || nop tag- : Jump to 0x21dbc
0x21d64: a1 bd cb 5a lduh r1,@(-13478,fp) tag- : Load r1 from 0x808b5a (BTEL map lookup result)
0x21d68: e4 05 34 84 ld24 r4,#0x53484 tag- Tabl: Load r4 with boost_control_load_offset (direct_boost)
0x21d6c: 22 b4 01 a2 lduh r2,@r4 -> add r1,r2 tag- : Load r2 with @r4
0x21d70: a2 bd c7 74 lduh r2,@(-14476,fp) tag- : Load r2 from 0x808774 (Engine Load - direct_boost)
0x21d74: 52 01 10 82 srli r2,#0x1 -> mv r0,r2
0x21d78: 40 20 f0 00 addi r0,#32 || nop
0x21d7c: fe 00 b1 e1 bl 0x4e500 tag- Call: subr_subtract_r1_from_r0
0x21d80: 50 42 f0 00 slli r0,#0x2 || nop
0x21d84: fe 00 af a4 bl 0x4dc14
0x21d88: a0 2d c5 90 sth r0,@(-14960,fp) tag- Scal: Store rx into RAM 0x808590 (for scale lookup)
0x21d8c: e0 06 26 3c ld24 r0,#0x6263c tag- Scal: Boost Error % Scale, +ve only.
0x21d90: fe 00 b1 a0 bl 0x4e410 tag- Call: Scale Lookup
0x21d94: e0 05 8c b8 ld24 r0,#0x58cb8 tag- Tabl: Boost Target Error based Timing tabl_0x58cb8
0x21d98: fe 00 b1 04 bl 0x4e1a8 tag- Call: Table Lookup
0x21d9c: 11 80 10 88 mv r1,r0 -> mv r0,r8 tag- : Put TABLE RESULT into r1, then put ORIG ARG in r0
0x21da0: 40 ec f0 00 addi r0,#-20 || nop tag- : Subtract 20 from r0 (ORIG ARG... load)
0x21da4: fe 00 b1 d7 bl 0x4e500 tag- Call: subr_subtract_r1_from_r0 (ie. TABLE RESULT from ORIG ARG)
0x21da8: 19 80 49 14 mv r9,r0 -> addi r9,#20 tag- : Put "ORIG ARG - TABLE RESULT" into r9
0x21dac: 81 c9 ff ff and3 r1,r9,#0xffff tag- : Put r9 into r1, limited to 0xffff
0x21db0: 0a 51 7d 02 cmpu r10,r1 -> bnc 0x21db8 tag- : if r10 (ORIG ARG) >= r1, Jump to 0x21db8
0x21db4: 10 8a 7f 03 mv r0,r10 -> bra 0x21dc0 tag- : Return value ORIG ARG
0x21db8: 10 89 7f 02 mv r0,r9 -> bra 0x21dc0 tag- : Return value ORIG ARG - TABLE RESULT
0x21dbc: 10 88 f0 00 mv r0,r8 || nop tag- : Return value ORIG ARG
0x21dc0: 28 ef 29 ef ld r8,@sp+ -> ld r9,@sp+
0x21dc4: 2a ef 2e ef ld r10,@sp+ -> ld lr,@sp+
0x21dc8: 1f ce f0 00 jmp lr || nop tag- Retn:--------------------------------------
But I still think it's neat.
Rich
Jul 27, 2011, 05:34 PM
#24
Evolved Member
Thread Starter
This odd table is looked up when a certain variable is non-zero (haven't logged that one yet in gear vs. upshift to see if it's related).
The result of this table is bundled up into what seems to be a timing "subtractor". Note that this table is separate from the Timing Reduction vs. Load/RPM table - that's somewhere else.
The one above is interesting in that its cells are 0 or 1 at/above load 160. That would tie in with what I've seen - timing on part throttle upshifts track the Lower Boundary, but WOT upshifts retain full-noise timing.
Rich
Jul 31, 2011, 07:44 AM
#28
Evolved Member
Thread Starter
Yee har... direct psi-based boost control, applied to AUDM/EDM Ralliart ROM 53610010, tested and working...
Next, I'll give that Over-Boost Timing Retard mechanism a whirl - I've patched that subroutine for psi-based boost control too.
I reckon that'll be quite useful for WOT SST upshifts, as boost gets bumped up for a brief period... as per the above graph. If the ECU decides to leave timing running off the main map (ie. not falling back to Lower Bound Spark Map), it can knock.
Worth a shot, anyway...
Rich
Next, I'll give that Over-Boost Timing Retard mechanism a whirl - I've patched that subroutine for psi-based boost control too.
I reckon that'll be quite useful for WOT SST upshifts, as boost gets bumped up for a brief period... as per the above graph. If the ECU decides to leave timing running off the main map (ie. not falling back to Lower Bound Spark Map), it can knock.
Worth a shot, anyway...
Rich
Aug 1, 2011, 07:43 AM
#29
Evolved Member
Thread Starter
I've now tried out the Over-Boost Timing Retard mechanisim. Seems to work!
My test settings (in "Direct psi-based" boost control mode)...
Logged results...
When boost went above target after SST upshift, logged timing was briefly 2 degrees more retarded than the High Octane Spark Map at that rpm/load point.
I hope that'll keep the knock at bay during SST upshifts. My ECU doesn't seem to drop back to the lower boundary spark map at wide-open throttle when upshifting. So this OBTR table is a very useful feature indeed.
Rich
My test settings (in "Direct psi-based" boost control mode)...
Logged results...
When boost went above target after SST upshift, logged timing was briefly 2 degrees more retarded than the High Octane Spark Map at that rpm/load point.
I hope that'll keep the knock at bay during SST upshifts. My ECU doesn't seem to drop back to the lower boundary spark map at wide-open throttle when upshifting. So this OBTR table is a very useful feature indeed.
Rich