VW MFD 1 Navigation Code Retrieval for Passat B5.5 (VWZ1Z7D4080249)

RYM88 wrote:

Hi!

I need some help figuring out the code for a VW MFD 1 Navigation unit from a passat b5.5.

Serial VWZ1Z7D4080249

Two dump reads in attach, don't know why the 1Byte 3 Bit says adress error...

Initial assessment of available information
- Unit: VW MFD 1 (Passat B5.5), serial VWZ1Z7D4080249.
- Tools: CH341A.
- Symptom: “1‑Byte 3‑Bit address error”; “2‑Byte” read completes.
- Attachments exist in the forum thread, but I cannot access them from this interface. I’ll tell you exactly what to post so I can decode the code for you.

Direct answer to the question
- Your MFD1’s anti‑theft PIN is stored in an I²C EEPROM inside the FIS (navigation) module. Typical device is 24C32 (sometimes 24C64), i.e., 16‑bit (two‑byte) addressing.
- The “1‑Byte 3‑Bit” mode is for 24C01…24C16 devices (where the top address bits live in the control byte). On a 24C32/64 this mode will NACK and many programmer GUIs report it as an “address error.” This is expected and not a fault with your board.
- Use the dump you read in “2‑Byte” mode. That is the correct addressing for 24C32/64 and is the one we can decode.

Detailed problem analysis
1. Why the CH341A shows “1‑Byte 3‑Bit address error”
- 24C01…24C16: internal address = 1 data byte; the upper 3 address bits (A2..A0) are mapped into the device address (that’s the “3‑Bit” in your GUI).
- 24C32 and larger: internal address = 2 data bytes (high + low). If you try the 1‑Byte/3‑Bit transaction against a 24C32, the device won’t ACK the addressing phase → “address error.”
- Conclusion: your successful “2‑Byte” read strongly indicates a 24C32/24C64. Discard the 1‑Byte read.

2. What chip and where
- Located on the FIS board under the metal shield. Typical markings: AT24C32, M24C32, BR24C32, 24C32WP, etc. Occasionally 24C64.
- Capacity check: file size should be 4096 bytes for 24C32, 8192 bytes for 24C64.

3. Reading reliability with CH341A
- Voltage: Many CH341A “mini” programmers drive I²C at 5 V unless modified. These EEPROMs are 3.3 V. Use a 3.3 V‑fixed or level‑shifted setup. If you must keep the mini board, do the common 3.3 V fix or use a proper programmer (TL866II/T48/T56, XGecu) to avoid marginal reads.
- In‑circuit vs off‑board: In‑circuit reads often suffer from bus contention (pull‑ups or the main MCU holding SDA/SCL). If the dump looks all FF/00 or is unstable between reads, desolder the chip or isolate VCC/lines. Tie WP (pin 7) low during read/write.
- Validation: Read the EEPROM 2–3 times and byte‑compare; identical dumps confirm signal integrity.

4. Where the code lives and how we’ll extract it
- For Blaupunkt VWZ1Z7 MFD1, the 4‑digit code is in the FIS EEPROM (not calculated from the “VWZ…” serial alone).
- The storage format differs slightly across firmware variants. Common patterns are:
- BCD or ASCII digits stored plainly at a fixed offset, sometimes duplicated.
- Mirrored copy and/or a simple checksum near the end of the sector.
- With your dump I will locate the correct block, verify mirrors/checksum, and give you the exact 4‑digit PIN.

5. Misconceptions to clear up (correcting typical forum noise)
- 93Cxx (Microwire) chips: not used for the MFD1 code in the VWZ1Z7 Blaupunkt FIS module; the target here is I²C 24Cxx.
- Serial‑only or “sum of digits” methods: do not work for these units. Without the EEPROM content, the code cannot be derived reliably.

Current information and trends
- CH341A clones still commonly ship with the 5 V I/O issue; many technicians have moved to TL866II/T48/T56 for robustness, or they permanently 3.3 V‑mod the CH341A and use NeoProgrammer/AsProgrammer for 24xx I²C devices.
- For stubborn in‑circuit reads, powering the FIS board in the unit while isolating the EEPROM’s pull‑ups sometimes helps, but desoldering remains the most dependable.

Supporting explanations and details
- Pinout (24C32 SOIC‑8): 1=A0, 2=A1, 3=A2, 4=GND, 5=SDA, 6=SCL, 7=WP, 8=VCC.
- Programmer hookup basics: VCC=3.3 V, GND, SDA↔SDA, SCL↔SCL, WP→GND. Keep wires short, use proper pull‑ups (most programmers provide them).
- Recommended I²C clock ≤100 kHz for stability with long leads/SOIC clip.

Practical guidelines (do this now so I can decode your code)
Please post the following from your successful “2‑Byte” dump:
- Exact file size in bytes.
- Chip marking as printed on the package (photo or text).
- Hex snippets (copy/paste) from these regions:
- 0x000–0x03F (first 64 bytes)
- 0x1F0–0x230 (64+ bytes around 0x200)
- 0x3E0–0x420 (if your device is 24C32) or the last 64 bytes of the device if it’s larger
Example format (addresses on the left are fine):
00: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx
10: …
1F0: …
200: …
3E0: …

With those, I’ll read the structure and return the 4‑digit PIN. If you prefer, you can also attach the full dump again in the thread; I’ll pick it up there.

Common pitfalls and how to avoid them
- All FF/00 or random data: poor clip contact or wrong voltage. Clean the pins, shorten leads, ensure 3.3 V, try off‑board read.
- Size mismatch: a “24C64” selected against a 24C32 can give a file full of repeats. Make sure the device selection matches the chip, or use “Read ID/auto” if your software supports it (many 24Cxx don’t have JEDEC IDs—manual selection is normal).
- One read differs from the next: bus contention; remove the chip or lift VCC and feed from the programmer.

Ethical and legal aspects
- Radio codes are an anti‑theft measure. Proceed only if you own the unit. Dealers can also retrieve the PIN with proof of ownership via factory systems.

Suggestions for further research
- If you end up doing more of these, consider a TL866II/T48/T56 and a good SOIC8 clip; success rate and repeatability are higher.
- Keep a verified “original.bin” backup before any edits.

Brief summary
- Your “2‑Byte” dump is the correct one; the “1‑Byte 3‑Bit address error” is expected for a 24C32/64.
- Post the specified hex ranges (or the full 4 KB/8 KB dump). I’ll extract and verify the 4‑digit code for VWZ1Z7D4080249.

Questions for the user
- What is the exact EEPROM marking (e.g., AT24C32, M24C64)?
- What is the byte size of your successful “2‑Byte” dump?
- Please paste the hex from 0x000–0x03F, 0x1F0–0x230, and 0x3E0–0x420 of that dump. With that, I can give you the code.