NefMoto

=========

I have this in my notes somewhere and meant to include it into the s4wiki but can't find it now, its been a few years :/

hopefully somebody can chime in and jog my memory

have you tried ESKONF TEV?

found this, ESKONF TEV probably wont help

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

I'll try ESKONF TEV tommorow and see if the warning is still present.

========

What engine was originally in the car?

2.0t 200hp TFSI, this warning is common problem after swap. It is needed to code out ldp properly.

I think it's a cluster issue - it guess doesn't recieve some kind of can info

Maybe search for a 1.8t rb8 cluster for test?

The cluster gets info of fuel tank leak. If I flash 551G the warning is gone. But AC has weird behaviours then...

Stop changing fault classes and remove the fault without changing them, and your fault will be gone.
This topic is a prime example of why any "CLAxxx" should never ever be touched.
This only hides the fault from OBD but does not change the conditions for the fault being set.

You did not change ESKONF correctly and that's why you have the fault.

Thanks for advice! Gonna revise my ESKONF and try again. Do You know what bits are for LDP in eskonf? TEV is defined on s4wiki, but LDP is not for Mbox

Changed CDTES CDLDP and ESKONF TES and AKF(Its stock off in Gbox). Unfortunately the warning still persists...

Revert your fault classes to stock and pull the codes.
Change ESKONF via trial error until you find the bits that turn off the code.

I tried this before and could not figure it out (years ago, though, so my memory of what I tried is vague)

If somebody finds the correct combination of ESKONF please post (especially for 551M/L), thanks.

Perhaps trev's swissarmy knife can help

Resurrecting this from the dead to provide a solution for M box ECUs which can probably be applied to other ECUs with similar conflicts.

Had a customer recently with a B7 swapped 2.7T that had this error present.

In my case, as some of you described above no combination of ESKONF or codewords cleared the fault in the dash. The error message is being sent via CAN to the cluster, through MOTOR 5 $480 on Byte 6 specifically. After a bit of time reversing and finding the payload creation of $480 it took a few revisions to narrow down which byte we needed to target.

Simply removing the write to the 6th byte of the $480 CAN message was enough to rectify the dash error for "close fuel cap".

As one of you mentioned, the G box ECU didn't present the error (D box also does not). This is because it is not sending this byte and the cluster has nothing to freak out about.

Here is the solution spoon fed.

Stock MBOX 0002:

F7 F4 1D F8                 movb    byte_F81D, rl2

Modified:

F7 8E 1D F8                 movb    byte_F81D, ZEROS

Hope this helps someone,

Christian

This is patching the CAN, not the cause for it.

PMAXKBI is what is contained in that byte and loaded by the Mbox firmware.

It’s sent out once more in another ID very near.

This has nothing remotely to do with error reporting for the reed sensor. Yet it throws the reed sensor fault in the cluster. I would argue that given the difference in years this would be an acceptable method to rid this error instead of having to switch to another firmware which doesn’t report that byte anyways.

Always open to debate, I just don’t see how that error isn’t a false positive with how the cluster is interpreting the data from that specific CAN message.

It is very likely you can also just zero out PMAXKBI, if it is a CAN matrix incompatibility.
I have not looked at it.

Yes, that also does work. I was just trying to preserve the usage of it elsewhere which is why I opted for only that change in code. Thanks for your input!