NefMoto

I've been having trouble getting the Flasher software working with my car; thought I'd ask and see if anyone has some tips

- VW Passat 1.8T B5 (Euro), APU Engine
- ECU: 4B0906018AA/0261206449
- Using either genuine HEX-CAN VCDS cable (set to dumb mode), or clone from easybid2000
- Trying with Nefmoto software since some time back with 1.5.x.x; currently trying with 1.6.1.0
- Running inside Virtualbox

Essentially, I'm unable to reliably read from the ECU, and am currently thinking I'm being an idiot and not finding the correct fuse to disable the instrument cluster

- I can reliably connect to the ECU with the ignition powered off (but can't read then due to preconditions not being met)
- I can occasionally connect to the ECU with the ignition powered on; then, only at the slow baud rate, and with slow init (very hit-and-miss as to when it'll connect correctly)
- All VCDS functions work as expected

I've gone over both the Bentley and Haynes circuit diagrams, and pulled what could be the relevant fuses (either 5 or 15), with no discernable difference.  Same effect is seen with car on or off charger.

I'll pull some logs later on today, but maybe somebody has a pointer to a fuse/relay I'm missing due to short-sightedness?

(as a side note, I've been able to successfully pull an image via Galletto, in-car).

Pulling the fuses is only for power conservation. The ignition needs to be on (not started just power on) to power the ECU. Are you using the correct memory layout? Are the buttons activated on the flashing software? Post logs and I am sure Tony or some of the more experienced members will be able to help.

Yep, either the 29F800BB or 29F800BT layouts will validate correctly.  Obviously haven't got as far as trying to write yet, but I'm aware that both of those memory layouts will "verify" OK, but only one will be suitable come write-time (as per http://www.nefariousmotorsports.com/forum/index.php?topic=258.0title=)

Buttons are available once I can connect to the ECU; it's getting connected reliably that's the issue.

Logs coming up later, once I get home.

Log files attached; one for connecting successfully with the ignition off (albeit unable to validate memory layout, or read flash, as would be expected), and one with the ignition on (unable to connect at all, with any combo of baud or init speed).

My comments begin with ###.

Any DTCs appear to be turning up as a result of me pulling various fuses along the way; they don't reappear minus my clumsy fiddling.

For good measure, here's a log I found of when I was able to successfully connect to the ECU (ignition on etc.), validate the memory layout, and start reading the flash.  I didn't believe it at the time, so cut the session short to see if I'd be able to reconnect, but no dice.

Wow, I thought that never somebody would show up with similar problem!!
From your desription it sounds to be related to what I am facing.  I'm fighting with
KWP2000 communication problems, also in a Passat B5 Euro, already a very long time and
never found out what is causing this. This is driving me really mad  :'(.

I see the following:
Ignition off (the ECU keeps running for 10-15 minutes after turning ignition off):
- Slow init and fast init work fine, communication with KWP2000 protocol is perfectly. I can
  send and receive small and big messages and also the comm session keeps active if I send
  at least each 5 seconds a message.
From this result I think I can exclude any problem with the used PC and the interface cable
or the software.

Ignition On:
1) VCDS functionality is working fine (using KWP1281 protocol).
2) Fast init does NOT work, NEVER got a response to the startCommunication message.
    (with a patched image I could show at least that the fast init pulse was recognized, so it's
    not the 25ms timing)
3) Slow init works fine, also communication works fine at first.
4) Communication drops "randomly": suddenly for the next request no response is received
    (not a single byte), also for further requests no response, until the session is started
    again with slow init.
5) I never faced checksum errors or undecodeable responses, only this stop of
   communication from ECU's side.
   The problem appears with different interface cables and when using different PC's, so I
   again exclude an erroneous interface (also, the comm is perfect when ign off!).
6) I found that KWP2000 communication was stable when using response messages of
    only <=32 bytes and when keeping the gap between response and next request shorter
    that roughly 250ms (using the 5 seconds timeout was definitely not working!).
7) After starting a programming session, I still had at first this unstable communication.
   But after letting the session time out and then reconnect to the programming
   session/ram system, I have stable KWP2000 communication with 5 second timeout and
   no errors (as with ignition off).

When running a simulation, I could not find any hint that the ECU would stop actively
communication in the way it is seen in the car (but simulation is without the incoming CAN
messages from other units).

I can currently think of two things:
a) The ECU receives messages via CAN which cause this problem when ignition is on. This
    would mean it is an intentional behaviour of the ECU (no idea what for besides driving
    people mad  >:()??
b) The K-line is disturbed by other units on the line which are powered off when ignition is
    turned off. (but why are they not disturbing if the ECU switched to programming
    session?)

Is this all a bug or intention???
Anyway, I'll keep on searching to find the root cause of this behaviour and would be glad to
hear also if you have a "break-through" with this strange communication problem.

Thanks for the log files. Here are some of my thoughts...

I have been told by many professionals that deal with VAG ECUs to not bother with fast init, because it is not properly supported on most VAG ECUs. They recommend always using slow init.

I should probably try doing a slow init to address 0x11 after multiple failures to address 0x01. Currently I only try address 0x11 after getting a successful response to address 0x01. This could help...

Some of the VAG flashing documents recommend broadcasting the "Mute" command before running the flashing process. This command is meant to tell other modules in the car to stop transmitting so they don't interrupt the flashing process. None of the ECUs I have looked at though handle the "Mute" command though, so I haven't implemented it.

On all ME7.1's and ME7.5's which I have looked at, the fast init was always implemented in
the code, and on all ecu's in the same way.  If fast init is not working it is most probably
due to incorrect timing of the tester (or it's something like the problem I face with
ignition on). The most crucial thing is the correct timing for the wakeup pulse before the
startComm message is sent. When I was testing fast init with a microcontroller (exact
timing), the wakeup worked fine.

This "mute" command sounds interesting. I would like to give it a try in my environment.
Can you provide more details, I never heard about this command before. Maybe I should
have seen it in some document already, but don't know where to look.

The "mute" command is described in the document in this thread:
http://www.nefariousmotorsports.com/forum/index.php?topic=95.0title=

I found that fast init worked on the 2000 and 2001 Audi S4, but would not work on the 2002 S4. I verified all of the timings were accurate to the millisecond with a logic analyzer. The KWP2000 spec suggests that the fast init timings should be accepted plus or minus 1 or 2 milliseconds if I recall.

I also found that some ECUs had problems entering programming mode after a fast init, but with a slow init they happily entered programming mode. The ECU would seem to go into an infinite loop trying to enter programming mode with fast init.

One thing that may be related to this, is that with slow init the ECU specifies that it doesn't want the source and destination address information in the message headers. But if you use fast init, then the ECU specifies that it does want the source and destination information in the message headers. So the communication protocol is actually more efficient if you use slow init, because then you can save two bytes in the header of every message.

Tony, thank you for the link to the document. Now I remember that I already had a
look at it some time ago. But seems like the "mute" command is used only when
flashing ECUs via CAN/TP2.0.

What you found about the fast init is also very interesting.  Which image was the 2002 S4
that does not allow the fast init?  I have a 2002 VW image with fast init also not working
with ignition on, but it is fine after turning off. In simulation, fast init works always fine
and the code shows no reason why it should not work always.
I'm going mad to find out what the hell could prevent using reliably the fast init!

Regarding the infinite loop on turning on programming mode: I saw this happen when
trying to start a programming session while ignition is turned off.  The ecu was sending
responsePending endlessly (a bug in the ecu's communication software).
Could it be you had same conditions when that happened after fastinit?

I wasn't able to start fast init with the 2002 B5 Audi S4 8D0907551T.

The infinite loops I saw were with "ConditionsNotCorrectOrSequenceError" responses I believe. I can't remember the exact situation that caused this, but I think it was more likely to occur with the 2000 B5 Audi S4 8D0907551A.

Just wanted to bring this up again, since I could fix the communication problems by installing
an extra wire from the ECU to the tester!
I installed a relay to be able to disconnect all controllers off the K-line except the ecu.
When I have only the ecu on the K-line, communication works perfect!  Even fast init is
possible without any problem  :D :D.
It must have been possibility b) from above, maybe I spend some time in future to find out
which module disturbs the K-line.

In  http://www.nefariousmotorsports.com/forum/index.php/topic,271.msg1510.html#msg1510 (http://www.nefariousmotorsports.com/forum/index.php/topic,271.msg1510.html#msg1510), same thing was mentioned:
Rick, did you give the extra wire a try?


Wow, finally I can start to test some things and take logs from the car this weekend  :).
Thought this would never happen.

Thanks for sharing what you found. I wonder if there is a special command that the NefMoto software needs to send to tell the other controllers to stay quiet. Maybe we could check what ECUx or VCDS due to start the connection.

I assume it is also possible that limiting the message size to 32 bytes, and adjusting the message timings could also resolve the issue.

I could not establish any form of communication in car, slow or fast innit. 

I have now run another cable as described which isolates the ECU.  Result is perfect fast and slow communication all the time.  No idea what is causing the problem.

Rick

I see you folks made some decent progress since I last checked in.  I'll pull out my Bentley manual over the weekend, and see if I can make a map of modules hanging on the k-line (given we're seeing the same issue on both US and EU models, the Bentley diagrams should include the right info nonetheless).

Version 1.8.0.0 of the ECU flasher has better connection and communication noise recovery. Hopefully that fixes the issues. Version 1.8.0.0 should be released in the next day or so.

Connection is solid as a rock now; thanks!

Which leads on to the next odd issue; it won't validate the memory layout.  Just popped the case on the ECU; the flash chip is an AM29F400BB-90SI; alas, the 29F400BB memory layout refuses to verify (neither does the generic layout).

For a giggle, I tried validating the 800 layouts; all pass at the validation stage.  However, they fail once the flash readout gets to ~62%, due to checksum mismatch after downloading a sector (I need to get a fresh log of the failure at that point, just for curiosity about the validating routine passing, and also to see exactly where it stops reading the flash).

All the layouts included with nefmoto flasher have a base address of 8388608 (0x800000); any reason to believe it might be different on this ECU?  Seems unlikely though.

exactly the same issue here.
I tried to read out my a4 b5 1.8t ANB ME7.5 Audi Partnumber 4b0 906 018AL. Read out with 400BB layout not possible, with 800BB works, but produces checksum errors after 63% read...
What are we doing wrong ?

Buergi

Hi all,
Ok, after some further reading i split my file into two of 512kB and checked it with me7check checksum utility. First 512kB appear to be good.
Can somebody please check if that file is ok ?
My goal is to modify the engine to decently run  (without throwing codes) with E85 which is currently the cheapest available fuel here...

Regards,

Buergi

Nefmoto won't work with older cars (2000 G/J). You must unplug instrument cluster fuse in order to communicate with ECU.

Of course that gets conditions not met.

Another bug I have seen is that I can't get past a 5% read...
Just hangs at 5%

Attached file is 100% original and OK

It is quite strange that the 400BB memory layout will not validate. The NefMoto software is asking to read memory from a range above the end of flash memory which should fail but doesn't. What happens if you just continue reading with the 400BB layout after the layout validation fails?

Can you post a communication log of the ECU reading that starts getting checksum errors at 63%?

i can`t connect to ecu on same car
error on message 0x01

I have the AA version of the ECU and although we can pull the ori file on a bench, it fails to communicate the Bosch 020 number. My tuner says that he has seen this before on the same numbered ECU and it seems to display some dicrepency on the memory size for some unknown reason 512/ 1mb.

Is there a specific problem with this type of ECU?

Here's a few logs, of attempts performed with the various memory layouts

400 memory layout
- validate, then attempting to read (fails when reading)
- attempting to read, without validating first (fails)

400bb memory layout
- ditto

800bb memory layout
- full log, up until the checksums start failing at ~63%

For note (as seen in the logs), the message seen when attempting to validate the various 400 memory layouts is

Validating memory layout succeeded.
End address is not the end of flash memory.

Any change on this? I am aiming to fit this ECU into my 99 A4 when i convert to ME7.5 over ME3.8.3 which i currently have

I will add a small bug fix to the next version of NefMoto to hopefully work better with this ECU. The NefMoto software should allow you to continue reading or writing the ECU even if the memory validation fails. Currently it only allows you to continue if the memory validation didn't complete or was correct. I will add the ability to continue the read or write of the ECU even when the memory layout appears incorrect.

I am not sure why this ECU appears to be lying about what memory ranges are available. The memory layout verification that the NefMoto software does is not part of the standard protocol implemented by VW/Audi. It is possible that this ECU has a bug with regard to what memory ranges it allows access to.

NefMoto 1.9.1.2 is the current version, and I will try to release an update soon that should allow you to continue.

Great!  Shout if you need me to test anything.  Thanks for keeping up with this!

No problem. I also just ordered a 2002 VW Passat 4B0906018CM ECU off ebay for $50 so I can locally test this damn ECU out. I thought I may as well own all of the ECUs that don't play nice.

Thank you Tony, your help is appreciated.

I need to fix the immo next as it won't associate with my dash, but that's another problem..

Tony, you legend.  Got a successful read of a 4B0906018AA/0261206449, matches with a read I could get from Galletto (both validate with ME7Check).  Now starts the hard stuff  :D

Hi

Did the Nefmoto software update help?

I have a similar problem with my 99 Audi A4 1.8T (Euro) with a 4B0906018 0004 ECU. I am using Ross-tech cable in dumb mode and get connected to the ECU in slow init, but cant do any read from the ECU. It fails validate memory layout and start reading.

I tried to pull the instrument fuse, but no difference in the sequence.

LHN