RomRaider

Ignition Timing is quite reasonable, include O2sensor voltage into your log.

Finally got the chance to do a run.

Two O2 sensor voltages, no. 2 is the rear sensor and is fed to the ECU via an emulator.

I notice the load, IPW, MAP(Boost in the log) and the O2 sensor voltage all start falling around 4600 rpm.

Seems strange.

This is not 02 sensor voltage.
Try another logging tool.

OK I will try during the week.....

I have tried several different ways of trying to log the O2 sensor voltage and nothing works.

Anyway I suspect the MAF calibration is out as the stock rom is not used to the extra air the 3.8Litre moves ? Who knows.

I am still learning the rom stuff and am gaining more understanding as I go on.

So in the below pics I am following the High octane fuel map back to the sub that uses the info from the map.

The part I cannot understand is where the register is(address) and how to follow the link the subroutine uses to write it...

pic one, my high octane fuel map starts at c181, so c17a to me would seem that is the reference subroutine 26778 looks for via address 11fa8.



Here is where I get really confused, 2681c loads a 24 bit value, branches and links to sub_4f7b0 and moves the register.... where it moves it to confuses me.


What do the numbers after the "sub_26778" mean ? eg. "sub_26778+94^j" ( the up arrow doesn't look like mine )

Address 0x011fa8 is part of a data structure.

I maybe easier to see what's taking place if you look at this view (press the spacebar to switch views in IDA)

The reference with the ^ is telling you from where in the ROM this address is referenced. In this case from sub_26778+94^ which is 94 bytes into sub 26778 which is before your current location.

Does your car have OBD? and maybe references to O2 voltage or corrections?

OK yes I do use the graph view, makes it easier to follow the path.

I am trying to work out the memory address the sub_routine writes to.

Most sub_routines write to and store in memory but I can't work out where.

If I could work that out I could then log the address via OBD

Did you investigate sub_4F7B0 ?

When I asked about OBD I meant true ODB-II system PIDs not specific RAM addresses with a non-ODB logger that you find. There maybe a number of O2 values available to you. These routines could also lead you to where the info is calculated and stored.

Thank you, now I see the links the arrows and numbers describe, makes following the path so much easier.

sub_4F7B0 seems to do its own thing yet branches off to several other subroutines that do the same......

Confused again...

I will try and follow the path again, I think I may be missing the reference to tables when looking at the subroutines.


No pid's for the Mitsubishi, they use the MUT3 diagnosis which is represented in each rom as a MUT table.
This table shows the command to read from a ram address but I am yet to figure out what info the addresses are linked to.

I had a MUT3 unit here for a while and used it but it didn't really tell me more than I already know with the Evocsan software.

I guess Mitsubishi don't want us to know or tune....

I have a Scangauge unit that will display lots of info, timing advance, throttle position, fuel consumption etc.
Their website lists some generic pid's to try and some of them work accurately, particularly the fuel trims.
It is customisable but I don't know how the unit converts the pid's to ECU commands, they are a series of numbers and don't seem to relate to addresses.

Here is the MUT table from my rom.

To my knowledge the ScanGuage uses ODB-II PIDs (J1979) to retrieve info. The parameters read are some of the ones I linked to in my earlier post.

You originally asked:The start address 0x011fa8 of the data structure is loaded to R0
Then the branch to sub_4f7b0, processes and returns with the result in R0 (I assume as I don't have it in front of me at the moment)
Upon return from sub_4f7b0 the return value in R0 is moved to R8 and processing continues at loc_26828.

Make sure you're running the latest version of IDA since Ilfak has fixed a lot of M32R problems in the processor module. I'm running 6.4.130306.

The 11FA8 section is a pointer list and the map selector byte decides which map it will use. This is how my original live tuning M32R patches worked.

You should also take your maps and set them up as array since it's much easier to deal with the data that way.



Also, take all the subs and variables you understand and try to name them appropriately. In that ROM FP is the general purpose pointer used to access RAM so everything will be offset according to its location 0x808000. When you understand what a bit does then use an enum to define it. See the attached capture from a fuel routine:



As you can see it is far more readable. I've obviously spent the last 6-7 years disassembling this stuff my list of files and routines is huge. I did the definition for your ROM a number of years ago so it is quite out of date.

-Michael

Michael,

Glad to here from you on this forum !
You were keeping silence for ages..

Been here since 2006 with only 1 post. I guess I am silent. Most of my time is spent in IDA anyway.

-Michael

Thanks heaps for all your help so far

I am still learning and still trying to get my head around how the ECU operates.

I don't have a lot of time to devote to this but grab a couple of hours whenever I can.

My Ida version is 6.1.0110409 , will look to updating it then, thanks Michael

Thanks again guys, I really appreciate the help and would have given up long ago without it......

You should be able to just use the updater thing on the hexrays site to get all the latest M32R fixes. Latest stuff Ilfak sent to me implemented proper detection of switch statements so it does a great job of fixing up those messy jumps. If your support contract has expired then I highly recommend renewing it.

-Michael