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.

Ok so I have used a file service and now have a modified file to write , I have used a checksum correction service so I think I am ready to write to ECU .
My question is do I just write the Extflash ? or does there have to be some other correction to match with Micro TC1796 or EEprom

Short answer: do not write anything yet — the file you have does not look like a modified copy of the ExtFlash you posted.

I had a look at both attachments and they are not two versions of the same block:

• pats extflash s29cd016g 2 .bin – data only in the first 1 MB, everything from about 0x0FFF40 to 0x1FFFFF is FF (erased). The header at 0x000000 points at addresses in the 0x8088xxxx range, i.e. the external flash window. That is consistent with a genuine ExtFlash dump of the S29CD016G, with the unused upper half erased. Normal.
  *CHKtunedpfegr.bin – exactly the opposite layout: first 1 MB is all 00, real content starts at 0x100000 and runs to the end of the file. Its header points at 0x801FFFFC / 0x80800000, and inside it are the strings TPROT_V10.00.00/1796, ME(D)/EDC17 SB_V12.00.01/1796, EDC17 CB.02.10.01 C61.00 and 37/1/EDC17_CP14/5/P1152//C1152K3ZL///.

Those TPROT / bootloader / SW-ident strings and the 0x801Fxxxx pointers belong to the internal flash of the TC1796 (your "Micro" read), not to the external flash. Good news: 1152K3ZL and EDC17_CP14 match your ECU, so it is your car's software — the tuner just worked on the Micro file, not on the ExtFlash. This is inference from the layout and strings, not from a byte-by-byte diff, so please confirm it as below.

What to do before you connect anything

• Binary-compare CHK_tune_dpfegr.bin against both of your original reads (Micro and ExtFlash), same size, in HxD (File > Compare) or WinMerge. The one that shows only a handful of small differences is the block it came from. That is the only block you write.
• Expected pattern in a correct tune: a few changed areas in the map/data region plus a few changed words in the checksum block. If the comparison shows differences across megabytes, something is wrong and you stop.
• Check the 00-filled lower megabyte. If your original Micro read has FF there and the returned file has 00, ask the service to return the file in exactly the same layout/format as the read you sent them. Programming 0x000000–0x0FFFFF with zeros instead of leaving it erased is not something you want to find out about the hard way.

Your actual question — does anything else need matching?

• No. Each of those blocks is its own image with its own header and its own checksum/CRC area. If only the Micro was modified, you write Micro only. ExtFlash stays as read, EEPROM stays completely untouched.
• There is no "cross" correction you do by hand between Micro, ExtFlash and EEPROM. If your checksum service tells you which block they corrected, that is the block that goes back — ask them to state it plainly.
  *The EEPROM is where immo/adaptation lives, which is also why your "backup" read changed between sessions (as you saw earlier — that is expected, not a bad read). Never write an old EEPROM back over a newer one unless you are recovering a dead ECU.

Write hygiene on KTAG boot

• Bench power supply, 12.5–13.5 V, at least 5 A, no battery charger with ripple.
• Same wiring/probe setup that read cleanly. Don't touch the boot probe during the write.
• Keep at least two copies of all four original reads on separate media before you press Write.
• If a write aborts, do not power down — retry the write first. A half-written internal flash with power removed is the usual reason people end up needing a BDM/JTAG rescue.

To confirm the plan, post: which file you actually sent to the file service (Micro or ExtFlash), what the service named the block, and a screenshot of the hex compare between the returned file and that original read.

OK I sent the tuner both extflash and mico as I was unsure which one was needed so here are the files for you to look at

Good news: from the samples you posted, the tuned file is a micro (internal TC1796 flash) file, not an external flash file. Here is why, and what to do before you press write.

What the two files actually show

• pats extflash s29cd016g 2 .bin – real data starts at offset 0x000000 (header 50 00 00 00 ... 103756 42681152K3ZL) and everything from roughly 0x0FFF40 to the end is FF. So only the lower 1 MB of the S29CD016G is programmed, upper 1 MB blank. Since you said your flash reads are byte-identical between sessions, that is almost certainly the genuine layout and not a bad read.
• CHK_tune_dpfegr micro.bin – exactly the opposite layout: lower 1 MB is 00, real code/data starts at 0x100000 (header 40 00 00 00 ... 103756 42681152K3ZL), and there is a dense signature/CRC block at the very end (0x1FFF6C onwards). It also carries the internal-flash strings ME(D)/EDC17 SB_V12.00.01/1796, 37/1/EDC17_CP14/5/P1152//C1152K3ZL/// and TPROT_V10.00.00/1796.

That C1152K3ZL matches your 1039S67144 family, so the tuner did work on your car's software, not somebody else's. And the file you posted in your previous message (CHK_tune_dpfegr.bin) looks identical to this one in every region I can see – so the tuner most likely only returned one modified file, the micro.

Answer to your question
Write the micro / internal flash only. Leave the external flash alone (it was not modified), and never write the EEPROM from a tune file – that is where immo, adaptations and counters live, and it is exactly why your "backup" read differs every session. That changing backup is normal, nothing is wrong with your reads.

Do this before writing (this is the important part)

• Binary-compare the tuned file against your original micro read. Easiest on Windows: fc /b original_micro.bin CHK_tune_dpfegr_micro.bin > diff.txt, or use the compare function in HxD / WinMerge.
• What you want to see: a handful of changed blocks in the calibration area plus a few small changed spots (the corrected checksums). A few hundred to a few thousand changed bytes in a few clusters = normal.
• Stop and ask questions if you see: the file differs everywhere, the sizes don't line up, or areas near 0x100000 (the header) and the tail signature block are wholesale different from your original. That would mean the wrong base file or a wrong-model file.
• Also compare the two tuned files the tuner sent you against each other. If fc /b says "no differences encountered", you have one file, not two, and the naming was just confusion.
• Make sure your original micro, extflash and eeprom reads are saved in at least two places off the laptop. If a boot write goes wrong those are your only way back.

Writing

• Same tool, same protocol (268), same boot connection you used to read. Don't switch tools between read and write.
• Stable supply on the bench – a proper 13.5 V regulated supply, not a battery charger, and a solid boot pad contact. An interrupted internal flash write on TC1796 in boot is recoverable but painful.
• After the write, read the micro back and compare it to the file you wrote. It should match byte for byte apart from any area the ECU rewrites itself.

Two side notes: your KTAG "backup" (1258 KB) is the tool's own container format, not something you write by hand – it is only for the tool's restore function, which is why it is a different size from the raw dumps. And on the DPF/EGR side, the software change only behaves properly if the hardware side matches (gutted/removed DPF, EGR blocked), otherwise you get regen and airflow oddities – and obviously that is off-road use only in North America.

If you post the fc /b summary (just the first and last few lines and the number of differences) I can tell you whether the diff pattern looks like a sane EDC17 calibration change.

What is fc/b ?

Short answer depends on where you read it, so let me cover the two things that abbreviation normally stands for in this kind of thread:

• b/B (bits per byte) – that's the entropy figure attached to a dump. 8 b/B = fully random/compressed/encrypted, 0 b/B = all one value. Your extflash sampled at ~2.28 b/B (lots of FF padding, i.e. large erased areas), the micro at ~5.46 b/B (dense code + maps). It's only a rough "is this a real dump or garbage" indicator, nothing you flash or edit.
• FC (flash counter) – the programming counter that lives in the EEPROM/immo area and increments every time the ECU is written. It's what a dealer sees as the "programming/flash counter" in diagnostics. Boot-mode writes with a KTAG-type tool normally don't touch it the way an OBD write does, but it is one of the reasons your backup reads keep differing between sessions (that plus adaptation/error-memory data in EEPROM).

If it was in a tool dialog or a filename rather than in the thread text, post the screenshot or the exact line and I'll tell you which one it is.

While we're here, on your earlier question: the file the tuner sent back is named CHK_tune_dpfegr micro.bin, i.e. the modification and the checksum correction were done in the micro (TC1796 internal flash) file. The extflash you sent (pats extflash s29cd016g 2 .bin) is the untouched original, so there is nothing to write there. Flash the corrected micro file only, in the same boot-mode setup you read it with, and keep the original micro read plus all three backups somewhere safe before you start.

One thing worth confirming with the tuner before you press write: that they worked from your micro read and returned a full 2 MB file of the same size (it is 2.00 MB, which is correct), and that the checksums they corrected include the internal-flash map checksums, not just an outer one.

The tuner sent me this (first File) and then I used an online checksum correction to get this (Second file )

Short answer to your actual question: the file you have is the micro (internal flash) image, so that is the only thing you write. Leave the extflash alone and never write the EEPROM.

Why I say that: the tuner's file and the CHK file both carry the same internal-flash signature block starting at offset 0x100000 (103756426811 52K3ZL, ME(D)/EDC17 SB_V12.00.01/1796, TPROT_V10.00.00/1796), and the first 1 MB is 00 filler. Your extflash read is the other layout — data in the first 1 MB, FF above it. So the tuner worked on the micro read, which is normal for CP14: maps live in the TC1796 internal flash, the external S29CD016G mostly holds code. Extflash unchanged = nothing to write there.

Now the part that worries me

In every region I can see of the two files you posted — the zeroed lower half, the header block at 0x100000 (including the 4 bytes at 0x100030: 29 1B 60 11), and the last 0x180 bytes — the tuner's tune_dpfegr.bin and the "checksum corrected" CHK_tune_dpfegr micro.bin are byte-identical. That is only a sample, not a full compare, so it is not proof. But 0x100030 sitting in a header area and not changing is exactly where you would expect a corrected value to move. Two possible explanations:

• The tuner already corrected the checksums, so the online service found nothing to fix (good).
• The online service does not understand EDC17 CP14 and simply handed your file back untouched (bad).

Do this before you write anything

• Binary compare the two files. In HxD: File > Compare > Compare, pick tune_dpfegr.bin and CHK_tune_dpfegr micro.bin. If it reports zero differences, the checksum service did nothing — then you need to know whether the tuner already did it.
• Binary compare your original micro read against tune_dpfegr.bin. You should see a small number of changed areas (map data), not thousands of scattered bytes. If the changes are only in a few tight blocks, the tuner edited data properly.
• Ask the tuner straight out: "are checksums corrected in the file you sent me?" Most proper file services do it as standard. Two corrections applied on top of each other is not a problem, zero corrections is.

General guidance, not something I can confirm from your files: EDC17 uses several CRCs plus the TPROT block, and generic web "checksum fixers" usually get CP14 wrong or ignore it. A tool that actually knows the ECU (WinOLS with the correct checksum module, or a known checksum service that names the ECU family) is what you want. If the checksums are wrong the usual outcome is no start or immediate limp, not a brick — but it is still a reflash to recover, so get it right first.

When you do write

• Same connection you read with (boot pad + connector pins), stable 12.5–13 V supply, nothing else pulling load.
• Do not crop, pad, or "tidy" the file — write it at the exact same size and layout the tool gave you (2048 KB with the zeroed lower half intact). The tool expects its own read format.
• Keep your untouched original micro, extflash and EEPROM reads in a folder you cannot accidentally overwrite. Those are your only way back.
• After writing, read the micro back and compare it to what you wrote. Identical = write verified.

One thing to be aware of since this is a North American CJAA: a DPF/EGR-off file is not road legal there and will not pass any emissions check, so treat it as bench/off-road learning only.

If you post the HxD compare result (number and locations of differences) I can tell you whether it looks like a real checksum correction or a no-op.

tuned file and corrected file are different some changes on 000413000 and a block of differences from 000FFE70 to 000FFEF0 and from there on identical

Short answer: that diff pattern is exactly what you want to see. A checksum correction should change only checksum/CRC bytes and nothing else. Your maps stay as the tuner left them, and a handful of bytes get recalculated so the ECU stops complaining.

What your diff is telling you

• The block at 0x0FFE70–0x0FFEF0 (128 bytes, sitting right before the 0x100000 boundary) looks like a CRC/checksum table — a list of entries, one per protected flash region. That is the classic place for it in EDC17 data areas. Inference from the address and size, not something I can prove from your two files.
• The single spot you called "000413000" — that address has one digit too many for a 2 MB file. I assume you mean 0x041300. A lone small change there is most likely one region CRC (or the checksum-over-the-checksum-table). Please post the exact offset and the before/after bytes if you want it pinned down.
• Everything from there on identical = good. It means the correction service did not shift, pad or truncate the file.

From the two files you attached: both are exactly 2048 KB, and every region I can see in the extracts (the file start, the header area around 0x100000 with 1037564268...1152K3ZL, and the tail ending in DE AD BE EF) is byte-identical between them. That is consistent with a checksum-only edit outside those windows. I have not diffed the whole 2 MB, so treat that as "consistent with", not "verified".

The one thing you must nail down before you write
You sent the tuner both micro and extflash. The file that came back is named "...micro.bin", which suggests the internal flash (micro) is the one that was modified — but don't guess. Do this:

• Diff tune_dpfegr.bin against your original micro read.
• Diff tune_dpfegr.bin against your original extflash read.

One of those two will come back "identical except a few map areas". That is the file the tuner worked on, and that is the one you write. Rules of thumb:

• If it matches the micro: write micro only. Leave extflash and EEPROM completely alone.
• If it matches the extflash: write extflash — and then you also need to check whether the internal flash holds a CRC over the external flash, because in that case the micro needs correcting too. Say so and we'll work through it.
• Never write the ~1258 KB "backup" container. That is KTAG's own wrapper (and it includes EEPROM/live data, which is why it changed between reads). It is not a flashable image.

Write procedure, plain and boring on purpose

• Original reads copied to two separate places (not just the tool's folder) before you touch anything.
• Bench/boot power from a proper regulated supply, 12.5–13 V, nothing else drawing on it. No laptop on battery only, no sleep/USB power saving, no antivirus scanning the tool folder.
• Write, then read back and diff the readback against the file you wrote. If it matches, the flash is good. This step is what separates "it should be fine" from "it is fine".
• EEPROM untouched means immo/adaptations are untouched — no immo drama.

Two practical notes

• Deleting DPF/EGR in software while the hardware is still fitted and plumbed will usually throw its own set of complaints, and on a US-market CJAA the emissions side is watched closely — plan the hardware and the legal side, not just the file.
• If the ECU comes up dead after a write, it is almost always recoverable in boot mode with your original micro/extflash files. That is the whole reason for the backups.

Post the exact offset and byte values at that first difference, plus which original your tune matches, and I'll tell you whether that pair of changes is a sane checksum set or whether the service missed one.

My mistake it is 00041300 ,
tuned file 68 10 00 00 94 10 EA93 FF FF 1B 00 3C 00 26 02
Checksum file 68 10 00 00 1C 00 49 72 FF FF 1B 00 3C 00 26 02

Those two diffs are exactly what a correct checksum fix should look like, so this is good news rather than a problem.

What you're looking at

At 0x00041300:
Only the 4 bytes at offset +4 changed. The bytes around them (68 10 00 00, FF FF 1B 00 3C 00 26 02) are descriptor fields – length/flags/pointers – and they are untouched. So the corrector overwrote a stored checksum value (most likely a 32-bit CRC, or a 16-bit sum plus a 16-bit CRC pair) belonging to one calibration block. That is inference from the byte pattern, not from a decoded map of that ECU, but it is the classic layout for EDC17 calibration checksum entries.

The block 0x000FFE70–0x000FFEF0 is ~128 bytes, sitting right at the end of the lower megabyte, immediately before the program area that starts at 0x00100000. That is where the master/global checksum table normally lives on these images. The corrector rewrote that whole table.

Everything from there on is identical, i.e. the corrector did not touch a single byte of code or maps. That is what you want: a checksum service that changes map data is a red flag.

Which file to write

Both files you attached are the internal flash of the TC1796 (the "micro"), not the external flash. Evidence in the images themselves:

• They contain ME(D)/EDC17 SB_V12.00.01/1796, ME(D)/EDC17 B_CB.02.03.00 and TPROT_V10.00.00/1796 – bootloader / service block / read-protection strings that live in the microcontroller, not in the external NOR flash.
• Software ID 1037564268 / 1152K3ZL and 37/1/EDC17_CP14/5/P1152//C1152K3ZL///, which matches your 1039S67144-family CP14 CJAA.
• The empty areas read as 00 rather than FF, which is the erased state of TriCore internal flash (external NOR erases to FF).

So: write the micro only. Do not write the extflash, and do not write the EEPROM or the "backup". The DPF/EGR calibration on this ECU is in the internal flash, and the tuner clearly worked on that image.

That also explains your earlier confusion: the "backup" changing between reads is normal – it contains live/adaptation data that the ECU rewrites, which is why it must be left alone.

Before you press write

• Compare your original micro read against tune_dpfegr.bin. You should see changes only in the calibration/data area plus the checksum fields. If you see edits in the code area above 0x100000, stop and ask the tuner what he did.
• Run the corrected file through a second checksum tool that just reports status (not one that "fixes" blindly). If it says nothing to correct, your checksums are consistent. If it wants to change more, the first service missed a block.
• Keep two identical original micro reads saved off the laptop before writing. You already have identical reads, so you're covered.
• Write in boot with the same protocol 268 you read with, stable bench supply (13.5 V, decent amps, good ground), nothing else on the bench PC, don't touch the probe.
• After the write, read the micro back and compare it byte-for-byte with the file you wrote. That is your only real proof the write completed.

One practical warning

A DPF/EGR-off calibration only behaves properly if the tuner also removed the associated monitors and DTCs; otherwise you get MIL and limp even though the write was fine. Worth confirming with him what he switched off. And for a 2015 US-market Jetta, an emissions delete is not road legal there – your call how you handle that, but it will show up on any inspection or emissions readiness check.

If you post the offsets that differ between your original read and the tuned file, I can tell you whether they look like calibration-area edits or something that shouldn't be touched.