|
masterj
|
 |
« on: September 20, 2014, 01:57:21 PM »
|
|
|
Hi, guys!
So I was scanning through my file in ida trying to find why I can't set z_lsv and found something interesting. so if we set CDLASH and CWDLSAHK to zero we should get zeroed out sfplash, right? Right? Wrong... or at least in my file. For some odd reason when logging I see sfplash.1 === 1!
Can someone tell me what is setting sfplash.1 bit to 1 ? And how can I force it to be zero at all times...
BTW I thought that sfplash bits hold all the errors info, like B_maxlash, B_minlash, etc. But I think that I was wrong.
|
|
|
|
« Last Edit: September 29, 2014, 11:19:53 AM by masterj »
|
Logged
|
|
|
|
|
phila_dot
|
|
« Reply #1 on: September 20, 2014, 02:44:32 PM »
|
|
|
Bit 0 is the error flag and bit 1 is the cycle flag.
Look at %DFPM for the breakdown.
A set cycle flag is desirable.
|
|
|
|
|
Logged
|
|
|
|
|
masterj
|
|
« Reply #2 on: September 21, 2014, 03:23:36 AM »
|
|
|
Bit 0 is the error flag and bit 1 is the cycle flag.
Look at %DFPM for the breakdown.
A set cycle flag is desirable.
Oh, now I get it, so zero bit is e_xxx and first bit is z_xxx. Hm... It is very weird because in FR this portion of code is shown as z_xxx (AND logic gate) e_xxx and in dissasembly it looks like z_xxx (OR logic gate) e_xxx. I mean that e_lash = 1 or z_lash = 1 sets b_sbbhk = 0. Or I am wrong? |
|
|
|
|
Logged
|
|
|
|
|
phila_dot
|
|
« Reply #3 on: September 21, 2014, 06:55:17 AM »
|
|
|
That is an and in the code you posted above.
If the cycle flag is set, then the error flag is checked, if the error flag is set then the reset condition is true and the bit is cleared. If either is clear then the reset condition is false and the set condition is tested.
|
|
|
|
|
Logged
|
|
|
|
|
masterj
|
|
« Reply #4 on: September 21, 2014, 07:54:51 AM »
|
|
|
That is an and in the code you posted above.
If the cycle flag is set, then the error flag is checked, if the error flag is set then the reset condition is true and the bit is cleared. If either is clear then the reset condition is false and the set condition is tested.
Ah, my bad  I mixed up bit 0 with bit 1 ) Thank you, philla! |
|
|
|
|
Logged
|
|
|
|
|
masterj
|
|
« Reply #5 on: September 21, 2014, 08:29:26 AM »
|
|
|
Hm... so looks like my problem of not setting the b_sbbhk is in 381AD1.1 bit. It is always set to zero. So I have went up and searched for a place where this specific bit is set. Found something, but could not identify what variable is hidden in 381ACA. Because this is the only place where code could end up and not set 381AD1.1 = 1. I think 381ACA should be set to zero so 381AD1.1 would become 1. Is it correct logic? Also I could not find any other writes to this specific address other than the ones that can be seen parallel in image. Philla, maybe you could check out my file @ https://www.sendspace.com/file/bwqr9m (dissasembled ida file) and advise what to check here so I could finally set 381AD1.1 = 1? |
|
|
|
|
Logged
|
|
|
|
|
phila_dot
|
|
« Reply #6 on: September 21, 2014, 09:37:07 AM »
|
|
|
Thats the timer.
|
|
|
|
|
Logged
|
|
|
|
|
masterj
|
|
« Reply #7 on: September 22, 2014, 03:06:08 AM »
|
|
|
Hmmm... if this is delay counter for trse then it should be preset to 0 by default because trse map in my file is set to zero.. very strange ill try to relog and put more variables here...
|
|
|
|
|
Logged
|
|
|
|
|
phila_dot
|
|
« Reply #8 on: September 22, 2014, 08:16:38 AM »
|
|
|
Is FD40.5 set?
How does ushk_w compare to those parameters?
|
|
|
|
|
Logged
|
|
|
|
|
masterj
|
|
« Reply #9 on: September 22, 2014, 01:07:35 PM »
|
|
|
Is FD40.5 set?
How does ushk_w compare to those parameters?
FD40.5 is B_hsha and it is always set to 1, ushk_w is 0 at all times. Please look at the zlsv.csv in first post. I have logged everything that is connected to this part... Also I'll attach my ecu file to see variables to address mapping. |
|
|
|
« Last Edit: September 22, 2014, 01:11:52 PM by masterj »
|
Logged
|
|
|
|
|
phila_dot
|
|
« Reply #10 on: September 22, 2014, 04:13:58 PM »
|
|
|
That's not possible.
If FD40.5 is always set, and ushk_w is always 0, then 0x371AD1.1 would be set in short time.
Even if 0x381ACA isn't 0, it will get there in enough cycles (not long).
Have you logged 0x381ACA?
|
|
|
|
|
Logged
|
|
|
|
|
masterj
|
|
« Reply #11 on: September 23, 2014, 03:17:50 AM »
|
|
|
Log shows that 0x381ACA (TRSE_TIMER) is always 0. Im attaching image, log of everything and definition file. What else to log, philla? Im kinda out of ideas...
|
|
|
|
|
Logged
|
|
|
|
|
phila_dot
|
|
« Reply #12 on: September 23, 2014, 10:39:04 AM »
|
|
|
Where does that red line (false branch) on the left in your screenshot come from?
|
|
|
|
|
Logged
|
|
|
|
|
masterj
|
|
« Reply #13 on: September 23, 2014, 02:18:18 PM »
|
|
|
Where does that red line (false branch) on the left in your screenshot come from?
This comes from a mystery variable 380BC2. If bits 1, 3 (#10) are zero then it follows false branch and basically skips through everything to the very bottom of the function. Philla, maybe you could just open disassembled idb (ida pro db file) that i have sent to sendspace? It will be way easier to see what is what than with these screenshots. Hm... No clue what is behind 380BC2.1 and 380BC2.3.... |
|
|
|
|
Logged
|
|
|
|
|
phila_dot
|
|
« Reply #14 on: September 23, 2014, 03:52:35 PM »
|
|
|
I'm only ever on here when I'm away from my computer and on my phone.
Anytime I'm on my computer I'm busy trying to get my own work done.
I will take a look the next time I get the chance.
|
|
|
|
|
Logged
|
|
|
|
|
