|
Bische
|
 |
« Reply #90 on: March 26, 2013, 11:45:21 AM »
|
|
|
I am defining the 8E0909518AK binary currently and got stuck on TEMIN/VA. I did load it up for disassembly to find the adresses and found something I would like to verify, here is the call for TEMIN/VA as it usually looks:  Here is it in the 518AK, TEMINVA lookup is a RAM location and TEMINVA is determined in another routine:  So according to my understanding, TEMINVA is a KL instead of a single and has tmot as axis? Here is how I defined it:  Here is a link to the .idb if anyone want to take a look: http://www.sendspace.com/file/fui178 |
|
|
|
|
Logged
|
|
|
|
jooo
Jr. Member
Karma: +0/-1
 Offline
Posts: 30
|
|
« Reply #91 on: March 29, 2013, 03:53:40 PM »
|
|
|
How are input/outputs on 2nd C167 addressed? I need to find such code to identify a map.
|
|
|
|
|
Logged
|
|
|
|
|
masterj
|
|
« Reply #92 on: March 30, 2013, 02:56:50 AM »
|
|
|
Can someone tell me how do you find out factor and offset of maps? Also need some info on workflow when address is not direct but through registers. Currentyl trying to find CWDMFAB map and in all bin files it was xrefed directly. Well my lucky bin was a little bit different and instead of direct xref I had to use regex to find reference to map. First I'll show usual bin: seg003:8C742 loc_88C742: ; CODE XREF: sub_88C672+52j
seg003:8C742 mov r12, #1D8Dh
seg003:8C746 mov r13, #206h
seg003:8C74A movbz r14, byte_380A46
seg003:8C74E calls 82h, sub_825C30
seg003:8C752 extp #0E1h, #1 ; 'ß'
seg003:8C756 movb byte_3848DD, rl4
seg003:8C75A movb [r0], unk_81150D ;<--- CWDMFAB
seg003:8C75E mov r4, [r0]
seg003:8C760 bmov word_FD8C.6, r4.0
seg003:8C764 bmov word_FD8C.7, r4.1
seg003:8C768 bmov word_FD8C.8, r4.2
seg003:8C76C bmov word_FD8C.9, r4.3
seg003:8C770 bmov word_FD8C.10, r4.4
seg003:8C774 bmov word_FD8C.11, r4.5
seg003:8C778 bmov word_FD8C.12, r4.6
seg003:8C77C bmov word_FD8C.13, r4.7
seg003:8C780 add r0, #2
seg003:8C782 mov r8, [r0+]
seg003:8C784 mov r9, [r0+]
Now in my bin I found it like this: seg003:8AEF0 loc_88AEF0: ; CODE XREF: sub_88AE20+52j
seg003:8AEF0 mov r12, #1FDEh
seg003:8AEF4 mov r13, #206h
seg003:8AEF8 movbz r14, tmot
seg003:8AEFC calls 83h, sub_833D44
seg003:8AF00 extp #0E1h, #1 ; 'ß'
seg003:8AF04 movb byte_3848D7, rl4
seg003:8AF08 movbz r4, byte_FA12
seg003:8AF0C movb rl5, [r4+63B8h] ; <--- [FA12 + 63B8h]
seg003:8AF10 movb [r0], rl5
seg003:8AF12 mov r4, [r0]
seg003:8AF14 bmov word_FD88.11, r4.0
seg003:8AF18 bmov word_FD88.12, r4.1
seg003:8AF1C bmov word_FD88.13, r4.2
seg003:8AF20 bmov word_FD88.14, r4.3
seg003:8AF24 bmov word_FD88.15, r4.4
seg003:8AF28 bmov word_FD8A.0, r4.5
seg003:8AF2C bmov word_FD8A.1, r4.6
seg003:8AF30 bmov word_FD8A.2, r4.7
seg003:8AF34 add r0, #2
seg003:8AF36 mov r8, [r0+]
seg003:8AF38 mov r9, [r0+]
seg003:8AF3A rets Next thing I did was xrefing byte_FA12 and looking for write. Found one @ 9F742: seg003:9F6D6 sub_89F6D6: ; CODE XREF: sub_89F514+1CP
seg003:9F6D6 mov [-r0], r9
seg003:9F6D8 mov [-r0], r6
seg003:9F6DA mov r9, r12
seg003:9F6DC mov r6, r9
seg003:9F6DE shl r6, #2
seg003:9F6E0 add r6, r9
seg003:9F6E2 shl r6, #1
seg003:9F6E4 extp #20Ah, #2
seg003:9F6E8 movb rl4, [r6+5A8h]
seg003:9F6EC nop
seg003:9F6EE movb byte_FA0E, rl4
seg003:9F6F2 extp #20Ah, #2
seg003:9F6F6 movb rl5, [r6+5A9h]
seg003:9F6FA nop
seg003:9F6FC movb byte_FA10, rl5
seg003:9F700 extp #20Ah, #2
seg003:9F704 movb rl3, [r6+5AAh]
seg003:9F708 nop
seg003:9F70A movb byte_FA0F, rl3
seg003:9F70E extp #20Ah, #2
seg003:9F712 movb rl2, [r6+5ABh]
seg003:9F716 nop
seg003:9F718 movb byte_FA0C, rl2
seg003:9F71C extp #20Ah, #2
seg003:9F720 movb rl1, [r6+5ACh]
seg003:9F724 nop
seg003:9F726 movb byte_FA0D, rl1
seg003:9F72A extp #20Ah, #2
seg003:9F72E movb rl4, [r6+5ADh]
seg003:9F732 nop
seg003:9F734 movb byte_FA11, rl4
seg003:9F738 extp #20Ah, #2
seg003:9F73C movb rl4, [r6+5AEh]
seg003:9F740 nop
seg003:9F742 movb byte_FA12, rl4; <-- found write! Great. More redirections...
seg003:9F746 calls 89h, sub_89F5E4
seg003:9F74A calls 89h, sub_89F5F4
seg003:9F74E calls 89h, sub_89F604
seg003:9F752 calls 89h, sub_89F612
seg003:9F756 calls 89h, sub_89F622
seg003:9F75A calls 89h, sub_89F632
seg003:9F75E calls 89h, sub_89F642
seg003:9F762 calls 89h, sub_89F652
seg003:9F766 calls 89h, sub_89F662
seg003:9F76A calls 89h, sub_89F670
seg003:9F76E calls 89h, sub_89F680
seg003:9F772 calls 89h, sub_89F690
seg003:9F776 calls 89h, sub_89F6A0
seg003:9F77A calls 89h, sub_89F6B0
seg003:9F77E mov r6, [r0+]
seg003:9F780 mov r9, [r0+]
seg003:9F782 rets Next thing was to notice how rl4 is set (lower byte of word @ r4, because of l right?) seg003:9F738 extp #20Ah, #2
seg003:9F73C movb rl4, [r6+5AEh] Now we go few lines up and see how r6 is set: seg003:9F6DA mov r9, r12
seg003:9F6DC mov r6, r9
seg003:9F6DE shl r6, #2
seg003:9F6E0 add r6, r9
seg003:9F6E2 shl r6, #1 Now here I do not understand why it is shifting values here... Can someone explain shl operation? For now I xref this subroutine (because r12 is from outside). seg003:9F526 extp #0E1h, #1 ; 'ß'
seg003:9F52A mov word_384C78, r8
seg003:9F52E mov r12, r9
seg003:9F530 calls 89h, sub_89F6D6
seg003:9F534 mov r4, #1
seg003:9F536 jmpr cc_UC, loc_89F542; <-- call to our subroutine Basically r12 = r9. So next step is to turn graphical representation and find out that r9 is constant of 0. WTF? seg003:9F514 mov [-r0], r9
seg003:9F516 mov [-r0], r8
seg003:9F518 mov r8, r12
seg003:9F51A mov r9, #0 <--- WTF? Can someone explain where is my mistake? |
|
|
|
« Last Edit: March 30, 2013, 05:27:06 AM by masterj »
|
Logged
|
|
|
|
|
masterj
|
|
« Reply #93 on: March 30, 2013, 12:05:44 PM »
|
|
|
Thanks, phila_dot, for helping me out with this issue. It looks like I just had to use default 204h (204 * 4000) = 810000
10000 + 63B8 = 163B8
Voila.
Although, I'm still not sure why we ignore offset stored in FA12...
|
|
|
|
|
Logged
|
|
|
|
Axis
Full Member
Karma: +4/-4
Offline
Posts: 91
|
|
« Reply #94 on: April 09, 2013, 12:18:35 PM »
|
|
|
How are input/outputs on 2nd C167 addressed? I need to find such code to identify a map.
Anyone care to help? |
|
|
|
|
Logged
|
|
|
|
MIL_on
Full Member
Karma: +12/-2
Offline
Posts: 119
|
|
« Reply #95 on: January 23, 2014, 08:09:50 AM »
|
|
|
Hi, i am also busy, disassembling a file for the first time. prj mentioned once " [...] ps_w gets converted to rl_w [...]". This happens in bgsrm-brl. While looking at it i always asked what happens to psagr_w in the files without external recirculation (attachment 1). So i picked this "little" function to be the first i wanted to follow in IDA. I think i've set everything correct while loading. After re-naming rl_w, ps_w and ml_w i tried to go backwards through searching all occurences of rl_w (attachment2). i thought the beste idea is to look through the only function which mov to rl_w instead "away" from it. sub_86138E:
seg003:0006138E movb rl4, #85h ; 'à'
seg003:00061392 movb rl, rl4
seg003:00061396 mov r4, #10AAh
seg003:0006139A mov rl_w, r4
seg003:0006139E mov r5, #10AAh
seg003:000613A2 mov word_381D8A, r5
seg003:000613A6 mov r2, #10AAh
seg003:000613AA extp #0E1h, #1 ; 'ß'
seg003:000613AE mov word_384A54, r2
seg003:000613B2 mov r3, #654Ch
seg003:000613B6 mov word_381D86, r3
seg003:000613BA mov r1, #543Dh
seg003:000613BE extp #0E1h, #1 ; 'ß'
seg003:000613C2 mov word_384A4A, r1
seg003:000613C6 mov r2, #543Dh
seg003:000613CA mov word_381D94, r2
seg003:000613CE mov r2, #800h
seg003:000613D2 extp #0E1h, #1 ; 'ß'
seg003:000613D6 mov word_384A4C, r2
seg003:000613DA rets
seg003:000613DA ; End of function sub_86138E
no xrefs found here. am i reading correct, that the value from #10AAh is loaded into r4 and from there into the RAM? by searching backwards for 10AAh or to look at location 150AA (using the equation: 205h*4000h+10AA = 8150AA) i found nothing that looked right  . So how else can the subroutines be called? So, any hints for a beginner in assembler? |
|
|
|
« Last Edit: January 23, 2014, 08:47:23 AM by MIL_on »
|
Logged
|
|
|
|
|
terminator
|
|
« Reply #96 on: January 28, 2014, 03:17:32 PM »
|
|
|
solved
|
|
|
|
« Last Edit: January 29, 2014, 11:54:15 AM by terminator »
|
Logged
|
|
|
|
|
dream3R
|
|
« Reply #97 on: January 29, 2014, 05:47:03 AM »
|
|
|
I'll try and answer some of the questions here, but I do find them hard to follow (English maybe).
Anyway, the only way I can see to calculate the factor and offset is by using mx=y+b equation for calculating engineering units? Anyone care to chime in?
|
|
|
|
|
Logged
|
|
|
|
|
dream3R
|
|
« Reply #98 on: January 29, 2014, 06:03:05 AM »
|
|
|
Anyone care to help?
Inputs as in analogue or digital pins?
GGHFM: ; CODE XREF: INTERRUPT+40P
seg017:628C push PSW
seg017:628E atomic #3
seg017:6290 or PSW, #0F000h
seg017:6294 nop
seg017:6296 mov r14, maf_reading4
seg017:629A mov r12, maf_reading3
seg017:629E mov r13, maf_reading2
seg017:62A2 mov maf_reading4, ZEROS
seg017:62A6 mov maf_reading2, ZEROS
seg017:62AA mov maf_reading3, ZEROS
seg017:62AE pop PSW
seg017:62B0 jb b_ehfm.1, loc_762BE
seg017:62B4 mov r12, maf_reading1
seg017:62B8 bset b_ehfm.1
seg017:62BA jmpa cc_UC, loc_762CE ; average
seg017:62BE ; ---------------------------------------------------------------------------
seg017:62BE
seg017:62BE loc_762BE: ; CODE XREF: GGHFM+24j
seg017:62BE mov MDH, r12
seg017:62C2 mov MDL, r13
seg017:62C6 divl r14
seg017:62C8 mov r14, MDL
seg017:62CC mov r12, r14
seg017:62CE
seg017:62CE loc_762CE: ; CODE XREF: GGHFM+2Ej
seg017:62CE mov mlhfmm_w, r12 ; average
seg017:62D2 mov mshfmm_w, r12
seg017:62D6 mov r13, fkhfm
seg017:62DA mov r14, r12
seg017:62DC mov r12, #0
seg017:62DE mov r15, r14
seg017:62E0 jmpr cc_NN, loc_762E4
seg017:62E2 neg r15
seg017:62E4
seg017:62E4 loc_762E4: ; CODE XREF: GGHFM+54j
seg017:62E4 mulu r15, r13
seg017:62E6 mov r15, MDH
seg017:62EA mov r12, r15
seg017:62EC and r15, #0C000h
seg017:62F0 jmpr cc_Z, loc_76302
seg017:62F2 mov r15, r14
seg017:62F4 jmpr cc_N, loc_762FC
seg017:62F6 mov r12, #7FFFh
seg017:62FA jmpr cc_UC, loc_76312
seg017:62FC ; ---------------------------------------------------------------------------
seg017:62FC
seg017:62FC loc_762FC: ; CODE XREF: GGHFM+68j
seg017:62FC mov r12, #8000h
seg017:6300 jmpr cc_UC, loc_76312
seg017:6302 ; ---------------------------------------------------------------------------
seg017:6302
seg017:6302 loc_76302: ; CODE XREF: GGHFM+64j
seg017:6302 shl r12, #1
seg017:6304 mov r15, MDL
seg017:6308 bmov r12.0, r15.15
seg017:630C mov r15, r14
seg017:630E jmpr cc_NN, loc_76312
seg017:6310 neg r12
seg017:6312
seg017:6312 loc_76312: ; CODE XREF: GGHFM+6Ej
seg017:6312 ; GGHFM+74j ...
seg017:6312 mov r13, r12
seg017:6314 mov mshfm1_w, r12
seg017:6318 cmp r12, #0
seg017:631A jmpr cc_SGT, loc_76322
seg017:631C mov mshfm_w, ZEROS
seg017:6320 jmpr cc_UC, loc_76326
seg017:6322 ; ---------------------------------------------------------------------------
seg017:6322
seg017:6322 loc_76322: ; CODE XREF: GGHFM+8Ej
seg017:6322 mov mshfm_w, r12
seg017:6326
seg017:6326 loc_76326: ; CODE XREF: GGHFM+94j
seg017:6326 cmp r12, MLMIN
seg017:632A jmpr cc_SGE, loc_76336
seg017:632C mov r12, MLMIN
seg017:6330 mov mshfms_w, r12
seg017:6334 rets
Above is my analysis of GGHFM where is calulates MAF reading from voltage, it might give some insight. I believe maf_readingx is voltage readings directly from the maf, read from the ECU pins. I can't find that code just now but unless I remember wrong that is what I saw. Here is another bit of code where the CPU pin ad6 is being read directly in-to the variable uulsuv_w, which iirc is the wideband O2 on my caR. AD6 is actually a RAM cell in this example. seg013:FF3E READ_CPU_PINS_sub_3FF3E: ; CODE XREF: READ_ADC+8P
seg013:FF3E ; ONE_MS_INTERRUPT_READ_SENSORS+1EP
seg013:FF3E mov r4, f_ad7
seg013:FF42 and r4, #3FFh
seg013:FF46 mov word_30094E, r4
seg013:FF4A mov r5, f_ad6
seg013:FF4E and r5, #3FFh
seg013:FF52 mov uulsuv_w, r5
seg013:FF56 rets
|
|
|
|
|
Logged
|
|
|
|
|
terminator
|
|
« Reply #99 on: January 29, 2014, 11:26:09 AM »
|
|
|
The thread like a monolog now. People are only asking.
|
|
|
|
|
Logged
|
|
|
|
TijnCU
Hero Member
Karma: +60/-4
Offline
Posts: 690
flying brick
|
|
« Reply #100 on: December 19, 2016, 02:54:28 AM »
|
|
|
How are input/outputs on 2nd C167 addressed? I need to find such code to identify a map.
I found inputs as ram and outputs as P#.# Could be the inputs come from a P#.# as well, but havent looked for further xrefs. |
|
|
|
|
Logged
|
|
|
|
|
elRey
|
|
« Reply #101 on: February 19, 2017, 06:43:12 PM »
|
|
|
Hello all, I'd like to multiply a word and a byte, specifically out put of KFLDRAPP and vstfva and cap at 100%. For testing I can use ldtvmd_word and vstfva and monitor the results before I decide to use it. I want vstfva byte to represent a 0% - 100% not 0% - 200%. So, if ldtvmd = 40% (i believe x66h) and vstfva = x80h (50% on a 0-100 scale), the result should be 20% (x33h). This will replace the addition of vsldtv_byte to output KFLDRAPP. I typically look for near exact examples of what I want to do and copy/paste/modify for what I need. However, I'm having a hard time finding an close example of to byte mulu where I can clearly understand the assign of MDH and MDL afterward. I'm confused with pulling out byte for the word results of the mulu. First part: mov r4, ldtvmd_word_382484
movbz r5, vstfva_ch03_byte_380AE4
mulu r5, r4
Problem I see here is the movbz of vstfva. If vstfva = xFFh, then movbz would make it xFF00h (99.61%) and not xFFFFh (100%). Or is this something I shouldn't worry about (close enough)? 2nd part: cmp MDH, #0FFh
jmpr cc_ULE, loc_84D8CA
mov MDH, #0FFh
Not sure this does what I think it does. I want to quickly check if it it should be (capped at) 100%. 3rd part: mov r5, word_FE0E
shr r5, #7
movb factored_ldtvmd_byte_380D86, rl5
I'm confused about this also. How do I get the word result into a byte? Thanks, Rey edit: just found this example: mov r4, #8Ch ; <- will use ldtvmd_word_382484 here
movbz r5, byte_38092F ; <- will use vstfva_ch03_byte_380AE4 here
mulu r5, r4
jmpr cc_V, loc_844DA2 ; <- checking Overflow
mov r2, word_FE0E
jmpr cc_UC, loc_844DA6
loc_844DA2:
mov r2, #0FFFFh ; <- FFFF is Overflow
loc_844DA6:
shr r2, #7
movb byte_383100, rl2
|
|
|
|
« Last Edit: February 19, 2017, 08:24:33 PM by elRey »
|
Logged
|
|
|
|
|
nubcake
|
|
« Reply #102 on: April 04, 2017, 10:30:58 AM »
|
|
|
Once again a late reply from me, but, eh - better late, than never? See below. First part: mov r4, ldtvmd_word_382484
movbz r5, vstfva_ch03_byte_380AE4
mulu r5, r4
Problem I see here is the movbz of vstfva. If vstfva = xFFh, then movbz would make it xFF00h (99.61%) and not xFFFFh (100%). Or is this something I shouldn't worry about (close enough)? "movbz" extends the MSB, not LSB. Meaning "mobvz" to the word register will produce "00FFh" value or "FFh" in "rl x" and "00h" in "rh x". 2nd part: cmp MDH, #0FFh
jmpr cc_ULE, loc_84D8CA
mov MDH, #0FFh
Not sure this does what I think it does. I want to quickly check if it it should be (capped at) 100%. Just the check of result size, I believe. If multiplication got over 6 hex digits (if it makes sense). 3rd part: mov r5, word_FE0E
shr r5, #7
movb factored_ldtvmd_byte_380D86, rl5
I'm confused about this also. How do I get the word result into a byte? No way without losing accuracy, obviously.  And that's what this snippet does: MDL to r5, divide r5 by 128 (shift right 7 times = divide by 2^7), moves the result into 380D86. Why the last bit is ignored - I dunno. Might be one of the initial values was signed and sign is irrelevant. |
|
|
|
|
Logged
|
|
|
|
|
