ROM Table Discovery & Definitions
 

Seeing as there isn't a specific thread for this I thought I'd start one rather than tagging it in the middle of the Tactrix threads.

I decided to try WinOLS with some success, however I was wondering if those with IDA could look through and determine if these tables are of any use and what they do.

It seems that WinOLS is fairly good at determining the actual tables and has a go at formulating the expressions, as well as allowing you to view them in a table or 3D format you would be familiar with.

Below are the 10 largest tables that are not yet defined, on my definition at least, for ZA1JA02G. I haven't looked at the A01G but so far the 2 are the same.

@Td-d
@ztan

I'll post the same over on Romraider to see if they can be of any assistance.

Addresses:
Table Data:

I'll have a look in IDA.
Last tried to use WinOLS in 2006...

Unpicking "Alpha 1":

From addresses given:
Following the xref from the x-axis (RPM) to B2EF8:

Following the xref from the table definition to 4FFD2:

We find the x-axis is RPM, y-axis is Throttle, value pulled from the table is stored in FFF89B8C (I don't know what this is yet).

*Thanks, I've updated the code. I figured it would be something like that as the table looks like this:
https://dl.dropboxusercontent.com/u/...lub/Alpha1.jpg

Seems to have higher numbers in the lower torque areas.

As more are found I'll update the 1st post.

Some more ;)

Addresses:

Data:

Rather than just picking random tables I have been overlooking the entire ROM, I found these 4 2D tables all in the same portion of the hex dump. They seem to correspond to RPM so I wonder if these are cylinder comp tables of some sort. When viewed as a chart they vary quite a bit.

i dont know what it is but i wanna learn all about it

i need help here

i tried find FFF106FF0

it is same but not analyze

Go to >Options>Setup data types (Alt-D)
An option box will come up with data type rotations that you want included in the data carousel - check "float". Pressing "d" in IDA will change the data type.

To change the line of numbers into an array, press "*" and enter the length of the array.

So this data is available on the CANBUS:
http://www.ft86club.com/forums/showthread.php?t=91170

I want it on my Tactrix. How do we go about getting it?

you would need to either sniff the can buss to get the data or get someone to trawl the ecu code to see if its stored in ecu ram addresses.

I suspect what the oft guys did was aquired a device that performes those read functions then sniffed the can buss data requests and coppied requests into oft.

We could do similarly by copying the OFT requests. I don't like that, though. I don't think that's a very ethical way of accomplishing it.

Vishnu, EcuTek have all got their parameters by either disassembling the ROM or sniffing the CAN bus. Ethical would be buying the info from Toyota or Subaru, but they aren't selling.

I had a look at this briefly a couple of years ago, sniffing Techstream requests on CAN:

http://www.romraider.com/forum/viewt...8475&start=296

That thread actually had this a few posts from where you linked in:

Ja. The initial post was the raw data that I was seeing intially over CAN, the second post was what I had cleaned up after having a bit of time to fiddle with the CAN bus over the weekend, setting Techstream to log one parameter at a time whilst sniffing the bus.

I couldn't find a Techstream parameter for IAM anywhere, so I figured that it was likely not easily available on the CAN bus.

Did you ever get the VSC logging with the openport 2.0? I'm having trouble deciphering how to get those addresses into a logcfg.txt

No. I asked Mike and Colby a couple of years ago and again more recently.
The OP2 is configured to send its requests to 07E0 (ECU), not 07B0 (VSC). I think to get control of that, we'd need to get a firmware rewrite from Colby.

I think we would have much better CANbus access to all modules at the moment using an Arduino and CANbus shield; I haven't the time to crack it at the moment.

This CANbus talk is getting a bit off topic, but if anyone can point to where the ECU interfaces with the VSC unit; and if the VSC data is put in RAM on the ECU, we can pull the data straight off the ECU with the OP2.

I apologize for dragging the conversation in the wrong direction. I agree on the arduino, and am in the process of doing that.
I'm eager to hear if this is in RAM in the ECU anywhere.

Sent from my XT1045 using Tapatalk

<Off topic> Examples of CAN requests to ECU using Drew Tech Canbus tools:

Engine on idle, requesting MAF data

OBD Mode 01:
Send:
00 00 07 e0 01 10 (mode 01, PID 10)
Response:
00 00 07 e8 41 10 03 b8 (repsonse 41 (01+40), PID 10, Data 03 B8 (7.68 g/s)

OBD Mode 23:
Send:
00 00 07 e0 23 14 ff f8 7c 70 04 (mode 23, 14:?number of parameters + data length, RAM address FFF87C70, 04:?bytes expected)
Response:
00 00 07 e8 63 41 15 e6 66 (response 63 (23+40), data 4115e666 (IEEE 754 float = 9.37 g/s)

Anyone have any idea what this (FFF884F4 for A01G) may be? I was looking at how data calls are made to get 16 bit sensor data and this one came up: a voltage value gets read from the 16 bit routine and then scaled by a table (defined at 0B1FA8) which reads like a temperature scale; 100 to -40 in 10 degree increments.

Does not match with any other temperature sensors that I log.

Not much help with yours @ztan but more of a question for those who are good at discovery.

Been trying to work out why the throttle closes under WOT and am doing some digging around. I don't suppose anyone fancies digging into the throttle angle routines. It's definitely nothing to do with requested angle, however there must be something that causes this. It seems fairly uniform between FI and NA cars too. I've tried testing Requested torque and calculated tq tables but nothing there has yet made any difference.

Rev limit code
 

Shiv asked me to look at an RPM limit problem under boost and there is something interesting in the code worth noting:

Rev Limit A and B have their cut and resume values in different directions (see disassembly pic). No reason for the engineers to do this and Rev Limit B works without hysteresis in the stock ROM which is has 7400 as the first (resume) value and 7200 as the second (cut).

A01G def: