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.

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.

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.

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.

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?

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

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