RomRaider

Hi guys,

So as some of you may have noticed, I am slowly trying to pick up reverse engineering skills. I was able to get some of the stuff that I needed for my own purpose done but I recently had someone ask me to see if I could take a look at inverting the polarity of the neutral position switch on a specific JDM ECU because, apparently, some transmissions have it reversed. Anyway, I figured, maybe I can do this ...

First thing I realized is that the CAL ID the person is looking at using is a 16 bit rom ... I have only so far played with the sh7058 so that took me back a few steps. Anyhow, my plan was to trace back the IO location for that sensor through the SSM functions. Using Dshultz scripts and documantation (you rock dude), I was able to figure out I think where the function I am interested in is located namely

PtrSSM_switches_4_5_x_6...



I assume this points out to a ram variable where the switch state is stored ?

If my assumption is correct, I tried to locate where in the code that ram variable is set and I found this section, looking at the logic, seems to make sense



So the information that I would be after would be this :

Neutral position switch is switch 4, its either the MSB or LSB assuming MSB



I am still not 100% on how the addressing on the 16 bit ECU work and I would like someone to explain me what 0x0F9 resolves to ? Another RAM variable, a GPI ??? I'll spend more time looking at the CPU documentation but maybe some quick guidance would make alot of difference for me.

Could anybody, sorta peer review my thought process and give me a pointer as to how to resolve the 0x0F9 address ?

Thanks !

Assuming I am not wrong in my previous assumption, looks like 00F9 is another ram variable which is set sepending on what's at 0x0898 bit 1 ...

Do we have a part number/spec of the processor that is being used on the 16 bit, I am using a generic M68H16 datasheet to figure out what the instruction are but it would be nice to see how the IO are mapped on that particular chip ? From quickly reading a dshultz post, looks like address are dependent on some register settings, I am not taking any of that into account right now so I could be looking at completely the wrong thing ...

Thanks

Seems like this has been done numorous times. I'll check my thought process looking at those images

All references to RAM are indexed using X, Y, Z as the high nibble to the base word (20 bit addressing).
So in the case above the opcode above is to clr the bit in the byte stored at 0xZ00F9 using the bit mask 0x40 (i.e.: bit 6).
In all cases accessing RAM X, Y, Z will be 2.
Y is used 99% of the time to access Tables to lookup data.
Z is often used to emulate the SP when in certain subs.

If you right click on the operand 0x0F9 you can usually force the addition of the index register by selecting the appropriate Offset.
I made a script (Convert16bitOperand.idc) that you can tie to a function key in IDA that will do the hard work.

To find the switch real address work back through the SsmGet_Switches sub and locate: staa Ssm_Switches_4_5_x_6_7_8_9_x, Z
You want to find where it sets or clears bit 7 (0x80) and what triggers that.
Once you find that source trigger bit/byte, create an Enum and then you can go mark all the locations that use the same combination.

Thanks Dale, found your script and got it to work. I also found this thread and it confirmed that I wasn't super far from tracing it back

viewtopic.php?f=15&t=8540

After chasing a few variable down, I could locate the ram variable/logic that is mentioned in the thread above and stop there. But it seems to be another RAM variable that is affected by some other logic, I'd really like to trace this all
back to the IO port just to make me feel better about this (Not my car so I can't really run it an verify assumptions by logging ram variable).

The only logic that I could find that set this variable look like this (Variable is at 0x20893):



White the following subroutine in the middle



Could this be an IO subroutine ? Do we have a spec or part # for that CPU so I can get an IO of how IO interface work for this ECU. EDIT : Maybe these micro don't have GPIO and rely on external component attached to a BUS to perform those task.

Could could be heading into the wrong direction ...

Thanks

Just for completeness, I believe that what the thread I linked to is suggesting is to change the mask at 0x1c02 from 0xF7 to 0xF6 to invert the logic.


Now as I said, I'd still like to trace 0x20892 to the actual IO ...

It looks like you are on the right track.
The details of the CPU are scarce at best. You are looking for MC68HC16Y5TSJ_Rev1

Prior to that ram address there is a subroutine that pulls the data directly from the hardware. It's a separate memory section that is controlled by the tpu if I recall correctly.


Hardware access is usually done via the Y register offset

Ok perfect thanks guys, I'll ask the guy to log a few ram variable for me just to make sure that I am looking at the right thing.

That's way more fun than advanced sudoku puzzles