RomRaider

Ok, so I've followed this thread (How To: Define a New ROM from a previously defined ROM) and made it through the first 5 steps and learned a ton.
After doing it I would highly suggest following that thread to a "T" and using the scripts provided. The script files themselves have a better description of how they work than that thread, but I figured it out eventually.

Now that I have a mostly disassembled ROM I have something I would like to discover, but will need help getting there.

I would like to determine the ADC that corresponds to each sensor. Which dschultz did for a different ROM and posted it in the previously mentioned thread, but only provided a brief explanation of how he did it.

He references "The routine that moves the ADC registers to RAM" but I don't know how to go about finding that. I figured I would start with the Mass Airflow Volts as I would like to look into that further at a later time.

I figured I could work backwards from the "SsmGet_Mass_Airflow_Sensor_Voltage_P18". I saw in that SSM routine that it was loading the value from RAM:FFFF4024. Which I believe is the raw uint16 value.

I then looked at xref to that location to see if I could fine a reference that loaded a value to RAM:FFFF4024. There are 92 xref's to that location, but all of them appear to be reading the value, not loading it.

The only other thing I can think of is that when the location is loaded with the ADC value it could be using indirect addressing, but I'm just learning about that so I don't really know.

Any help is appreciated. I'm new to this so I may be making a mistake somewhere.

There are some tricks.
You may start to analize usage of the ADC registers. Moreover some chips are able to move ADC results directly to RAM thru DMA.
Or those values maybe copyed into RAM inside the cycle where just the first address of the data array is involved.

This^ You may peek at the hardware/software manuals and see if any of the addresses match up. I can't remember if they are hard coded or configured in firmware.. If it is hard coded and you can correspond the addresses to the ADC channel #.

When you follow the RAM references 'up' the chain and they stop (read only), you may have found the array, or as you mentioned, indirect addressing You can confirm this by looking at the other longwords in this area and following the references. You should eventually see references to MAP, IAT, and other sensors on the ADC if you're there.

I would start with something like battery volts and trace it up the chain and see what they have in common.

Ok,

I looked at the Manual before and saw this, but I guess I forgot to mention it.

https://www.dropbox.com/s/ssemaujdh8ymnir/ADC%20Registers.jpg

The addresses in that list are at higher addresses than what I expect to even be allowed. When adding the RAM section it was suggested to start at FFFF0000 with a length of 0000BFFF. And so the highest address in my disassembly is FFFFBFFF.

Maybe I am just ignorant, but that doesn't make sense to me.

If you create another segment for the high addresses that all the CPU peripherals live in you can then see references to them in code.
For the SH7058 make a segment from 0xFFFFD000 - 0xFFFFF87F
You will need the sh3.cfg file I created. Move it into the IDA config directory replacing the existing file if you have not done so yet. If you have a new version of IDA (6.4) this file is already included in the IDA distribution.
Once setup you will need to "Re-Analyze" so IDA can map the addresses to the register names.

To find the routine that reads the ADC look for the ADC control register addresses referenced in code (F838 and F858). There will be a couple.
You are on the right track with 0xFFFF4024 as that is either the start of the ADC values in RAM or is within it.

Once the ADC is read to RAM, the RAM area is referenced and read into another section of RAM which makes two copies of ADC values in RAM. Some of the Sensor Scaling routines reference these RAM sections. So if you look at a temperature sensor scaling table and follow references back to code where it is used, you will see the RAM address referenced at the very beginning of the routine.


Indirect addressing is used extensively, so this makes finding all references to any RAM address a challenge.

Hex-Rays promised to work around to adding AREA directive for SH processor.
Who knows what the future holds.
This will help to assign applicable RAM and SFR area within sh3.cfg file.
Currently those segments should be added manually.

Thanks dschultz, I got that segment added now and will start looking at that.

I've also found an older thread that was helpful in explaining the CEL switch table and the example posted help me learn more about assembly language. (CEL routines in 32bit ECU explained)

Edit:

I am also not understanding td-d's post about resolving indirect addressing.



Can someone post a before and after example? I think that should clear it up for me.

You can also review the output generated by the MakeCELPointers.idc script to gain a bit more insight into the CEL table. Also look at the <dtcode> section of the latest logger.xml definition.


From the example above.
He says - copy the address loaded to gbr at the beginning of the routine, FFFF636C
Select the indirect reference - so select the operand of the opcode 'add'.
Press Crtl-R to bring up the edit window and paste the gbr address into the base field.

dschultz,

You worded it a little bit better, but I'm still not sure. I'll say what I am thinking and you let me know if I'm wrong.

I am thinking the code used to look like this:


And you select the "gbr" in the add line, then hit Ctrl-R and paste FFFF636C into the base field because we know gbr=FFFF636C from the previous lines.
Also check the box that says: treat the address as a plain number.

Bingo, that's exactly how. Worthwhile also ticking 'treat the base address as a plain number'.

I'm assuming you meant 0xFFFFD000 - 0xFFFFF87F. Just realized this when trying to start over to make sure I didn't screw anything up.

Oops, yes I missed a 0

Ok, so I think I found the ADC code, but I am trying to resolve the gbr indirect references and it is not formatting like I thought it would.

I also renamed the register locations so they would show up. Is there any reason that the .cfg file doesn't automatically format and rename the register locations?

Edit: Pretty sure I did something wrong. Will look at it again and post if I have any more problems.

sh3.cfg is used the first time you are loading the file.
After that changes inside .cfg are not applied to your project.

In order to implement your changes in .cfg file save the project into .idc script and download the your initial binary again and apply saved .idc after that.

Ok, I have determined a few questions while digging in the disassembly some more.

So it looks like the sh3.cfg file did work, but because I added the segment for the CPU peripherals after loading the file those addresses did not get named. I'm not sure if I'm missing something but when loading the file there is no way to define this location. So until Hex Rays does something we are going to have to name these addresses manually correct?

My next task for myself is to determine how r15 is used as the stack pointer when calling a subroutine and how it returns from the called sub.
I will explain where I am getting lost below.

Previously r14 is h'0 and r15 is h'FFFFBFA0


Now below is where I get lost.


Ok, so where I get lost is the beginning of sub_EE4 because I don't understand how @-r15 (@h'FFFFBF9F) can be overwritten when it was loaded in sub_762. How would it know where to return from sub_762?

The only explanation I can think of is that the SP (r15) is reduced or incremented with every jsr or rts instruction.