RomRaider

0x2DD04 = SSM LUT I think. It seems to be a bunch of addresses, and makes more sense than the other address mentioned. Only thing is, the addresses it gives me don't seem to be set to anything I know in the logic. Meaning, using the equation you gave, I will get an address. So I search for that address, and nowhere does it seem to get set to a familiar RAM address. It gets set to a RAM address, just not one that I know. Yet I searched for ECT, and I am confident that I have the correct RAM address for ECT.

I finally was able to figure out what you were talking about when I searched for the address of the ecu ID in a hex editor as opposed to in IDA View.

Andy

Got it! Man that is confusing!

For anyone reading that wants to learn how to find the SSM table, first you need to find the ecu ID. Best bet is to search for it in a hex editor(or the hex window in IDA). From there, you need to search for the address that the ecu ID was at, again, use a hex editor(or the hex window in IDA). The ecu ID I was working on was 3D04EA4605, and I found it at 0x2B163 through 0x2B167, it's 5 bytes long. I found it located at 0x2DD05(02) 0x2DD06(B1) and 0x2DD07(63). The ecu ID is the 5th-7th byte of the table, so go back 5 to 0x2DD00 and that is the start of the SSM LUT. You should notice a pattern now, and it helps! You can either count down every 4 bytes to whatever address you're looking for(according to the ssm.pdf) or you can use merchgod's formula (SSM LUT Start + (0x4*parameter)) to get the address. You'll see that it has an address stored over 3 bytes and surrounded by 0's. If you're using IDA you'll want to search for the last 2 bytes of that address(exclude the beginning 2) and eventually you'll find where it is loaded and stored to a different location. That different location is the RAM address for whatever parameter you were looking at.

Hope this helps someone in the future!

Andy

there you go.

With regards to the 32-bit ECU, the concept is the same except that it points to the function that returns the parameter's value.

Haha you gave us enough hints just making sense of it all was a bit tricky.

When the function calls load acc. D with #0A0h then multiply d*e - given E is a set address with a variable value - is D going to be the decimal value of #0A0h?? Or a location??

post the code

sub_19C04
ldd 836h, Z
lde #0FAh <---- In Question...
jsr sub_19A66
stab 0D22h, Z
rts

or
17 EA 0D 22


So does e= the given hex value in decimal? or 2-hex value into e?

-Jerod

e = 0x00FA in this example.

how to distinguish if it wants a decimal value (or well hex) or address?

-Jerod

I think what you're asking is if there is an extension applied like there is with say 0FB, Z. From my understanding, all addresses in this processor are 20 bits long, so yes there would be. I believe it is the yk extension register. Right Bill?

Andy

No, that is only for the index registers. Do you have a copy of the software manual? I would highly recommend that you do:

I do, I just don't have it memorized haha! Makes sense though, thanks!

Andy

Anyone have any idea of what the ecu would reference other than throttle voltage.

IE: If clear use throttle voltage - if not clear use byte xxx - its used everywhere and is always used IF not clear otherwise it uses throttle voltage.

Any ideas??

-Jerod

Couple of questions to add to Jerod's post, as I am interested in that as well.

1. Is there some secret to figuring out what certain "switches" or bit-checks do? Following them around and seeing what sets or clears them works great if enough of the logic is defined, but sometimes I come across one that it would be very helpful to know what it does, however I don't know what any of the logic it's used in does. I have been having Jerod log some of them to see when they change and trying to figure out what it's changing with, but this doesn't always work either. I have traced every SSM switch back and none of them do anything with some of them either.

2. The physical '02/'03 ecu supports more switches than the group-n ecu did apparently. Since the ecu supports them, would there be any negative effects of changing the code to reflect them being supported? For instance, switch 0x121 I believe is the clutch switch, accelerator switch, brake switch, and some other stuff, but it's "not supported" so those switches never work. I haven't come across anywhere where they would be needed, but I don't think it would be too hard to change the code if I ever did find somewhere that they are.

3. We are having difficulty calculating the proper expression for something, as it's never been defined before. Is there an equation to calculate the expression to be used? I noticed in an old post on openecu that Bill was using XMLWRITE to calculate an expression for 8bit throttle. Is this something I should use?

Thanks!

Andy

Well, if there was a means of easily figuring out everything, then there would be no work to do. You would simply be able to describe everything and every piece of logic. The puzzle analogy fits well here. Your question is like asking, "I have this jig-saw puzzle which represents a picture of the mountain range with a lot of blue sky. Well, I have these pieces that are entirely blue sky. Is there way I can quickly figure out exactly where these piece go? I haven't placed any other pieces even remotely around that area."


Well, there's no clutch switch for the 16-bit ECU. I don't remember if there's a brake switch input to the ECU, but it would pointless to try to define these for SSM logging purposes.


See the answer to #1.

Back in the dark ages when no one knew anything about the Subaru ECUs, someone came up with a utility called XMLWRITE that defined tables for a number of ECUs. After a period of time, it was discovered that this person actually hacked Ecutek software and generated this utility using their defs (this is not something they claimed when they created it - just that they had found a way to define a number of tables). Eventually we decided to disallow any discussion or posting of xmlwrite or xmlwrite defs at the RomRaider site (this was back in like early 2007) and this continues to this day for obvious reasons.

If you don't know what the real-world conversion of a particular value is, then you do not know enough about the logic surrounding that value to be able to accurately define it for tuning. There is not a magical formula for determining one. There may not even be a real-world conversion for some values.

I'm having a very hard time figuring out how the CEL table and logic works. I have seen the fix talked about with the "05 00 00" but with the Group-N ROM this doesn't seem to fix certain CEL's for people. I would really like to look into it more and learn how it all works.

I know the location of the table, but how is it referenced?
I am not sure on the logic, though, I have a few subroutines marked that I think it might possibly be.

If anyone could shed some light on this I'd greatly appreciate it!

Andy