I have a vag409.1 I can use to test a few basic things, however I have no any ecu compatible

I was able to do a few tests

All the test are responding as expected.

First Test: Cable Recognition, OK
Second Test: Try to establish a connection only with 12V on the interface: OK

Fixed a bug when InvokeParam/delegate are null

v1.9.5.2 (and later) now have CH340 support

See https://github.com/NefMoto/NefMotoOpenSource/releases/latest

Boot mode now in testing. Please help test!

https://github.com/NefMoto/NefMotoOpenSource/releases/tag/v1.9.6.0-rc3

Thank you 

Subject: Three fixes for the open-source flasher (single-file build, EEPROM read) — need testers

Hi all,

While building the open-source ECU Flasher from source (master, commit 97df3fa)
I ran into three issues and have fixes for them. I am posting them here in case
they are useful and so someone with a bench setup can test them.

Honest disclaimer up front: all three COMPILE cleanly and I verified the build
produces a working single-file executable, but I have NOT tested them against a
live ECU yet. Please review the diffs before trusting them. Patches attached.

--- Fix 1: MemoryLayouts not found in a single-file publish ---
GetMemoryLayoutsDirectory() locates itself through Assembly.Location, which
returns an empty string in a single-file published app (compiler warning IL3000).
The lookup then falls through to the current working directory, so a published
build usually finds no layouts at all — and without a layout, KWP2000 read/write
stay disabled ("Specified memory layout is not correct"). BootMode is unaffected
(it auto-detects the layout).
Fix: use AppContext.BaseDirectory, and copy the MemoryLayouts files next to the
executable on build/publish so a plain "dotnet publish" gives a working app.

--- Fix 2: unsigned loop counter in WriteEntireSerialEEPROMOperation ---
The search for the EEPROM shadow copy in external RAM uses a UInt32 counter with
the condition "x >= 0", which is always true. When no match is found the counter
wraps past zero and indexes out of bounds, throwing instead of reporting the miss
through the existing "Could not locate serial eeprom data in RAM" path.
Fix: count down with a signed value so the loop terminates at zero.

--- Fix 3: expose serial EEPROM read in the UI ---
ReadEntireSerialEEPROMOperation already exists but nothing in the UI reaches it.
Coding, immobiliser data and the ECU's own identity live in the serial EEPROM
rather than in the flash, so a flash dump alone never shows them.
This adds a "Read EEPROM" command next to the existing ECU-info commands: it reads
the 512 bytes and saves them to a file, and requires a KWP2000 connection.
Read only on purpose — the write path patches a shadow copy in external RAM,
which is a different class of risk, so I left it out of the UI.

Patches are against commit 97df3fa, but I checked the current master today and
all three issues are still present there unchanged, so the patches should still
apply. Happy to open a GitHub pull request instead if that is preferred.
Feedback and bench testing very welcome.

Full disclosure: I am a car enthusiast, not a programmer. The analysis and these
fixes were done with AI assistance; the commits carry co-authorship. If you have
detailed questions about the internals, I will be upfront — I will go and ask the
AI, because I do not know the answer myself. The diffs are small, so please read
them and judge the code on its own merits.

Thanks.

also i already have an eeprom branch locally but i haven't pushed it to the main repo, so please make eeprom changes a different PR.

TIA!!