NefMoto

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.

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?

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!

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 (https://www.sendspace.com/file/bwqr9m) (dissasembled ida file) and advise what to check here so I could finally set 381AD1.1 = 1?

Thats the timer.

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...

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.

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?

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...

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....

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.

In the meantime I'll log 380BC2 to see what's going on and report here...

UPDATE: logged both 380BC2.1 and 380BC2.3 - both of them are set to 1. Looks like problem is not here

Rechecked and re-logged everything one more time. Looks like problem is definitely in 381AD1.1 because it is never set to 1 even if counter TRSE is set to zero. And because of that B_sbbhk is never set. Can someone just open my idb file in ida and advise me what else to do? I know that philla dot said he would look but I know that this will not happen soon and I need this fixed as soon as possible.

Wip ida pro file: https://www.sendspace.com/file/bwqr9m

More updates on the issue... so i went and flashed TRSE = 20s. And to my surprise 0x381ACA was always 0. So that makes me think maybe this whole diagnostic function is not executed for some odd reason?? Are there any special conditions for this function to be executed that are not mentioned in fr diagrams? Really need help here, guys. Very weird situation and actually first big mystery since registration on nefmoto :)

OK, so finally I found why DLSH is not even starting. I thought that CDLSH only overwrites cycle and error bits, but actually CDLSH.0 = 0 ===> DLSH is SKIPPED completely (as in it never existed). So I enabled CDLSH and bam - everything works as expected :) Thanks everyone who was trying to help me.