NefMoto

Im experiencing a wierd lean condition at WOT, after around 4500rpm the MAF reading goes down and the actual AFR leans out.

Here is a log, WOT in 3rd starts at row 480: https://docs.google.com/spreadsheet/ccc?key=0AlddzLucZT07dEU3UmYta0VKbms5TWl6b3YydFlWcUE (https://docs.google.com/spreadsheet/ccc?key=0AlddzLucZT07dEU3UmYta0VKbms5TWl6b3YydFlWcUE)

2002 Audi A4 1.8t, returnless:

HTA2868r Eliminator, ported
Ported BEX manifold
Ringer Racing 1000cc EV14 Single tips
S8 4.2l 3.5" MAF
Maestro 7
BSR 1.5bar Boost guage
D1 Spec catch can, -10an lines
Black anodized Evolution Racewerks Competition FMIC, custom piping 2.25"/2.5"
Custom 3" downpipe with 100cel race catalyst
Ferrita stainless resonated /w 3.5" tips
Aluminum piston type DV
ECS snub mount
Stern soft motor mounts
Stern transmission mount v2
Apikol soft rear diff mount, billet version
Clutchmasters FX400 6-puck
Clutchmasters 240mm 19lb steel flywheel

I have pressure tested the system at ~1bar, I have tried plugging all ports on the TIP(evap, ccv and plugged DV) as my first thought was air leak post-MAF pre-turbo since the boost doesnt drop, none of that helped. I had this exact symptom when I was still on stock turbo and stock MAF, rest of the setup was the same except for turbo/MAF. I was pretty sure it was my stock TIP collapsing and I never attemped to fix it since I was going to swap in my bigger turbo and MAF.

I have not verified fuel pressure yet, but to my eyes it does not look like im running out of fuel, though im not ruling it out. The fuel pump/filter is stock and was changed less than 2 years ago.

I have a feeling this could be software related, but im stuck, I cant figure out were to look.

I was out to take a new log today, to trace back in the diagrams. I logged uhfm_w, mlhfmm_w and mshfm_w.

Here is a graph of those + boost and fuel against RPM:
(http://img855.imageshack.us/img855/6582/stg3rev103graph3.jpg)

The MAF actually reads the air entering(mlhfmm_w is following uhfm_w), as seen here in the graph, but something is interfering.

The only thing that according to the FR should be modifying mlhfmm_w is KFKHFM, since sy_turbo=1 the fpuk is = 1, and my KFKHFM is all set to 1's.
(http://img843.imageshack.us/img843/3523/gghfm.jpg)

Im stuck here, I have looked at MLMAX but from what I understand it is not limiting/interfering with mshfm_w. I have also looked up KFMLDMX, and that map is only for diagnosis, setting a MAF reading too high flag.

Im not 100% about MLMAX/KFMLDMX, please if someone knows more, do give me a hint :)

Here is the log I made the graph from: https://docs.google.com/spreadsheet/ccc?key=0AlddzLucZT07dDgySXB4Z09WQVc4MzRiYWZ0SU5YeWc (https://docs.google.com/spreadsheet/ccc?key=0AlddzLucZT07dDgySXB4Z09WQVc4MzRiYWZ0SU5YeWc)

I doubt it is the tune. If it is, you'd see it in injector duty cycle

You're running out of fuel (bad injectors, failing pump, etc)

How would I see it the injector DC?

My understanding is that rk is calculated from load, and rl is calculated from airflow and RPM? Since mshfm_w is dropping, so is the load and thus the rk goes stupid lean since there is still actual airflow(mlhfmm_w).


Ok, lets assume my pump is bad and pressure drops. Why does the mshfm_w start to drop?

It is pretty obvious(at least to my eyes) in my logs, that the AFR goes lean because the airflow reading goes down.

If possbile measure block 2 for injectors duty cycle.

Here is injector DC against AFR's:
(http://img687.imageshack.us/img687/6686/stg3rev103graph2.jpg)

The peak before the dive is 38% DC.

EDIT: Updated the first graph with Injector DC also.

Wow. You're right. That is extremely odd. I don't see your MAF dropping low enough to cause that kind of injector cut.. Some thing else is going on. I've never seen that much fuel cut.

Don't forget, though, your load is supposed to taper down with rpm after peak boost (although MAF should not)

Also, please post the original CSV so I can run it through ECUxPlot...

Yes I find it really odd too, I cant get my head around it. There is something that holds it back, between mshfm_w and mlhfmm_w.

One thing I noticed now is that my actual load is 10-15% over requested when this happens, maybe all this is an action to bring actual load down?

I have attached the log I made the graphs from, let me know if there is anything else you want to see.

your MAF is taking huge dive, which is causing you to go lean two ways

1) your load drops off a cliff, sending your req lamba into a low load region (lean)
2) injector drops because the MAF is dropping.

If i had to guess, i'd say its a DV problem.

Yup, exactly my thoughts aswell :) I have tried running with the DV jammed shut without any luck, I guess I can try to completely remove the DV and se if it makes any difference.

However, I think I have found the root cause to this. I found this alternative GGHFM diagram:
(http://img16.imageshack.us/img16/8006/gghfmv2.jpg)

I will get a new log tonight to verify this.

DV is not leaking, pressure tested the system at 1.5bar, no leaks at all.

Did some more logging, and have found the cause:
(http://img18.imageshack.us/img18/6663/fkhfmfail.jpg)

This is my current KFKHFM:
(http://img18.imageshack.us/img18/3829/kfkhfm.jpg)

I cant understand what is wrong?

[edit]

yes that is very very strange :/ Either the FR is wrong, and is missing another correction factor, or you aren't logging what you think you are :/

I think you'll need somebody here to disassemble your bin to find out what else can affect fkfhm

Yes, I will go through the FR obe more time, if I cant find anything thats my only hope.

Do anyone happen to have any names of people I could contact for disassembly? Maybe I need to learn to disassemble myself.

I have noticed that this correction seems to happen when actual boost > requested boost, if anyone want to take a look I have attached two logs.

Seems strange if the ECU wants to correct boost overshoot with scaling the MAF reading down, no?

What is the RAM location of FKHFM?

This is from the setzi logger generated .ecu file:

fkhfm, {}, 0x380A0C,  1,  0x0000, {-}       , 0, 0,    0.0078125,      0, {HFM-Korrekturfaktor}

Here is a link to my .bin:
http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=1103.0;attach=1399 (http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=1103.0;attach=1399)

0x380A0C is converted to 16 bit and put in 0x381F72 which seems to be used for some sort of recursion algo.

Ive not got the the bottom of it quite yet. I guess there is a few things we could do to stop it doing it, or to chase it to find the cause.

Thank you for looking at this! I hope one day get to learn how to do this and contribute back.

It so strange, logging fkhfm variable should only show 1 at all times since my KFKHFM is all 1's at all points.

Let me know if there is anything I can do.

Can you email me the actual file that is making these logs please?

Since I am using Maestro the file is encrypted(?), but I can mail it to you if you want to take a look.

I think I am on to something:
(http://img577.imageshack.us/img577/4457/cwfkmsdka.jpg)

This codeword is set in my binary, and it is a very long diagram, but I have the end variables and I will take a log with those:
(http://img33.imageshack.us/img33/4350/fkmvariables.jpg)

CWFKSDKA is not set in s4's, rs4's or other 1.8t files I have. I really do hope this is what causing my condition, but if it is I will have to go over to the dark side and ditch Maestro(well, this is only a question of time before I have to).

Im a little anxious to begin flashing with NefMoto and editing with Winols, not that I dont think its working, but Im getting a bit paranoid since I dont have the tools at hand to recover a bricked ECU. Is Winols checksum corrector considerd safe? I have tested it once by altered a file, correct it and run it in the Setzi checksum checker with success. I have heard stories about the MTX plugin not correcting everything as it should..

Going roadtrip tomorrow, and I really would like this to be solved before. Ahh decisions...

Get boot mode tools first.

really interesting!
the only reason according to FR fkhfm can differ in your case from 1 is your sy_turbo state, did you check that? (i know it's weird!!).

SY_TURBO will not change the state of fkhfm.

The fact that you are using M7 could be the cause of this, the fact that you dont know what they are doing to the file. Ive disassembled the stock file and it matches the FR, only 2 things can change fkhfm. KFKHFM, and init. value of 1.0

Winols is used by all the big tuners and is the most trusted tool in the industry.

Thank you for confirming this, thanks very much. Now I have no choice but go winols instead.

I would be very interested to pull the file on my car now and have a look at it in Winols, is there any way of doing this without boot mode? I assume my file in there is non readable

The fact that you can read RAM values shows that the file can be read, maybe not using standard protocol, but it can be read.

ugh. I wish you'd mentioned that it is M7 earlier. Just write your own file and get it over with.

I will head out to the garage and give it a try with Nefmoto, I hope it works  :)


I listed M7 in my first post ;)

Im currently in the process of transferring my tuned maps from M7 to Winols, I really like the version tracker/comparation in winols actually.

Galletto cable is ordered also, thanks everyone for your help, I really appriciate it.

Bische, apologies i must have missed it.

In any case, i think you are FULLY capable of doing this 100% on your own without M7 :)

Please let me know if I can help in any way.

NP man :)

Yeah I dont doubt I can do it, my fear is if something else goes wrong and brick my ECU. Normally I would not care to brick the ECU(I know I will brick it at some point, and deal with it), I can take my bike to work lol, but tomorrow I need to have my car running. Highly preferrable without this MAF condition.

Tried to read the ECU with Nefmoto and got the aftermarket tuner lockout message.

EDIT: I also mailed Tapp to see what he says about this problem.

Read by protocol will be blocked.

Do you have any tools that will read in boot mode?

I know we can find the problem if you can get the actual file.

No I dont have anything to read in boot mode, I just ordered a Galletto though. I know reading over OBD is possible with such files, I had another tuned file on my ECU(which had the block) when I read it with the M7 Flasher...

There must be something out there to read these files outside boot mode.

Just get a spare ecu :)

Forget about reading the M7 file, it isn't worth your time.

I am 100% confident in your abilities.

Tapp says nothing is wrong with the file.

I noticed there is a /V beside KFKHFM in this diagram:
(http://img16.imageshack.us/img16/8006/gghfmv2.jpg)

What does that mean? I cant find anything in the FR the describes it.

If your KFKHFM is all 1s, but fkhfm is not 1, i'd say either

1) something wrong with the file (i.e. doesn't match FR)
2) KFKHFM isn't where you think it is
3) fkhfm isn't where you think it is

I totally agree, I have verified 3). I don't think M7 shows address'? so 2) can not be verified, although it is at 0x10DA0, In the case of 1) the stock file does match.

Of course he is going to say there is nothing wrong with the file, but you have evidence to the contrary.

I say stop using the M7 junk and write your own file.

Do you have a list of all the maps listed in M7? I bet they can all be found in the stock file inside of 30mins.

1 That is something I cant verify atm
2 I have adjusted KFKHFM in this file earlier with success
3 The mshfm_w and rl_w is following the fkhfm correction very accurately in my logs

4 The FR diagram does not apply to this file, I found two different diagrams of the GGHFM module, there could be a third. The FR copies I have was written in 2000 and 2001, my ECU is 2002.

Something I have noticed is that my load is higher than requested when this happens, about 20% higher than rlmax_w when fkhfm starts to correct.

I have already defined all maps I have tuned in M7, in my .ols. I learned/did that while I was waiting for my M7 basefile lol

Holy f

I just noticed the software number from my M7 file != my stock binary I sent Tapp....

what is it?

I believe I have a copy of your ori software on my home pc. If you would like I can dig it up and post here when I get back. Pretty interesting thread...

Edit: 8E0909518M   0261207778    1037363466

Located here;

http://nefariousmotorsports.com/forum/index.php?topic=1103.0

Yes that is my stock binary, software number on my M7 file(which is supposed to be my stock binary) is: 1037363052

I dont know for shit what file I have in my car. ::)

Edit: Did a quick search, it is another revision of software for my ECU. Probably the 0001, as the file I have is 0002.

Oh, gotcha. Yeah, I have no experience with M7, but from everything I've seen/read, I think it's high time you joined the dark side....

SY_Turbo will change the init value of 1 and therefore fkhfm.

but i never heard of M7, so that will be much more likely.

No it wont.

In the FR and in code the initialisation value is locked to 1.00.

SY_TURBO has no control over fkhfm in ANY condition. It simply changes what fkhfm is multiplied by.

If SY_TURBO is true  then mshfm_w = (fkhfm * 1) * (mlhfmm_w - MLOFS)
If SY_TURBO is false then mshfm_w = (fkhfm * Fkup) * (mlhfmm_w - MLOFS)

In this case SY_TURBO is true, so in short and in code we have:
mshfm_w = fkhfm  * (mlhfmm_w - MLOFS)

SY_TURBO changes how fkhfm is used, but NOT its contents.

SY_TURBO is a compile time option, and as it is set in the file in question, any code to do with fpuk is simply not there.

Here is the initialisation of fkhfm(byte_8A0C) being set to 1.00 (0x80)
sub_6846C:
6846C                 movb    rl4, #80h
68470                 movb    byte_8A0C, rl4
68474                 rets

Here is fkhfm(byte_8A0C) being filled with the contents of KFKHFM (0x10DA0), yo can also see a 16 bit equivalent(word_9F72) value is also created.

sub_68476:
68476                 mov     r12, #0DA0h
6847A                 movbz   r13, byte_F89C
6847E                 movbz   r14, byte_F9B5
68482                 calls   0, sub_7312
68486                 movb    byte_8A0C, rl4
6848A                 movbz   r4, rl4
6848C                 shl     r4, #7
6848E                 mov     word_9F72, r4
68492                 rets

This is the ONLY 2 places in code(original file) that byte_8A0C is written to.

impressiv!  ;D

but I simply meant fkhfm after multiplication with 1 or fkup.

I am aware that sy_turbo is a compile time constant but I did not know that the code for Sy_turbo=0 is missing.
and the code is ignoring the init value 1 and does not multiply?

the code you examined is 100% the one Bische drives?

Thanks, but it is simply just following logic and code.


Ok i see


Thats just what happens with compile options, the part of the option that is not needed, is simply missing.


The initialisation value of 1.00 is always run


It is of the stock file that his file is made from, that is the problem. It is not the exact file that is in his car. Which is why I am saying that M7 could be the cause of this.

for me I compared Sy_Turbo with e.g. Sy_Wmin and Sy_Wmax which are simply asm #constants built in the code, than compile options.
of course you can have compile options that use system constants.

I am only at the beginning to understand my disassembled me7 binary.

there are several points where I would expect more Xrefs to a Variable than I see and I guess some may be accessed indirectly?

Some things are accessed by subroutines where the addresses are passed as parameters.
For example the DPP could be passed as one parameter and then address as another, then you will not see the XREF, etc.

it makes things not easier ;)

BTW: there are Me7 versions around that also use a 2nd HFM correction factor called fnwhfm (derived from a 3D Map Pulsation/NWS) which I did not find in any FR.

Why don't you ask Chris Tapp if you are using Maestro?

Do you happen to know one that has this?


I have. He stopped responding when I told him I have had my stock file dissassembled and verifyed and the fact that he has given me the wrong file.

My Galletto cable should show up on wednesday

Ok, I got the file version Tapp sent me. This was the stage 1 flash I had on my car before, that he then reverted back to stock, and sent back to me to me.

SW# 1037363052

I post this if anyone want to take a look and maybe verify the cause, it is NOT CHECKSUM'ed.

Let me get this straight, he reverted a tuned file that you sent him back to what he thinks is stock and then he used that?

The only differences to between the 2 files is map changes, and checksums. All routines are identical.

One is simply and update of the other.

Yes


Ok, thank you for confirming this.

Not quite sure what to do next, I will try to 0 CWDHFM at least, see if that does the trick.

I still do not understand 100%:

this "m7" makes it impossible to read the flash image and you are forced to use the m7 application to modify (a subset of) parameters defined in m7?
and it still could be possible that your KFKHFM is not completely "1" in your Flash ROM?

Maestro 7 is a device that allows the end user to "fiddle" parameters set by someone else. IT contains a flash loader and an editor of sorts. Think of it like winols + damos for dummies.

Any movement of the file is encrypted and it does not show any real addressing.

It is more than possible that any of the parameters defined are completely wrong.

M7 also places code mods into the file, which again could be causing anything.

The file can be read, but not with any tools that OP has.

It is a tuners interpretation of how a file is set out, using definitions created by them. The whole thing is totally open to miss-understanding and confusion, through no fault of the end user.

Alright, my Galletto showed up today and now im running my own file written in Winols and flashed with NefMoto flasher :)

The condition seems to happen around 5000rpm, a little sooner in high load and a little later on low loads. If I just rev the engine it happens around 5500rpms. Im thinking it may have something to do with cam change over.

Attached the actual file im running now.

LOL, I think I actually found it:
(http://img526.imageshack.us/img526/8023/kfkhfm2.jpg)

I shifted the KFKHFM 1bit in that pic

Tapp was confident it wasn't his file? :)

Lol, sucks he just stopped responding after Bische said he was taking the initiative to figure out what's going on. That's not right, nor is it fair.....

Totally agree, there was 3 options listed above as to what the problem would be. I knew because i pulled the stock file apart. And now that we know what it is, the shape of the graph makes total sense too.

I'd be asking for my money back politely.

^^Me too.

The way I see it, the only chance that Chris has of keeping M7 alive is by working WITH his customers, not in secret. I really think if he made his product more openly available to the end user (along with being more affordable!), he could get gobs more people to jump on. Not many people (besides Nef members of course), want to deal with WinOLS, Tunerpro, making def files....etc. I'm sure he reads this site, it's a shame he doesn't contribute.....well deliberately contribute anyway, lol. I know some of his work is on here, and has enlightened some of us;) (thanks Chris! ;))

Edit: sorry--- end rant...

Im sorry to say this did not solve the problem either  :(

If anyone has an idea please let me know, any idea at this point is a good idea.

Is it possible through disassembly to see what addresses the ECU is looking for the KFKHFM map? It would be nice to verify the map/axis addresses at this point.

ditch M7, done :)

I already have  :P

Im running my own file now.

sub_68476:
68476                 mov     r12, #0DA0h         Map address @ 0x10DA0, using bosch 8 bit structure
6847A                 movbz   r13, byte_F89C    Y Axis 8 bit rpm (axis data starts at 0x10DA2)
6847E                 movbz   r14, byte_F9B5    X Axis 8 bit load (axis data starts at 0x10DB0)
68482                 calls   0, sub_7312           map routine
68486                 movb    byte_8A0C, rl4     Put the 8 bit result in 0x380A0C ram location (fkhfm)
6848A                 movbz   r4, rl4                convert -
6848C                 shl     r4, #7                  - to 16 bit
6848E                 mov     word_9F72, r4     Place 16 bit value in 0x381F72 ram location
68492                 rets                              End of routine

Following on from that, the initialization of fkhfm


sub_6846C:
6846C                 movb    rl4, #80h ; 'Ç'    Move 0x80 (128dec, correction factor of 1)
68470                 movb    byte_8A0C, rl4   in to ram location 0x380A0C (fkhfm)
68474                 rets                            End of routine

Ok, I have found your problem

look at address 0x10DA1, this is 0xE as stock, ie 14, you have changed this to 0x14,  ie 20 decimal, you have changed the table from 14x14 to 14x20 by acident.

Just as a test try putting EVERYTHING to do with that table back to stock and run again.

Edit: This is looking into the file you posted above.

LOAD  17    18      29    39     50    59     69     80     89      98   108   117   128    113
------------------------------------------------------------------------------------
  800¦128   128   128   128   128   128   128   128   128   128   128   128   128   128
  960¦128   128   128   128   128   128   128   128   128   128   128   128   128   128
 1120¦128   128   128   128   128   128   128   128   128   128   128   128   128   128
 1760¦128   128   128   128   128   128   128   128   128   128   128   128   128   128
 2400¦128   128   128   128   128   128   128   128   128   128   128   128   128   128
 2880¦128   128   128   128   128   128   128   128   128   128   128   128   128   128
 3520¦128   128   128   128   128   128   128   128   128   128   128   128   128   128
 4320¦128   128   128   128   128   128   128   128   128   128   128   128   128   128
 5280¦128   128   128   128   128   128   128   128   128   128   128   128   128   128
 5920¦128   128   128   128   128   128   128   128   128   128   128   128   128   128
 6880¦128   128   128   128   128   128   128   128   128   128   128   128   128   128
 8000¦128   128   128   128   128   128   128   128   128   128   128   128   128   128
 8960¦128   128   128   128   128   128   128   128   128   128   128   128   128   128
10080¦128   128   128   128   128   128   128   128   0   10   25   255     1   0
 5120¦88   38   100   10   0   10   10   3   26   100   14   50   71   20
 5120¦0   5   25   38   48   58   64   128   128   128   128   128   1   4
 5120¦6   1   12   4   24   31   37   44   51   57   64   91   117   144
 5120¦184   211   3   13   19   25   0   0   0   0   0   0    0   0
 5120¦0   0   0   0   0   0   0   0   0   0   0   0   0   0
 5120¦0   0   0   0   0   0   0   0   0   0   0   0   0   0
 RPM
Is your resulting table, with varying messed up axis data. :)

Id say you have a problem at about 5120rpm and high load? ;)

LOL I just discovered this myself and was taking screenshots etc to put up here!

When I open the thread you had already shown the problem :)

Thank you for all your help matchew! I will verify this tomorrow, if time permits.

awesome thread and knowledge included! I like it.

question:

how does M7 treat the 16 Bit values compared to 8 bit. are there some fixed rules?
I would expect to shift it 8 bits in order to have some calculations with 8 bit fixed comma??

Did you have a chance to test yet?

Just came back from taking some logs, SUCCESS!!!!

Thanks big time everyone and specially matchew, now I can finally start dialing in my car :)

I guess after bad things come good things, if I never had this problem I would still be using M7. Im really satisfied with running my own file now, being able to access everything I want to, in my ACTUAL file.

Thanks again.

EDIT: I still cant get access to take logs with NefMoto, still that security message for some reason?

Grats! Glad to hear you made the jump to do your own stuff. Thats the tricky thing about M7 imo... once you are smart enough to get M7 to do what you want it to do, you pretty much have the knowledge to do your own file...

Excellent :)

I entirely agree. The grass is a little greener on the other side ;)

Here is a 3rd gear pull: http://youtu.be/nmIP7GP_GDk (http://youtu.be/nmIP7GP_GDk)

Log from that pull: https://docs.google.com/spreadsheet/ccc?key=0AlddzLucZT07dGcyaWQxYUlhWHcyTlV2dVlxUWl2akE (https://docs.google.com/spreadsheet/ccc?key=0AlddzLucZT07dGcyaWQxYUlhWHcyTlV2dVlxUWl2akE)

I did flick the gas mid-pull, as my boost did overshoot some.

pull some I limit and get a proper log.

post the original csv

run it through ecuxplot.

Tune the boost request to be closer to reality in the lower revs, this will give you a better place to start from when trying to tune the boost control PID.

not sure that is a good idea (IMO), you'll affect spool rate if it is too low.

At lower revs, you want two things

1) keep the req boost low enough to prevent positive deviation.
2) keep the req boost high enough to prevent the PID from cutting WGDC from 100% during spool on WOT

If you can't do both, you may have to tweak a few other maps

http://nefariousmotorsports.com/forum/index.php?topic=871.0title=

Depends if he wants to tune all the factors of boost control correctly, which is what should be done when changing turbos.

I personally would totally tune all factors of the PID control. Not just rely of the I-term limiter. You can see that the PID is out of whack by how far away "stable" boost is from request, and how "stable" it is, also by how far it over shoots (this has more to do with than just the I-term limiter)

Horses for courses, it was just a suggestion.

The most difficult region to calibrate the PID for is where actual is about to cross req until the higher rpms when req is stable.

Not sure what you meant by "low revs". If you meant that region, I agree. If you meant during spool, then i disagree ;)

Thanks for the quick tips, I did pull out about 10% on the I limit near the point where actual boost meets requested. Also lowered requested load under 3500rpms.

I feel I first need to learn how a PID controller works and trace the diagrams in FR back and forth a few times :)