RomRaider

Hello all!

So while I'm really good with data and cross referencing, coding is not my strong spot. So while SH7058 has been noob friendly for verifying maps and axis', it has not been the same with RAM address bit masks. So while a lot of RAM addresses are set, some have bit masks that allow multiple things to inherit the same RAM address. So I think a bit mask is just filtering data or something. But how do you actually identify which bit mask the function is referring to when it calls a RAM address? I'll leave this code below as an example.

**************************************************************
* FUNCTION *
**************************************************************
undefined FUN_0007fdc8()
undefined r0:1 <RETURN>
undefined4 Stack[-0x4]:4 local_4 XREF[1]: 0007fdc8(*)
FUN_0007fdc8 XREF[1]: FUN_0007fe6a:0007fe6c(c)
0007fdc8 4f 13 stc.l GBR,@-r15=>local_4
0007fdca d0 2b mov.l DAT_0007fe78,r0 = FFFF427Bh
0007fdcc 40 1e ldc r0,GBR
0007fdce c4 84 mov.b @(0x84,GBR)=>DAT_ffff42ff,r0
0007fdd0 d6 2a mov.l DAT_0007fe7c,r6 = FFFF24D4h
0007fdd2 61 03 mov r0,r1
0007fdd4 84 64 mov.b @(0x4,r6)=>DAT_ffff24d8,r0
0007fdd6 c8 20 tst #0x20,r0
0007fdd8 89 10 bt LAB_0007fdfc
0007fdda c4 c7 mov.b @(0xc7,GBR)=>DAT_ffff4342,r0
0007fddc c8 20 tst #0x20,r0
0007fdde 8f 0d bf/s LAB_0007fdfc
0007fde0 66 03 _mov r0,r6
0007fde2 d5 27 mov.l DAT_0007fe80,r5 = FFFF49C6h
0007fde4 84 54 mov.b @(0x4,r5)=>DAT_ffff49ca,r0
0007fde6 c8 02 tst #0x2,r0
0007fde8 8b 08 bf LAB_0007fdfc
0007fdea 84 51 mov.b @(0x1,r5)=>DAT_ffff49c7,r0
0007fdec c8 02 tst #0x2,r0
0007fdee 8b 05 bf LAB_0007fdfc
0007fdf0 60 63 mov r6,r0
0007fdf2 c8 08 tst #0x8,r0
0007fdf4 89 02 bt LAB_0007fdfc
0007fdf6 60 13 mov r1,r0
0007fdf8 a0 02 bra LAB_0007fe00
0007fdfa cb 20 _or #0x20,r0

So with 0xFF49C7, it has multiple RAM functions stored in that RAM address. So my thinking is that you have to rely on the tst functions. So tst 0x2 would be getting the reading at bitmask 0x0002 and tst 0x8 would be getting the reading at bitmask 0x0008. Is it right to interpret 0x2 as bitmask 0x0002 and not bitmask 0x0020?

Also, I have noticed that not every RAM address has a tst code. Most actually don't have this. But I'm guessing that's because they don't have multiple RAM functions stored in that single address. Lastly, how would this transfer to the logger defs? I see code for "ecubyteindex" and "ecubit" but not sure how that would to bitmask code from the A2L, or if that even would relate to ECUID specific bitmask RAM addresses.

It would make complete sense to me for the bit mask stuff to act as a filter, hence why the RAM address will be called and then tested to filter the data. But after learning that VOID functions actually will typically mean active, I don't want to take my chances haha

I think you're at the point where you'll have no choice but to learn some of the SH instruction set. Start with
https://www.renesas.com/en-us/doc/produ ... sh7058.pdf , skim over chapter 2.
Then, http://documentation.renesas.com/doc/pr ... h_2esm.pdf , go see what it says for tst.

The rest is mostly being very familiar with bites, bits and boolean operations. If not, I'm not sure what to suggest, maybe http://faculty.etsu.edu/tarnoff/ntes215 ... itwise.htm


Say rather, the byte at 0xFFFF49C7 has eight bits, some of which are used as a binary flags. Tst is one way of checking individual bits; i.e. the leftmost bit (#7) would be tested with tst 0x80, Rn.


That's not quite how it works. When it says void inside the argument list it only means that the function is called without arguments, as far as ghidra was able to tell. When there are arguments, they're typically passed in through registers R4, then R5,R6,R7 as needed.
What I was saying was: if ghidra identified a function, regardless of the argument list, that function is probably called, unless the caller(s) skip that call after checking a flag. It's very difficult to be certain of anything – this is the nature of RE.

And actually for once wikipedia https://en.wikipedia.org/wiki/Mask_(computing) is pretty readable. Just the first few parts are relevant here.

Fudge. Thank you so much for providing all those resources! I have an instruction set bookmarked that I’ve been using for a bit, but i need all the information I can get. I definitely do lack the basic understanding of coding as a whole so I’m quite a bit behind a lot of you all haha But hey, ahead in the data game (Sheerly due to the fact that I actually had a reason to do so as well as the time to spend on it lol )

Okay so VOID calls are decompiler related. In the sense that it’s the decompiler helping visualize the data in a sense. I’m definitely getting a better idea of all of it in my head thanks to you explaining it haha That’s the most frustrating part about all of this. With data and everything else car related, I’ve been able to visualize things very easily and it just made sense. With code, it just feels like I can never even understand it to begin with, let alone analyze it haha But I’ve made quite a bit of progress from where I once was!

<table type="BitwiseSwitch" name="Template" category="Flags">
0x80 <bit position ="7" name="-"/>
0x40 <bit position ="6" name="-"/>
0x20 <bit position ="5" name="-"/>
0x10 <bit position ="4" name="-"/>
0x08 <bit position ="3" name="-"/>
0x04 <bit position ="2" name="-"/>
0x02 <bit position ="1" name="-"/>
0x01 <bit position ="0" name="-"/>
<description>Toggle</description>
</table>

For anyone wondering what bit position bitmasks refer to. Grabbed it from some old forum post.

/begin CHARACTERISTIC mPTDSW
"PTD specifications choice SW mPTDSW"
VALUE 0x0000898F REC_UBYTE_C 0 COMP_0283 0 255
/end CHARACTERISTIC

/begin CHARACTERISTIC mfTTE_ON
"0: Torque TTE control disabled (TATE=APP0) 1: Torque TTE control enabled (TATE← TTEPTD)"
VALUE 0x0000898F REC_UBYTE_C 0 COMP_0283 0 1 BIT_MASK 0x0040
/end CHARACTERISTIC

/begin CHARACTERISTIC mfTFD_ON
"0: Drive-force TFD control disabled (TTEPDT=TTEAP0) 1: Drive-force TFD control enabled ( TATE←TTEPTD)"
VALUE 0x0000898F REC_UBYTE_C 0 COMP_0283 0 1 BIT_MASK 0x0020
/end CHARACTERISTIC

/begin CHARACTERISTIC mfTFDCVT
"0:TFD0 to CVT 1:TFDD to CVT."
VALUE 0x0000898F REC_UBYTE_C 0 COMP_0283 0 1 BIT_MASK 0x0004
/end CHARACTERISTIC

/begin CHARACTERISTIC mfCVTFL_ON
"0:CVTFAIL flag disabled, 1:CVTFAIL flag enabled."
VALUE 0x0000898F REC_UBYTE_C 0 COMP_0283 0 1 BIT_MASK 0x0002
/end CHARACTERISTIC

/begin CHARACTERISTIC mfPTD_ON
"0:drive power demand control OFF 1:drive power demand control ON"
VALUE 0x0000898F REC_UBYTE_C 0 COMP_0283 0 1 BIT_MASK 0x0001
/end CHARACTERISTIC

/begin CHARACTERISTIC mPTDSW2
"TD related control choice SW inclusion byte mPTDSW2"
VALUE 0x00008990 REC_UBYTE_C 0 COMP_0283 0 255
/end CHARACTERISTIC

/begin CHARACTERISTIC mfITOHOSON
"0: Intentional control off 1: Intentional control on."
VALUE 0x00008990 REC_UBYTE_C 0 COMP_0283 0 1 BIT_MASK 0x0080
/end CHARACTERISTIC

/begin CHARACTERISTIC mfJERKON
"0: no jerk control, 1: jerk control, yes."
VALUE 0x00008990 REC_UBYTE_C 0 COMP_0283 0 1 BIT_MASK 0x0040
/end CHARACTERISTIC

/begin CHARACTERISTIC mfFNETQHOS
"0: no RPM torque compensation, 1: RPM torque compensation."
VALUE 0x00008990 REC_UBYTE_C 0 COMP_0283 0 1 BIT_MASK 0x0020
/end CHARACTERISTIC

/begin CHARACTERISTIC mfFHHTQHOS
"0: no upland/thermal compensation control, 1: upland/thermal compensation control."
VALUE 0x00008990 REC_UBYTE_C 0 COMP_0283 0 1 BIT_MASK 0x0010
/end CHARACTERISTIC

/begin CHARACTERISTIC mfTRLNON
"0: no accelerated linearity control on treadmill 1: accelerated linearity control on treadmill."
VALUE 0x00008990 REC_UBYTE_C 0 COMP_0283 0 1 BIT_MASK 0x0008
/end CHARACTERISTIC


/begin CHARACTERISTIC mfFSPTFAC
"0: Intentional detection control tuning OFF 1: Intentional detection control tuning ON"
VALUE 0x00008990 REC_UBYTE_C 0 COMP_0283 0 1 BIT_MASK 0x0004
/end CHARACTERISTIC

/begin CHARACTERISTIC mfFZADDFD
"0:Regional attribute response control OFF 1:Regional attribute response control ON"
VALUE 0x00008990 REC_UBYTE_C 0 COMP_0283 0 1 BIT_MASK 0x0002
/end CHARACTERISTIC

/begin CHARACTERISTIC mfFADDFD
"0: Travel resistance compatible control OFF 1: Travel resistance compatible control ON"
VALUE 0x00008990 REC_UBYTE_C 0 COMP_0283 0 1 BIT_MASK 0x0001
/end CHARACTERISTIC

Thanks once again, Pirelli! What's weird is some of those aren't showing up in the A2L as well as the definitions being worded differently. Are you using a different A2L than ZB060?