|
elRey
|
 |
« Reply #30 on: February 12, 2013, 11:50:01 AM »
|
|
|
movb rl7, #40h ; bit6
movb rl6, #0
mov r12, #9957h
movbz r4, rl6
add r12, r4
movb rl4, [r12]
orb rl4, rl7
movb [r12], rl4
Could someone explain these lines of code please? What do the square brackets [] do? I'll see if I can find what #9957h referes to. And likewise, why does this look like it's redundant (repeating): movb rl7, #4
movb rl6, #0
mov r12, #9957h
movbz r4, rl6
add r12, r4
movb rl4, [r12]
orb rl4, rl7
movb [r12], rl4
movb rl7, #4 ; bit2
movb rl6, #0
mov r12, #9957h
movbz r4, rl6
add r12, r4
movb rl4, [r12]
orb rl4, rl7
movb [r12], rl4
Do the [r12] increment places or something? Thanks, Rey |
|
|
|
« Last Edit: February 12, 2013, 11:57:15 AM by elRey »
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #31 on: February 12, 2013, 12:12:20 PM »
|
|
|
I believe [] is a dereference.
i.e. [r12] refers to the contents of memory at the location pointed to by the contents of r12, rather than just the contents of r12
|
|
|
|
|
Logged
|
ME7.1 tuning guideECUx PlotME7Sum checksumTrim heatmap toolPlease do not ask me for tunes. I'm here to help people make their own. Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your ex
|
|
|
|
phila_dot
|
|
« Reply #32 on: February 12, 2013, 01:42:27 PM »
|
|
|
I believe [] is a dereference.
i.e. [r12] refers to the contents of memory at the location pointed to by the contents of r12, rather than just the contents of r12
Bingo. Memory is being read from 9957h rather than 9957h being read as data itself. |
|
|
|
|
Logged
|
|
|
|
|
elRey
|
|
« Reply #33 on: February 12, 2013, 01:55:56 PM »
|
|
|
Thanks, but why does it look like it runs the same thing twice where the outcome seems to be the same?
|
|
|
|
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #34 on: February 12, 2013, 03:32:36 PM »
|
|
|
elray: from my quick reading you appear to be right. Not sure why.
|
|
|
|
|
Logged
|
ME7.1 tuning guideECUx PlotME7Sum checksumTrim heatmap toolPlease do not ask me for tunes. I'm here to help people make their own. Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your ex
|
|
|
|
phila_dot
|
|
« Reply #35 on: February 12, 2013, 04:35:55 PM »
|
|
|
Hard to tell a whole lot from an out of context code snippet on the internet, but it looks some of the possible functionality is not being used.
The fact that 9957h is being offset by a hardcoded 0. I've seen alot of places in the code where some functionality that might be used in other applications is disabled in one way or another. It looks to be designed to use 9957h as a base and offset to different locations each timing or'ing with a hex value.
|
|
|
|
|
Logged
|
|
|
|
Geremia
Jr. Member
Karma: +11/-10
 Offline
Posts: 27
|
|
« Reply #36 on: February 16, 2013, 08:54:23 AM »
|
|
|
Thanks, but why does it look like it runs the same thing twice where the outcome seems to be the same?
Probably it's just compiler issue or lazyness about source code optimizing, given 9957 as a simple ram addr. But, if 9957 is a memorymapped register for some peripheral (mmu, controller of something), the double writing 40 could assume a meaning. |
|
|
|
|
Logged
|
|
|
|
|
elRey
|
|
« Reply #37 on: April 19, 2013, 12:31:27 PM »
|
|
|
Disassembly: HEX: Jump to xref doesn't show where word_3839C2 is written, only read. That part may not have been disassembled by plug-in. What do I search in HEX to find where word_3839C2 is written to? Thanks, Rey |
|
|
|
|
Logged
|
|
|
|
|
Bische
|
|
« Reply #38 on: June 19, 2013, 04:38:32 AM »
|
|
|
Im trying to find an adress, but I got stuck on how it is pointed to: loc_893730:
mov r12, #215Ah
mov r13, #206h
movbz r14, tmot
calls 83h, sub_833D44
extp #0E1h, #1 ; 'ß'
movb byte_3848E6, rl4
movbz r4, byte_FA1C
movb rl5, [r4+6A7Ch]
movb [r0], rl5
mov r4, [r0]
bmov word_FD86.4, r4.0
bmov word_FD86.5, r4.1
bmov word_FD86.6, r4.2
bmov word_FD86.7, r4.3
bmov word_FD86.8, r4.4
bmov word_FD86.9, r4.5
bmov word_FD86.10, r4.6
bmov word_FD86.11, r4.7
add r0, #2
mov r8, [r0+]
mov r9, [r0+]
rets
; End of function sub_893660
movb rl5, [r4+6A7Ch]
movb [r0], rl5
mov r4, [r0]I initially thought it was as simple as FA1C+6A7C, since FA1C is a CAN adress(lws_w, steering angle), but that does not line up. Or is it reading the content of the memory and adding 6A7C to point to the codeword? Seems unlikely to me.. In the known bin I have it is pointed to a hard adress. |
|
|
|
« Last Edit: June 19, 2013, 04:44:52 AM by Bische »
|
Logged
|
|
|
|
|
prj
|
|
« Reply #39 on: June 20, 2013, 03:57:00 AM »
|
|
|
Log with ME7Logger what value is stored in FA1C.
Looks like variant coding to me.
Then add what is stored in FA1C to 0x6A7Ch.
0x6A7Ch is the main address and FA1C stores an offset that is added to it.
In your known bin there is just one variant and it is not possible to have multiple values for different codings.
In this bin looks like 0x816A7Ch contains multiple values and they are accessed based on variant coding.
hth.
|
|
|
|
|
Logged
|
|
|
|
|
Bische
|
|
« Reply #40 on: June 22, 2013, 12:41:37 AM »
|
|
|
Thanks, I will try that.
|
|
|
|
|
Logged
|
|
|
|
|
elRey
|
|
« Reply #41 on: June 27, 2013, 11:11:22 AM »
|
|
|
movb rl4, #0
bmov r4.0, word_FD3E.6
cmpb rl4, #1
jmpa cc_NZ, loc_85A838
Is the third line byte comparing constants 00 and 01 ? If so, does that mean code never jmps to loc_85A838? i.e. code at loc_85A838 has been permanently disabled? |
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #42 on: June 27, 2013, 11:50:17 AM »
|
|
|
No.
it checks if FD3E.6 is set, and branches if it's not.
|
|
|
|
|
Logged
|
|
|
|
|
elRey
|
|
« Reply #43 on: June 27, 2013, 12:10:33 PM »
|
|
|
is r4.0 the same as r14  |
|
|
|
|
Logged
|
|
|
|
|
phila_dot
|
|
« Reply #44 on: June 27, 2013, 12:11:16 PM »
|
|
|
It's rl4, as in the low byte of r4.
|
|
|
|
|
Logged
|
|
|
|
|
