Help with EDC17CP14 2015 VW Jetta please

Welcome, and no problem at all explaining this clearly. First, the good news: nothing you described sounds broken.

On the file sizes
Your mental model of "the backup should be the biggest file" is the confusing part, so let's drop it. The ECU doesn't have one big memory. It has several separate memories, and KTAG reads each one into its own file:

• Micro = 2048 KB — this is the internal program flash of the TC1796. 2 MB is exactly right, that is the full chip, so that read looks complete.
• EEPROM = 128 KB — this matches the TC1796 data flash / EEPROM region. Correct size.
• Extflash — the external memory chip, read on its own.

Each of those is a full, standalone copy of that one memory. They are not slices of the "backup." The 1258 KB "full backup" is just KTAG's own container/log for the job — it is not meant to be the sum of the others, so it being smaller does not mean a bad read. Think of it like photographing three separate rooms: you get three photos, not one photo that contains the other three.

How to actually prove the read is good (do this before trusting it)

• Read the micro twice and compare the two files in your hex editor (or a compare tool). If they are byte-for-byte identical, the read is clean. This is the single most important check.
• Open the micro dump and scroll through it. A good dump has varied data. If large areas are all FF or all 00, that region didn't read.

On TPROT / serial patching
Here is the key point people miss: TPROT is TriCore read protection. If KTAG already gave you a real, repeatable micro dump in boot mode, then the boot read has already gotten past TPROT for reading — the bootloader bypasses it at the hardware level. So you don't need to hunt for TPROT in the hex editor just to read.

Where TPROT matters is if you later want to write your modified file back over OBD/bench instead of boot: some workflows remove/patch the TPROT bytes in the dump so the ECU will accept an OBD write afterwards. That's a separate step, and you don't touch it until you have a verified read and a checksum-correct modified file. Don't blindly edit bytes you found in a hex search — you can brick the boot process that way.

To point you to the exact next step, can you post:

• The full ECU HW and SW number (from the label and/or from the read).
• The exact KTAG protocol number you used for this read.
• Whether two consecutive micro reads compare identical.
• A screenshot of the KTAG read log/summary.

That'll tell us whether your dump is trustworthy and what your real path to writing is.

Numbers from ECU label 03L 906 019 KC CJAA 5679
03L 907 309 AA DIESEL EDC17CP14 HW: H16
BOSCH 1039S67144 Assembled in Mexico
0 281 030 249 zsc 864 13-11-17 7824 0254


KTAG protocol 268 plug in 425

Micro reads are identical , flash reads are identical ,
Backup reads are not . I took 3 reads one a week ago and 2 consecutive on the same session ,the 2 taken together are identical , just took another and it was different again . it seems the eeprom changes . Is this rolling codes for immobilizer each time the ecu is powered up perhaps?


Not sure if I can screenshot this
In the KTAG id box all the fields are blank HW:
SW:
SW upg .:
VIN nr.:
Spare :
Installation:
Engine:

The progress dialog box reads , Identifying ECU ,
Reading device info
Reading Backup
Reading micro
SECTOR: 0X00000000
SECTOR 0X00004000
etc etc etc goes on to read flash and eeprom then ends with
Reading successfully completed
To enable the serial programming of this ECU;
1) Make a backup
etc etc

Good — this is exactly the behaviour I'd expect, and it tells me your read is healthy.

The short answer
Your micro and flash reads being byte-for-byte identical across sessions is the important result. That means the program flash (the part that actually matters for tuning) is reading cleanly. You've now proven that properly, so trust those files.

Why the "backup"/EEPROM keeps changing
This is normal and not a fault. EEPROM (data flash) is the ECU's scratchpad — it's the one region the processor is constantly writing to. Between two reads taken in the same key cycle it can be identical, but power the ECU up again and it will differ, because on every run/power event the ECU updates things like:

• Adaptation/learned values (fuelling, sensor offsets, etc.)
• Error/DTC memory and freeze-frame data
• Operating-hour and internal counters
• Immobilizer sync/rolling counter values

So you're partly right: immobilizer-related counters are one of the things in there, but it's not only the immo. It's the general "living" data of the ECU. Two consecutive reads matching, then a later one differing, is textbook. Nothing is wrong with your tool or your process.

Practical takeaway: don't chase a "matching" EEPROM read — you can't get one across power cycles, and you don't need one for a tune. Just keep one good EEPROM read on file for reference.

The blank ID fields (HW/SW/VIN all empty)
Also expected. In boot/BDM mode KTAG is talking to the chip directly at a low level, not through the diagnostic protocol that normally returns those SW/HW/VIN strings. That info lives in the flash, not in the boot-mode ID handshake, so the box stays blank. It is not a sign of a bad connection — your successful micro read proves the link is solid.

One thing worth confirming for the record: can you post the actual byte size and, if you can see it, the checksum KTAG reported for the micro read? And is protocol 268/plug 425 the boot-mode entry you used (not OBD)? Just want to make sure we're both describing the same read type before you go near the flash content.

Flash 2048kb . micro 2048kb . eeprom 128kb . backup 1258kb .
I do not know how to view the checksum KTAG reported .
I am using KTAG in boot mode with direct connection method - wires to ECU connector pins and probe to boot pad on PCB .
My hex editor will find checksum but I do not know which algorithm to use - options of checksum 8 ,16 ,32 ,64 ,custom ,CRC16 , CRC16 /CCITT-FALSE , etc etc

Good news first: you can stop worrying about the hex-editor checksum, because you've already done the check that actually matters.

Why you don't need to match KTAG's checksum
Reading the micro twice and getting byte-for-byte identical files IS the verification. That's the gold standard. A checksum is just a shortcut way of comparing two files when you can't line them up directly — but you already lined them up and they matched, so you've proven the read is clean. The checksum tells you nothing more than that.

Why the hex-editor checksum won't line up with KTAG's number
Don't go down this rabbit hole. There is no single "the" algorithm to pick. KTAG's reported value is its own internal figure over its own byte range with its own method — you have no way of knowing which range or which method it used, so guessing between Checksum8 / CRC16 / CCITT etc. will never reliably reproduce it. That's expected, not a fault.

Also worth separating two different things people call "checksum":

• Read-verification checksum — what you're looking at now. Already covered by your identical double-read.
• ECU internal checksums — the Bosch program/CRC checksums stored at specific addresses inside the micro. These only matter when you modify the file. The ECU checks them on boot, and if they're wrong it won't run the modified map. You do not calculate these by hand — the tuning software (WinOLS with the correct EDC17 checksum module, or the flash tool's built-in correction) recalculates and re-inserts them automatically when you write back.

On your file sizes
Flash 2048 / micro 2048 / eeprom 128 all look right for TC1796. The 1258 KB backup is again just KTAG's container/log — normal.

So the practical next step: keep your matched micro read as your known-good original, keep one eeprom read for reference, and don't try to reverse KTAG's checksum. When you eventually modify a map, let the software handle checksum correction on write.

If you want, tell me which tuning software you're planning to open the micro in and I'll point you at the right checksum setting for EDC17 so it's automatic.