Toyota GR86, 86, FR-S and Subaru BRZ Forum & Owners Community - FT86CLUB - Gear Determination Thresholds for ZA1JK00G

- Software Tuning (https://www.ft86club.com/forums/forumdisplay.php?f=88)

- - Gear Determination Thresholds for ZA1JK00G (https://www.ft86club.com/forums/showthread.php?t=155091)

Gear Determination Thresholds for ZA1JK00G

Have been recently trying out Ghidra which I am attempting to define the gear determination thresholds for K00G.This is not defined in open source as far as I'm aware of.

Attaching the definition if anyone would like to test it. I am using the OFT v4.03 definition, but should work fine with a stock K00G ROM.

This is untested, so please use at your own risk.

There are three sets of values:

For A and B you should be using the same values for the internal A and B cells. Those values point to only a single function, a pointer and nowhere else. For the C and D tables those locations are not even referenced anywhere at all.

To change the value, divide the values from tables A and C by 4.1 and multiply with your intended ratio. Those values should be replicated to tables B and D as well.

https://i.imgur.com/ltjsRwc.png

I can validate this - thanks for posting it! I hadn't looked into any of this since I began. Opened up K00G and after an afternoon of study, your read looks valid.

It looks like in S10C the unused C/D tables are gone and the A/B tables are simplified to only have 5 elements instead of 10; the associated switching logic that hinged on K00G:0xFFF88D8E is removed, though the ECU still calculates and records it at S10C:0xFFF88BF2; nothing seems to refer to it anymore, though. Interestingly, the A/B and C/D tables seem to differ by almost exactly the ratio of 4.1:4.33, but I can't see what controls the switching between them.

I did some experimentation and, if you rephrase Gear Determ Thres A/B/C/D as 3D tables with sizex=2/2/1/1 sizey=5, RomRaider can display those tables more compactly without altering the address locations:

Code:

        <table type="3D" name="Gear Determination Thresholds A" category="Miscellaneous - Thresholds" storagetype="float" endian="little" sizey="5" sizex="2" userlevel="4">

            <scaling units="Rev/Mile" expression="96560.6/x" to_byte="96560.6/x" format="0.00" fineincrement="50" coarseincrement="100" />

            <table type="Static X Axis" name="Table" sizex="2">

                <data> Side 1 </data>

                <data> Side 2 </data>

            </table>

            <table type="Static Y Axis" name="Gear Thresholds" sizey="5">

                <data> Min 1st Gear / Max 2nd Gear </data>

                <data> Min 2nd Gear / Max 3rd Gear </data>

                <data> Min 3rd Gear / Max 4th Gear </data>

                <data> Min 4th Gear / Max 5th Gear </data>

                <data> Min 5th Gear / Max 6th Gear </data>

             </table>

I also noticed that, in theory, there's an RPM adjustment factor in the code (it defaults to 1.0 so Ghidra hides it in the decompiler), that lets you globally divide the RPM used in the calculation by a given factor, in both K00G and S10C, without having to edit the data tables; if you put in (new FD / stock FD) into that float, it might autoscale the tables without having to make further edits. K00G:0x5000A / K00G:0x5006A divide the RPM by float:0x104570 / float:0x104574, in case you want to experiment. (Still present in S10C!)

Also - congratulations on the Ghidra progress!!

Quote:

Originally Posted by callisto (Post 3609861)

Code:

        <table type="3D" name="Gear Determination Thresholds A" category="Miscellaneous - Thresholds" storagetype="float" endian="little" sizey="5" sizex="2" userlevel="4">

            <scaling units="Rev/Mile" expression="96560.6/x" to_byte="96560.6/x" format="0.00" fineincrement="50" coarseincrement="100" />

            <table type="Static X Axis" name="Table" sizex="2">

                <data> Side 1 </data>

                <data> Side 2 </data>

            </table>

            <table type="Static Y Axis" name="Gear Thresholds" sizey="5">

                <data> Min 1st Gear / Max 2nd Gear </data>

                <data> Min 2nd Gear / Max 3rd Gear </data>

                <data> Min 3rd Gear / Max 4th Gear </data>

                <data> Min 4th Gear / Max 5th Gear </data>

                <data> Min 5th Gear / Max 6th Gear </data>

             </table>

Thanks on the 3D table tip - wasn't aware that it could be done that way :)

On the ratio adjustment, that's a great idea as well though I still can't figure out on why there would be two ratio sets but then again, I suppose that's all from an RE standpoint which can be done - which is to infer.

Regarding Ghidra - thanks, and to you as well :) I'm honestly quite surprised how seemingly fast people pick up what the function(s) are trying to do and/or achieve... or I must be going round the long way. I got lucky that this example is simple in particular (the ratio values are the same in A01G so all I had to do was search for it in K00G) but I'm having trouble with several other use cases where I have no lead or hint to start from.

My next case I'm working on is a bit more open - in A01G, I'm trying to find if there is a value in RAM that indicates when tip-in fuel enrichment is active. What I'm doing right now is manually remapping backwards regions of the ROM/RAM from the definitions and the logcfg files to give me a better idea on what is being referenced in the decompiler, but there are still quite a number of RAM addresses to figure out from if any are doing what I'm looking for.

Any hints on getting more done and faster in Ghidra would certainly be appreciated!

You’re taking the route I did and I haven’t found better yet. The original crew knew how to find the OBD hooks in Subaru code, I think? But I’ve made no progress finding those yet in order to have a second way.

Quote:

Originally Posted by callisto (Post 3609880)

What I understand is that there are Mode21 PIDs (OBD2 PIDs but specifically used by Toyota/Subaru) which requests a byte value (or several) in which that reference can be used to find where that value is located in RAM. So instead of going around deducing the RAM address for oil temperature you can use the oil temperature PID to point you there.

Yeah. The part I want to find is where it handles Mode 21 requests. But I have to learn a lot more about OBD protocol, I suspect. It’s a multi-year quest for sure.

Quote:

Originally Posted by Compelica (Post 3609883)

What I understand is that there are Mode21 PIDs (OBD2 PIDs but specifically used by Toyota/Subaru) which requests a byte value (or several) in which that reference can be used find where that value is located in RAM. So instead of going around deducing the RAM address for oil temperature you can use the oil temperature PID to point you there.

By the way - I found a pathway into this sort of thing, except through CAN bus rather than in OBD2 pids. The old long-ago Subaru tuning folks from the 00's used the OBD and CAN entries to understand their ECUs in the first place and while I still haven't solved Mode21 yet, the CAN hooks may still be quite helpful to you.

Search for 00 00 01 42 FF F8 and you'll have the lookup table address for CAN id 0x142 and its FFF8xxxx memory pointer; then, search for pointers to the result location (i.e. S10C @cd94- 00 00 01 42 FF F8 89 A0, so search for cd94 and FFF889A0) to expand inward from there. Notably, only some of the CAN query IDs have their own dedicated send routine; the rest are using an indirect calculated lookup that I haven't solved yet. At the end of the 32-item array of "12 bytes about CAN ids", there'll be a 32-item array of pointers back to those exact arrays, with a lot more code references revealed. See also:

https://github.com/timurrrr/ft86/blo...an_bus/gen1.md