NefMoto

Technical => Reverse Engineering => Topic started by: armageddon on May 16, 2017, 03:17:47 PM



Title: Disable kr during nls
Post by: armageddon on May 16, 2017, 03:17:47 PM
To not to mess with others topics....

I'm still "learning" assembly language, IDAPRO and so,...

I would like to get rid of knock retard during nls, and and as this is a issue that affects more people, maybe we can together try to get a solution .

reading this posts from prj, it should be enough to disable kr by setting cwkr to 0 during nls and back to 1 after

Quote from: prj
If you have issues with knock after LC/NLS you need to modify the LC/NLS code to disable knock control when LC/NLS is active and re-enable knock control after LC/NLS has deactivated.
That way you will not have the problem with knock retard during flatshift.............Knock control on/off is a single bit on ME7. Same goes for misfires. Toggling this on or off is hardly rocket science, I know this because I've done this.


does the following code makes any sense?

at the begining of nls function

mov     r4, word_81999A(cwkr on k-box)
mov     byte_Fxxx, r4(unused ram)
bclr      word_Fxxx.0

and before exit nls function

bset    word_Fxxx.0

feel free to help :)


Title: Re: Disable kr during nls
Post by: fknbrkn on May 17, 2017, 03:35:14 AM
the problem is not in your asm code
problem is logic

what the purpose of reading flash value of cwkr, moving it to unused ram location and then immediately clear this byte?


Title: Re: Disable kr during nls
Post by: armageddon on May 17, 2017, 04:14:27 AM
Thanks for the input,

so what will be the correct way to set cwkr to 0 and then back to 1?


Title: Re: Disable kr during nls
Post by: prj on May 17, 2017, 04:35:39 AM
Threads like this are good. It gives a lesson in humility.


Title: Re: Disable kr during nls
Post by: TijnCU on May 17, 2017, 09:26:25 AM
you need to look at the FR and then you see:
CWKR > BIT
You do not need to alter CWKR. But you need to study more code first  :)


Title: Re: Disable kr during nls
Post by: nyet on May 17, 2017, 10:02:15 AM
If CWKR is in flash you can't modify it on the fly. Certainly making a copy of it, then modifying the copy isn't going to accomplish anything, unless you change the ASM that reads CWKR such that it reads your copy instead.

Alternately, modify some of the resulting RAM variables instead.

Some obvious (RAM) candidates:

lkrnew, lkrold, B_drlkrdy, drlkrdy, drlkrra

I could be wrong about all of this, of course.

But I don't think CWKR does what you think it does, so all of the above is useless (although hopefully it addresses a major misconception you have about ASM hacking..)

Threads like this are good. It gives a lesson in humility.

Lack of humility isn't the problem in this case, IMO :P

I think forcing B_kr to 0 is all you need.

I could be wrong of course.


Title: Re: Disable kr during nls
Post by: armageddon on May 17, 2017, 12:42:22 PM
I think forcing B_kr to 0 is all you need.

I could be wrong of course.

thanks,

I have already tried it with b_kr, but as said previously by TijnCU, it did not work


Title: Re: Disable kr during nls
Post by: nyet on May 17, 2017, 12:45:50 PM
thanks,

I have already tried it with b_kr, but as said previously by TijnCU, it did not work

You have to modify where it is calculated. If you just overwrite it randomly from elsewhere, it isn't going to work, since whatever you do will be overwritten by existing ASM where B_kr is calculated by the stock ASM.

I didn't read what TijnCU did, so I don't know if that is what he was trying to do or not.


Title: Re: Disable kr during nls
Post by: contrast on May 17, 2017, 01:27:34 PM
I had a problem with b_kr not working during NLS, but similarly the problem was wrong place.
If you change in the correct place, it will disable KR.


Title: Re: Disable kr during nls
Post by: prj on May 17, 2017, 02:01:54 PM
b_kr is crank-sync. tsrldyn is 20ms scheduler iirc.
So yeah changing it in tsrldyn routine will accomplish nothing.


Title: Re: Disable kr during nls
Post by: gt-innovation on May 17, 2017, 03:15:12 PM
thanks,

I have already tried it with b_kr, but as said previously by TijnCU, it did not work

Logic is simple.

1.Find where the codeword is checked on the original code.
2.Hijack it to your code(somewhere between lc and nls code)
3.make byte 0 while running
4.make byte 1 before exit



Title: Re: Disable kr during nls
Post by: armageddon on May 18, 2017, 04:07:15 AM
You have to modify where it is calculated. If you just overwrite it randomly from elsewhere, it isn't going to work, since whatever you do will be overwritten by existing ASM where B_kr is calculated by the stock ASM.

ok, I think I am understanding what you are saying, but ASM it's still a little(alot Smiley ) confusing to me

found this, is this the right place?
Code:
loc_875E06:                             ; CODE XREF: ROM:loc_875DF8j
ROM:875E06                 jnb     word_FDB4.0, loc_875E1C
ROM:875E0A                 jnb     word_FD92.9, loc_875E1C
ROM:875E0E                 movbz   r4, byte_A50E
ROM:875E12                 and     r4, #10h
ROM:875E16                 jmpr    cc_Z, loc_875E1C
ROM:875E18                 bset    word_FD90.10  (b_kr)
ROM:875E1A                 jmpr    cc_UC, loc_875E1E
ROM:875E1C ; ---------------------------------------------------------------------------
ROM:875E1C
ROM:875E1C loc_875E1C:                             ; CODE XREF: ROM:875E04j
ROM:875E1C                                         ; ROM:loc_875E06j ...
ROM:875E1C                 bclr    word_FD90.10  (b_kr)
ROM:875E1E


Title: Re: Disable kr during nls
Post by: SB_GLI on May 18, 2017, 07:43:39 AM
Logic is simple.

1.Find where the codeword is checked on the original code.
2.Hijack it to your code(somewhere between lc and nls code)
3. Store original value
4. make byte 0 while running
5. restore original value




Title: Re: Disable kr during nls
Post by: prj on May 19, 2017, 10:35:07 AM
Just jump to 0 if LC active and do nothing if it is not, let the original logic run - really not so hard...
No need to save store or restore anything.


Title: Re: Disable kr during nls
Post by: armageddon on May 20, 2017, 03:21:31 PM
Assuming that the location above is the right place to clear b_kr.... what's the meaning of #10h ?

Code:
ROM:875E0E                 movbz   r4, byte_A50E
ROM:875E12                 and     r4, #10h



and another noob question, how to jump to there from nls routine?

do I have to modify the original ASM code to call nls routine?


Title: Re: Disable kr during nls
Post by: nyet on May 20, 2017, 04:18:20 PM
what's the meaning of #10h ?

r4 &= 00010000


Title: Re: Disable kr during nls
Post by: nubcake on May 21, 2017, 05:55:22 AM
how to jump to there from nls routine?

You don't.
You set up some kind of "NLS active" flag in your original routine and check for it in KR one.


Title: Re: Disable kr during nls
Post by: armageddon on May 21, 2017, 06:52:18 AM
all of you already helped me alot, but if you could help me a litle more with the code....

this is what I'm thinking, but not sure where to place it, does it have to be inside nls routine or can be placed outside

Code:
loc_875E06:                             ; CODE XREF: ROM:loc_875DF8j
ROM:875E06                 jnb     word_FDB4.0, loc_875E1C
ROM:875E0A                 jnb     word_FD92.9, loc_875E1C
ROM:875E0E                 calls   8Ah, sub_8Axxxx
ROM:875E12                 and     r4, #10h
ROM:875E16                 jmpr    cc_Z, loc_875E1C
ROM:875E18                 bset    word_FD90.10
ROM:875E1A                 jmpr    cc_UC, loc_875E1E
ROM:875E1C ; ---------------------------------------------------------------------------
ROM:875E1C
ROM:875E1C loc_875E1C:                             ; CODE XREF: ROM:875E04j
ROM:875E1C                                         ; ROM:loc_875E06j ...
ROM:875E1C                 bclr    word_FD90.10
ROM:875E1E


 

Code:
 sub_8Axxxx:                      movbz   r4, byte_A50E
                                  jnb     word_Fxxx.0, locret_8Azzzz
                                  and     r4, #EFh   

 locret_8Azzzz:                         
                                  rets

set bit Fxxx.0 somewhere before/after trsldyn on NLS

Code:
ROM:8A4690                 jnb     word_FD5C.9, loc_8A46BA
ROM:8A4694                 mov     r4, word_9E7C
ROM:8A4698                 exts    #81h, #1 ; 'ü'
ROM:8A469C                 mov     r9, word_817200
ROM:8A46A0                 cmp     r4, r9
ROM:8A46A2                 jmpr    cc_NC, loc_8A46BA
ROM:8A46A4                 mov     r4, word_F802
ROM:8A46A8                 exts    #81h, #1 ; 'ü'
ROM:8A46AC                 mov     r9, word_817202
ROM:8A46B0                 cmp     r4, r9
ROM:8A46B2                 jmpr    cc_ULE, loc_8A46BA
ROM:8A46B4                 movb    byte_8CB2, ZEROS
ROM:8A46B8                 jmpr    cc_UC, loc_8A4718
ROM:8A46BA ; ---------------------------------------------------------------------------
ROM:8A46BA
ROM:8A46BA loc_8A46BA:                             ; CODE XREF: ROM:8A4690j
ROM:8A46BA                                         ; ROM:8A46A2j ...
ROM:8A46BA                 jnb     word_FD5C.9, loc_8A4710
ROM:8A46BE                 jb      word_FD5C.5, loc_8A4706
ROM:8A46C2                 mov     r4, word_F802
ROM:8A46C6                 exts    #81h, #1 ; 'ü'
ROM:8A46CA                 mov     r9, word_817206
ROM:8A46CE                 cmp     r4, r9
ROM:8A46D0                 jmpr    cc_ULE, loc_8A4706
ROM:8A46D2                 movbz   r4, byte_8AB0
ROM:8A46D6                 exts    #81h, #1 ; 'ü'
ROM:8A46DA                 movbz   r9, byte_817208
ROM:8A46DE                 cmp     r4, r9
ROM:8A46E0                 jmpr    cc_ULE, loc_8A4706
ROM:8A46E2                 exts    #38h, #1 ; '8'
ROM:8A46E6                 mov     r4, word_384FF0
ROM:8A46EA                 exts    #81h, #1 ; 'ü'
ROM:8A46EE                 mov     r9, word_817204
ROM:8A46F2                 cmp     r4, r9
ROM:8A46F4                 jmpr    cc_NC, loc_8A4718
ROM:8A46F6                 movb    byte_8CB2, ZEROS
ROM:8A46FA                 add     r4, #1
ROM:8A46FC                 exts    #38h, #1 ; '8'
ROM:8A4700                 movb    word_384FF0, rl4
ROM:8A4704                 jmpr    cc_UC, loc_8A4718
ROM:8A4706 ; ---------------------------------------------------------------------------
ROM:8A4706
ROM:8A4706 loc_8A4706:                             ; CODE XREF: ROM:8A46BEj
ROM:8A4706                                         ; ROM:8A46D0j ...
ROM:8A4706                 exts    #38h, #1 ; '8'
ROM:8A470A                 mov     word_384FF0, ONES
ROM:8A470E                 jmpr    cc_UC, loc_8A4718
ROM:8A4710 ; ---------------------------------------------------------------------------
ROM:8A4710
ROM:8A4710 loc_8A4710:                             ; CODE XREF: ROM:loc_8A46BAj
ROM:8A4710                 exts    #38h, #1 ; '8'
ROM:8A4714                 mov     word_384FF0, ZEROS
ROM:8A4718
ROM:8A4718 loc_8A4718:                             ; CODE XREF: ROM:8A46B8j
ROM:8A4718                                         ; ROM:8A46F4j ...
ROM:8A4718                 movb    rl4, byte_8AA4
ROM:8A471C                 rets




Title: Re: Disable kr during nls
Post by: prj on May 21, 2017, 03:42:15 PM
You need to read some programming basics.
You have no idea what you are doing.

Learn at least a programming language, hell QBASIC will do.


Title: Re: Disable kr during nls
Post by: Khendal on May 22, 2017, 02:56:36 PM
I've found this condition on FR... for Knock control active :

Condition KC active : B_kr : (( rl > LKRN ) v B krldy ) & ( tmot > TMKR ) & B_stend

Maybe we need to change this condition by entering a check inside on a nls variable on or off ???  

Something like :

(( rl > LKRN ) v B krldy ) & ( tmot > TMKR ) & B_stend & NLS_off

I've also found this info... if needed :

The knock control can be switched off via the label TMKR: TMKR > tmot ==> !B kr


Title: Re: Disable kr during nls
Post by: jcsbanks on May 23, 2017, 10:16:18 AM
I have no idea about ME7, but have modified a lot of C167 code on MS43, so some general tips.

You need to work out how to intervene on a functional level first. Often there are a range of options that vary from trivial to complex to code. You need to think about all the side effects and possible side effects.

As others have pointed out, the logic and data integrity is everything, you need to be writing something that isn't going to get trampled by something else writing the same, especially if more frequently than you or causing an oscillation.

If you can achieve a result with existing code by altering a map or a codeword, do so.

If that isn't possible, consider whether to change an axis of an existing map to change it to do what you want.

Or a strategically placed NOP, change to a branch condition etc.

Or change the address of a pointer and make a new one (find free space, initialise the value, change code that uses your pointer).

Sometimes you need to add a hook by replacing an existing instruction with a jmp or call. Or change the address of an existing jmp or call.

Preserve register integrity, don't screw the stack. Have a way to boot recover your ECU when you mess it up. Simulate everything. Don't assume anything, Bosch are very clever. Dunning Kruger zone alert.

Edit: also, label your disasm. It will then make a lot more sense to you and everyone reading. You probably have an a2l for your ROM, so import it into your idb. If you don't, work on one for which you do until you understand it.


Title: Re: Disable kr during nls
Post by: armageddon on May 30, 2017, 11:37:32 AM
Just to give some feedback,

b_kr  disabled in the right place did the trick

from today test it is working fine but will do some logs to make sure that everything is working as it should

thanks to all that contributed for this  ;)


Title: Re: Disable kr during nls
Post by: Khendal on May 30, 2017, 02:37:18 PM
Just to give some feedback,

b_kr  disabled in the right place did the trick

from today test it is working fine but will do some logs to make sure that everything is working as it should

thanks to all that contributed for this  ;)

Ohhh really ??? Nice work ;)


Title: Re: Disable kr during nls
Post by: woj on March 15, 2018, 12:53:00 PM
Let's try this here, B_kr seems easy enough, but I am also trying to figure out dmd. B_dmdstop seems to be impossible to locate in the code for me (it is mostly in procedures where there is several other bit flags manipulated, very hard to tell which is which, and I am loosing my patience with this). But, as with CWKR, I could do it with moving CDMD to RAM and switch it there. I found the code where CDMD goes to B_cdmd and then everything follows. But what I'd need to know, if that is crank synchronous, or periodic (100ms or else). I can see that in the same loop there are DTC reporting procedure for IAT or CTS for example, but I am still not 100% sure about the procedure's frequency. Anyone?

(Yes, I know that for "big boy" applications with NLS/LC one can just turn off CDMD, unlike CWKR that should be retained, nevertheless I want to know).

EDIT: I might have found a solution that does not require the answer to the posted questions, nevertheless, I'd still be interested in feedback on this.


Title: Re: Disable kr during nls
Post by: nubcake on March 15, 2018, 06:16:24 PM
Let's try this here, B_kr seems easy enough, but I am also trying to figure out dmd. B_dmdstop seems to be impossible to locate in the code for me (it is mostly in procedures where there is several other bit flags manipulated, very hard to tell which is which, and I am loosing my patience with this). But, as with CWKR, I could do it with moving CDMD to RAM and switch it there. I found the code where CDMD goes to B_cdmd and then everything follows. But what I'd need to know, if that is crank synchronous, or periodic (100ms or else). I can see that in the same loop there are DTC reporting procedure for IAT or CTS for example, but I am still not 100% sure about the procedure's frequency. Anyone?

(Yes, I know that for "big boy" applications with NLS/LC one can just turn off CDMD, unlike CWKR that should be retained, nevertheless I want to know).

EDIT: I might have found a solution that does not require the answer to the posted questions, nevertheless, I'd still be interested in feedback on this.

Dxxx (diag) routines usually run at 100ms intervals.
Scheduler is actually fairly easy to figure out. If the function reads "zzyl", it's likely to lead you to cylinder sync intervals.
Main load signal voltage (e.g. udss_w) will be written to by 1ms ADC.
"slow" periods (50/100/200/1000 ms) as well as "init" will be called from a list of offsets in the bin.
"fast" periods (sync/10/20) will be called by big functions with a lot of calls in them.
Etc.

P.S.
Just turning off misfire detection completely is not a "big boy" application, it's a crude hack.


Title: Re: Disable kr during nls
Post by: woj on March 16, 2018, 06:51:51 AM
Thanks a lot! This is in sync with what I see in the code and it parks me closer to what I want to know (and I have all these bin offsets / call vectors nicely defined), but I'd need to do some experiments to confirm the timings. For some other work I have identified the init and 100ms vectors, but never looked deeper as that was the only thing I needed. And I am probably guessing right that some of these call vectors are going to be alive only when the engine is?

Yes, I also like elegant solutions, but I did experience people saying "why you spend so much time on it, just make it go fast and forget the rest". Well, these guys later post "I have a X-mas tree of DTCs, what's going on" or "I blew my engine up" ;)

EDIT: If it helps anybody - looking for the family of AUFW constants gives you almost an instant answer as to which vector / procedure loop is which ;)

On my ECU: dwell times are calculated and used at crank sync (daah?), CWKR / B_kr is done every 10ms, not 100% sure about CDMD, but it seems to run every 100ms with other diagnostic procedures.


Title: Re: Disable kr during nls
Post by: TijnCU on March 18, 2018, 03:03:57 PM
Without overcomplicating things:
seg003:21EAC                 extp    #206h, #1
seg003:21EB0
seg003:21EB0 CDMDcheck:                              ; call to misfire disable here, replace cdmd with 0
seg003:21EB0                 movbz   r4, byte_CDMD
seg003:21EB4                 and     r4, #1
seg003:21EB6                 jmpr    cc_Z, loc_821EC0

Or this:
seg003:42EE6                 movb    rl4, nmot
seg003:42EEA
seg003:42EEA NMIDLUcheck:                             ; call to misfire disable here, you can even choose whether you'd like to
seg003:42EEA                 cmpb    rl4, NMIDLU      ; replace nmot with a low value or replace nmidlu with a high one.
seg003:42EEE                 jmpr    cc_C, loc_842EF4
seg003:42EF0                 bclr    USR0
seg003:42EF2                 jmpr    cc_UC, loc_842EF6


Title: Re: Disable kr during nls
Post by: woj on March 18, 2018, 04:00:37 PM
Did not get my head around the first option yet, the second one though - that's only disabling one of the detection methods (DMDLU - irregular running), isn't it? Is that sufficient?

In any case - good stuff, this should eventually get me to what I want.


Title: Re: Disable kr during nls
Post by: TijnCU on March 18, 2018, 05:33:08 PM
The first one is a bitwise check of the "Eurobyte CDMD". 1=misfire detection enabled, 0=misfire detection disabled. Not sure if it runs all the time, but the second one will be live during operation in any case.


Title: Re: Disable kr during nls
Post by: woj on March 19, 2018, 03:39:37 PM
OK, I now have identified B_dmdstop in the code with 99.9% confidence, and it looks like the one I should use. Unless somebody convinces me otherwise...


Title: Re: Disable kr during nls
Post by: gt-innovation on March 20, 2018, 03:35:16 AM
OK, I now have identified B_dmdstop in the code with 99.9% confidence, and it looks like the one I should use. Unless somebody convinces me otherwise...

why do you even bother with dmd? I mean it is good if you need to do things by the book but till today by writing directly to the ignition array or cuting the ignition i never had problems with Misfires. On the other hand b_kr needs to be manipulated in the most simple way. raise a flag in your lc algo and write a small part of code hijacking the bset b_kr  and bypass it when your flag is raised.

The deactivation of the misfire detection would be usefull when you make a rolling boost launch code.DMD needs to be manipulated definitely on MED9.1 as it will complain if you keep the lc active for some time.I do so but i have seen other tuners not even bothering which is funny as the random multiple misfires will come very very fast.


Title: Re: Disable kr during nls
Post by: woj on March 20, 2018, 08:58:33 AM
Tell you why I bother in general ;) In this thing:

http://www.nefariousmotorsports.com/wiki/index.php/Adding_anti-lag_launch_control_and_no-lift_shift

(I did not check the bin that this link points to, but took the hex code from the description) I think there is a bug in the code. If one sets the RPMThreshold for NLS lower than the LaunchRPM for LC then LC does not work, NLS takes over with its procedure when the car is stationary and the ignition is cut at RPMThreshold and only for CutDuration. I cannot do an experiment to show this, nevertheless, the code tells me so.

Thus, unless I double check things and do stuff my way, I cannot trust anything or anyone ;)



Title: Re: Disable kr during nls
Post by: gt-innovation on March 20, 2018, 09:44:09 AM

Explain to me please what does this has to do with the DMD ? Further more who said we(or i) use this code?
I specifically told you about "why" stopping the misfire detection as it is not giving any issues even when you keep the lc for 5 6 seconds active when you write directly to the "ignition Array"

I am giving you a hint but you seem to be stuck with the code that is published here....In any case stopping the misfire detection is good but kind of useless on me7.1 me7.5 as it does not complain on LC on the other hand med9 does.

if you don`t like the nls algorithm to get mixed with your lc add a vfzg > 10kmh check and you are done.

We all know the published code here has many issues but you are giving me the impression that you do no know what you are doing or searching for.

Trying to help people here is becoming harder and harder....


Title: Re: Disable kr during nls
Post by: woj on March 20, 2018, 10:53:20 AM
Man, let's not start another prj-style discussion, I apologise for not expressing myself correctly (I really had tough last couple of days) and for seeming not to listen.

I am listening and thanks for helping out. You say I should not be bothered about dmd, I gave the example of the code as something that tells me I should not just accept things and opinions without question (and yes, I know how to fix it, but thanks for the hint). Including the dmd. You say no issue on ME7.1 and ME7.5, but a problem on MED9.1. I do have something in between on my plate - ME7.9.10. So before it is tested, I will not know, and since I am not the one that will test the code and I will be throwing bins between myself and another person I want to minimise overhead and be dmd-off ready just in case.

Having said all that - my very question of whether doing it through the B_dmdstop flag is the right way is technically still unanswered ;)


Title: Re: Disable kr during nls
Post by: gt-innovation on March 20, 2018, 11:41:17 AM

As always there are multiple ways to do it but i have not seen the code of your 7.9.10 to tell you exactly.You can either make it ignore the misfires or not detect them at all. You can also manipulate the codeword that enables the misfire detection. It shouldn`t be that hard anyway to use on of those things since you have a good understanding.

As for the PRJ-style comment well you can refer to it once you contribute as much as he does.I am not responsible for what you write and what you try to explain and if it is not clear i will just assume.BTW i am trying to tell you how i do it on some occasions when multiple people here don`t even bother replying to you so don`t get offended.


Title: Re: Disable kr during nls
Post by: woj on March 20, 2018, 01:18:23 PM
BTW i am trying to tell you how i do it on some occasions when multiple people here don`t even bother replying to you so don`t get offended.

I am far from being offended, and to be honest I get more feedback on this forum than I would ever expect, from you and couple of other good souls :)