Pushed to master.

I have discarded your eeprom patches because the eeprom support I'm working on replaces the code entirely.

Thank you!

Hi nyet (and everyone),

I know this thread is a bit old, but I saw you're still active here so I hope you don't mind me adding my own case — it's very similar to the original poster's issue.

I'm hitting a consistent KWP2000 handshake failure on a Seat Leon Mk1, AUQ 1.8T engine, ME7.5 ECU (part number confirmed via KWP1281: 06A906032HN, SW index 0001).

Setup: NefMoto v1.9.6.2, genuine FTDI FT232R KKL cable (confirmed by Windows as FT232R USB UART), COM3, VCP driver CDM v2.12.36.20 WHQL.

Symptom, 100% reproducible over dozens of attempts: slow init sync byte (0x55) and both key bytes are received correctly, NefMoto sends the correct complement byte back, but the ECU's own address-complement byte is never received (read=0, expected 0xEE/0xFE).

Already tried with no change in behavior: FTDI driver reinstall, latency timer 1ms, slow init gap at 1500/2600/3000ms, KWP2000 settings reset to defaults, battery disconnect, fuse 11 alone and fuses 11+15 together (with both pulled, NefMoto doesn't even start a connection attempt), aftermarket radio removed, Serial Enumerator/RTS-on-close/Selective Suspend toggled, slow init baud corrected to 38400 per the getting-started guide, and the Slow 5-baud offset tried at 0 , 10 ,20 and 30.

Key finding: using VCDS-Lite 1.2 on the exact same KKL cable and COM port, I successfully connected via KWP2000 (Control Module Finder) to Address 03 (ABS Brakes, Controller 1C0 907 379 K) with full data and coding read back, and also read the Engine module's info via KWP1281. So the K-line wiring, the cable, and KWP2000 itself all demonstrably work on this car over this exact interface — the failure seems isolated specifically to NefMoto's handshake with this Engine/ME7.5 controller at address 01.

Does that narrow it down at all? Is there anything ME7.5-specific about the address-complement step that could behave differently from a generic KWP2000 controller like the ABS module? Happy to post the full LoggerLog.txt excerpt if it would help.

I'll also test v1.9.7.0 and report back with results.

Thanks in advance for any pointers.

as nameless said, it is a limit of dumb cables. The slow init sequence has to be bit banged out via rough software timeout.

Fast init solves this problem (mostly) but doesn't work on ME7.5

I can offer to TRY to get it working if you send me an ECU. I can attempt to crossflash my 4B0906018CH but i'm skeptical it will work.

Finally, you can always use bootmode

Thanks a lot for looking into this and opening #95 — really appreciate it.

Yes, absolutely willing to test pre-release builds, whenever you have something ready. Happy to run whatever version/build you send, report back logs, screenshots, whatever's useful.

In the meantime I'm also doing a clean Windows reinstall on my end and testing on a second laptop, just to rule out anything specific to my current setup on my side. Will report back if any of that turns up something relevant, but either way I'm around and glad to help however I can to get this sorted — for me and for the next person who hits the same wall.

For flashing on the bench? I think so, I always have.

Good point on VCDS-Lite — you're right, that was KWP2000 to the ABS (0x03), not to the engine. On the engine (0x01), VCDS-Lite also only gets KWP1281, same as NefMoto always has. So neither tool has ever gotten a full KWP2000 session specifically with this ME7 before now.

Tested v1.9.7.1-rc0: it does now reach Connected — Slow init succeeded → Switching to KWP2000 session → Connected — which never happened before (old version always failed at the address complement step, 0 bytes, expected 0xEE). But it only stays connected for a few seconds before "Disconnecting because no response was received for the Tester Present message" (3 failed attempts). So it's not staying up long enough for a Full Read Flash.

On the ORI: I don't have another tool that can pull a full flash read (VCDS-Lite doesn't do that, and I don't have MPPS or anything similar). So I'm stuck getting you that ORI unless it's possible another way. Is there a smaller/faster read that might fit inside that few-second window, or a way to get what you need over KWP1281 instead since that already works reliably? Or should I just wait for a build that fixes the TesterPresent issue and try the full read again then? Whatever's most useful for you — happy to keep testing.

Try reading with address 11. Also, if you havent, open the ecu and verify its the stock EPROM chip and has not been swapped with some kind of riser