Нужна помощь с EDC17CP14 на VW Jetta 2015, пожалуйста

Добро пожаловать, и ничего страшного — сейчас всё нормально объясню. Для начала хорошая новость: по вашему описанию ничего не выглядит неисправным.

По размерам файлов
Представление о том, что «бэкап должен быть самым большим файлом», как раз и сбивает с толку, так что отбросим его. В ECU нет одной большой памяти. Там несколько отдельных областей памяти, и KTAG считывает каждую из них в отдельный файл:

• Micro = 2048 KB — это внутренняя программная flash-память TC1796. 2 MB — абсолютно правильный размер, это весь чип, так что считывание выглядит полным.
• EEPROM = 128 KB — соответствует области data flash / EEPROM TC1796. Размер правильный.
• Extflash — внешний чип памяти, считывается отдельно.

Каждый из них — полная самостоятельная копия соответствующей области памяти. Это не части «бэкапа». «Полный бэкап» размером 1258 KB — просто собственный KTAG container/log для этой задачи; он не должен быть суммой остальных, поэтому меньший размер не означает плохое считывание. Представьте, что вы фотографируете три отдельные комнаты: получаете три фото, а не одно фото, содержащее остальные три.

Как реально убедиться, что чтение корректное (сделайте это, прежде чем ему доверять)

• Считайте micro дважды и сравните два файла в hex-редакторе (или программе сравнения). Если они полностью совпадают побайтно, чтение чистое. Это самая важная проверка.
• Откройте дамп micro и пролистайте его. В хорошем дампе данные разнообразные. Если большие области полностью состоят из FF или из 00, эта область не считалась.

По поводу TPROT / serial patching
Вот ключевой момент, который многие упускают: TPROT — это защита TriCore от чтения. Если KTAG уже дал вам реальный, повторяемый дамп micro в boot-режиме, значит при чтении в boot TPROT уже обойдён — bootloader обходит его на аппаратном уровне. Поэтому искать TPROT в hex-редакторе только ради чтения не нужно.

TPROT важен, если позже захотите записать изменённый файл обратно через OBD/bench, а не через boot: в некоторых вариантах работы remove/patch байты TPROT в дампе, чтобы ECU потом принял запись по OBD. Это отдельный шаг, и трогать его не нужно, пока у вас нет проверенного чтения и изменённого файла с корректной контрольной суммой. Не редактируйте наугад байты, найденные поиском в hex — так можно завалить boot-процесс.

Чтобы подсказать точный следующий шаг, можете выложить:

• Полный номер HW и SW ECU (с наклейки and/or из чтения).
• Точный KTAG номер протокола, который использовали для этого чтения.
• Совпадают ли два последовательных чтения micro.
• Скриншот KTAGчтения log/summary.

По этому будет понятно, можно ли доверять вашему дампу и какой у вас реальный путь к записи.

Номера с наклейки ECU 03L 906 019 KC CJAA 5679
03L 907 309 AA DIESEL EDC17CP14 HW: H16
BOSCH 1039S67144 Собрано в Мексике
0 281 030 249 zsc 864 13-11-17 7824 0254


KTAG протокол 268, разъём 425

Считывания micro идентичны, считывания flash идентичны,
а считывания Backup — нет. Я сделал 3 считывания: одно неделю назад и 2 подряд за один сеанс. Эти 2, сделанные вместе, идентичны, а только что сделал ещё одно — и оно снова оказалось другим. Похоже, меняется eeprom. Может, это rolling codes иммобилайзера, которые меняются каждый раз при включении ECU?


Не уверен, что смогу сделать скриншот этого.
В окне идентификации KTAG все поля пустые HW:
SW:
SW upg .:
VIN nr.:
Запасной:
Установка:
Двигатель:

В окне прогресса отображается: «Идентификация ECU»,
Чтение информации об устройстве
Чтение Backup
Чтение micro
SECTOR: 0X00000000
SECTOR 0X00004000
и т. д. — продолжается чтение flash и eeprom, а затем заканчивается строкой:
Чтение успешно завершено
Чтобы включить последовательное программирование этого ECU:
1) Сделайте Backup
и т. д.

Отлично — именно такого поведения я и ожидал, и это говорит о том, что чтение у тебя исправно.

Коротко
То, что чтения micro и flash побайтно совпадают между собой в разных сессиях, — самый важный результат. Это значит, что flash-память программы (та часть, которая действительно важна для калибровки) считывается без ошибок. Теперь это доказано, так что этим файлам можно доверять.

Почему «backup»/EEPROM постоянно меняется
Это нормально и не является неисправностью. EEPROM (data flash) — это рабочая область ЭБУ, и именно в неё процессор постоянно что-то записывает. При двух чтениях в рамках одного и того же цикла зажигания данные могут совпасть, но после повторного включения питания ЭБУ они уже будут отличаться, потому что при каждом событии run/power ЭБУ обновляет, например:

• Adaptation/learned значения (подача топлива, коррекции датчиков и т. д.)
• Error/DTC память и данные freeze-frame
• счётчики наработки и внутренние счётчики
• иммобилайзера sync/rolling значения счётчиков

Так что ты отчасти прав: счётчики, связанные с иммобилайзером, действительно там есть, но это не только иммобилайзер. Это общие «живые» данные ЭБУ. Два последовательных чтения совпали, а более позднее отличается — это абсолютно штатная картина. С инструментом и самой процедурой всё в порядке.

Практический вывод: не нужно пытаться получить совпадающее чтение EEPROM — между циклами питания это невозможно, да и для прошивки оно не требуется. Просто сохрани одно хорошее чтение EEPROM для справки.

Пустые поля ID (HW/SW/VIN все пустые)
Это тоже ожидаемо. В boot/BDM режиме KTAG идёт прямой низкоуровневый обмен с микросхемой, а не работа через диагностический протокол, который обычно возвращает эти SW/HW/VIN строки. Эта информация хранится во flash, а не в рукопожатии ID boot-режима, поэтому прибор оставляет поля пустыми. Это не признак плохого соединения — успешное чтение micro подтверждает, что связь установлена нормально.

Для полноты хотелось бы уточнить один момент: можешь выложить фактический размер в байтах и, если он отображается, checksum KTAG, указанный для чтения micro? И протокол 268/plug 425 — это использованный тобой вход в boot-режим (не OBD)? Просто хочу убедиться, что мы оба говорим об одном и том же типе чтения, прежде чем ты полезешь к содержимому flash.

Flash 2048kb. micro 2048kb. EEPROM 128kb. backup 1258kb.
Я не знаю, как посмотреть указанную контрольную сумму KTAG.
Я использую KTAG в boot-режиме методом прямого подключения — провода к контактам разъёма ECU и щуп к boot-площадке на PCB.
Мой hex-редактор найдёт контрольную сумму, но я не знаю, какой алгоритм использовать: варианты контрольной суммы 8, 16, 32, 64, custom, CRC16, CRC16 /CCITT-FALSE и т. д.

Сначала хорошая новость: можешь больше не переживать из-за контрольной суммы в hex-редакторе, потому что ты уже выполнил проверку, которая действительно важна.

Почему не нужно, чтобы совпадала контрольная сумма KTAG's
Дважды считать микроконтроллер и получить побайтно идентичные файлы — это и есть проверка. Надёжнее не бывает. Контрольная сумма — всего лишь быстрый способ сравнить два файла, когда нельзя сопоставить их напрямую. Но ты уже сопоставил их, и они совпали, значит, ты доказал, что чтение выполнено корректно. Контрольная сумма ничего сверх этого не показывает.

Почему контрольная сумма в hex-редакторе не совпадёт с числом KTAG's
Не заходи в эту кроличью нору. Не существует какого-то единственного «правильного» алгоритма, который нужно выбрать. Значение, указанное KTAG, рассчитывается самой программой по своему диапазону байт и своим методом. Ты никак не узнаешь, какой диапазон и какой метод она использовала, поэтому перебор Checksum8 / CRC16 / CCITT и т. п. никогда не даст гарантированного совпадения. Это нормально, а не ошибка.

Ещё стоит разделять два разных понятия, которые называют «контрольной суммой»:

• Контрольная сумма для проверки чтения — это то, что ты сейчас смотришь. Твоя двойная проверка с идентичными файлами уже всё подтвердила.
• Внутренние контрольные суммы ЭБУ — контрольные суммы Bosch program/CRC, записанные по определённым адресам внутри микроконтроллера. Они важны только когда ты изменяешь файл. ЭБУ проверяет их при запуске, и если они неверные, модифицированная карта работать не будет. Тебе не нужно считать их вручную — программа для тюнинга (WinOLS с правильным EDC17 модулем коррекции контрольных сумм или встроенная коррекция во flash-инструменте) пересчитывает и заново вставляет их автоматически при обратной записи.

О размерах твоих файлов
Flash 2048 / micro 2048 / eeprom 128 — всё выглядит правильно для TC1796. Бэкап размером 1258 KB — это снова просто KTAG's container/log — всё нормально.

Так что практический следующий шаг: сохрани совпавший дамп micro как заведомо исправный оригинал, оставь один дамп eeprom для справки и не пытайся вычислять контрольную сумму KTAG. Когда позже будешь менять карту, пусть программа сама исправит контрольные суммы при записи.

Если хочешь, напиши, в какой программе для тюнинга собираешься открыть micro, и я подскажу правильную настройку контрольной суммы для EDC17, чтобы всё выполнялось автоматически.

Итак, я воспользовался файловым сервисом и теперь у меня есть модифицированный файл для записи. Также воспользовался сервисом коррекции checksum, так что, думаю, всё готово к записи в ECU.
Вопрос: достаточно просто записать Extflash? Или нужна ещё какая-то коррекция, чтобы он совпадал с Micro TC1796 или EEprom?

Короткий ответ: пока ничего не записывайте — имеющийся у вас файл не похож на модифицированную копию выложенного вами ExtFlash.

Я посмотрел оба вложения, и это не две версии одного блока:

• pats extflash s29cd016g 2 .bin – данные есть только в первом 1 MB, всё примерно от 0x0FFF40 до 0x1FFFFF заполнено FF (стёрто). Заголовок по адресу 0x000000 указывает на адреса в диапазоне 0x8088xxxx, то есть на окно внешней flash. Это соответствует нормальному дампу ExtFlash S29CD016G с очищенной неиспользуемой верхней половиной. Всё нормально.
  *CHKtunedpfegr.bin – ровно обратная структура: первый 1 MB полностью 00, реальные данные начинаются с 0x100000 и идут до конца файла. Его заголовок указывает на 0x801FFFFC / 0x80800000, а внутри есть строки TPROT_V10.00.00/1796, ME(D)/EDC17 SB_V12.00.01/1796, EDC17 CB.02.10.01 C61.00 и 37/1/EDC17_CP14/5/P1152//C1152K3ZL///.

Эти строки TPROT / bootloader / SW-ident и указатели 0x801Fxxxx относятся к внутренней flash TC1796 (ваше чтение «Micro»), а не к внешней flash. Хорошая новость: 1152K3ZL и EDC17_CP14 совпадают с вашим ECU, так что это ПО именно вашей машины — тюнер работал с файлом Micro, а не с ExtFlash. Это вывод по структуре и строкам, а не по побайтному сравнению, поэтому подтвердите это, как описано ниже.

Что сделать, прежде чем что-либо подключать

• Сравните бинарно CHK_tune_dpfegr.bin с обоими вашими исходными чтениями (Micro и ExtFlash), одинакового размера, в HxD (File > Compare) или WinMerge. Тот файл, где будет всего несколько небольших отличий, и есть блок, из которого он сделан. Записывать нужно только этот блок.
• Ожидаемая картина в нормальной прошивке: несколько изменённых областей в диапазоне map/data плюс несколько изменённых слов в блоке контрольной суммы. Если сравнение показывает различия на протяжении мегабайт — что-то не так, остановитесь.
• Проверьте нижний мегабайт, заполненный 00. Если в вашем исходном чтении Micro там FF, а в возвращённом файле 00, попросите сервис вернуть файл в точно таком же layout/format, как и отправленное им чтение. Записывать 0x000000–0x0FFFFF с нулями вместо того, чтобы оставить его стёртым, — это не то, о чём стоит узнать на собственном горьком опыте.

Ваш главный вопрос — нужно ли ещё что-то сопоставлять?

• Нет. Каждый из этих блоков — отдельный образ со своим заголовком и своей областью checksum/CRC. Если изменён только Micro, записываете только Micro. ExtFlash оставляете как считали, EEPROM вообще не трогаете.
• Никаких «перекрёстных» правок вручную между Micro, ExtFlash и EEPROM делать не нужно. Если сервис по контрольным суммам скажет, какой блок они исправили, именно этот блок и заливайте обратно — попросите их указать это прямо.
  *В EEPROM хранится immo/adaptation, поэтому ваше чтение «backup» и менялось между сессиями (как вы видели раньше — это ожидаемо, а не плохое чтение). Никогда не записывайте старый EEPROM поверх более нового, если только не пытаетесь восстановить мёртвый ECU.

Аккуратность при записи через KTAG boot

• Лабораторный блок питания, 12.5–13.5 V, минимум 5 A, без зарядника с пульсациями.
• Та же wiring/probe схема, на которой чтение прошло чисто. Не трогайте boot-пробник во время записи.
• Перед тем как нажать Write, сохраните как минимум две копии всех четырёх исходных чтений на разных носителях.
• Если запись прервалась, не отключайте питание — сначала повторите запись. Наполовину записанная внутренняя flash при отключении питания — обычная причина, по которой потом требуется восстановление BDM/JTAG.

Чтобы подтвердить план, напишите: какой файл вы реально отправляли в файловый сервис (Micro или ExtFlash), как сервис назвал этот блок, и приложите скриншот hex-сравнения возвращённого файла с тем исходным чтением.

ОК, я отправил тюнеру и extflash, и mico, так как не был уверен, какой из них нужен, поэтому вот файлы, посмотрите.

Хорошая новость: судя по опубликованным тобой образцам, тюнингованный файл — это файл micro (внутренняя флеш-память TC1796), а не файл внешней флеш-памяти. Ниже объясню почему и что нужно сделать перед записью.

Что на самом деле показывают два файла

• pats extflash s29cd016g 2 .bin — реальные данные начинаются со смещения 0x000000 (заголовок 50 00 00 00 ... 103756 42681152K3ZL), а всё примерно от 0x0FFF40 до конца — FF. То есть запрограммирован только нижний 1 МБ S29CD016G, а верхний 1 МБ пуст. Раз ты говоришь, что считанные дампы флешки побайтно совпадают между сессиями, почти наверняка это настоящая структура, а не ошибка чтения.
• CHK_tune_dpfegr micro.bin — структура ровно обратная: нижний 1 МБ — 00, реальные данные code/data начинаются с 0x100000 (заголовок 40 00 00 00 ... 103756 42681152K3ZL), а в самом конце есть плотный блок signature/CRC (начиная с 0x1FFF6C). В нём также присутствуют строки внутренней флеш-памяти ME(D)/EDC17 SB_V12.00.01/1796, 37/1/EDC17_CP14/5/P1152//C1152K3ZL/// и TPROT_V10.00.00/1796.

.
Этот C1152K3ZL соответствует твоему семейству 1039S67144, значит, калибровщик действительно работал с ПО твоего автомобиля, а не с чужим. И файл, который ты выкладывал в предыдущем сообщении (CHK_tune_dpfegr.bin), во всех видимых мне областях выглядит идентично этому — скорее всего, калибровщик вернул только один изменённый файл, micro.

Ответ на твой вопрос
Записывай только micro / внутреннюю флеш-память. Внешнюю флеш-память не трогай (её не изменяли) и никогда не записывай EEPROM из тюнинг-файла — именно там хранятся IMMO, адаптации и счётчики, поэтому твоя «резервная копия» отличается при каждом сеансе. То, что этот backup меняется, нормально — с чтением у тебя всё в порядке.

Что сделать перед записью (это важно)

• Сравни тюнингованный файл побайтно с твоим исходным дампом micro. Проще всего в Windows: fc /b original_micro.bin CHK_tune_dpfegr_micro.bin > diff.txt, либо используй функцию сравнения в HxD / WinMerge.
• Что должно получиться: несколько изменённых блоков в области калибровок и ещё несколько небольших изменённых участков (исправленные контрольные суммы). От нескольких сотен до нескольких тысяч изменённых байт в нескольких кластерах — это нормально.
• Остановись и задай вопросы, если увидишь, что файл отличается повсюду, размеры не совпадают или области возле 0x100000 (заголовок) и блок подписи в конце полностью отличаются от исходного файла. Это означало бы, что взят не тот базовый файл или файл от другой модели.
• Также сравни между собой два тюнингованных файла, которые прислал калибровщик. Если fc /b выводит «различий не обнаружено», значит, файл у тебя один, а не два — просто запутались в названиях.
• Убедись, что исходные дампы micro, extflash и eeprom сохранены минимум в двух местах не на ноутбуке. Если запись в boot прервётся или завершится ошибкой, это будет единственный способ восстановиться.

Запись

• Используй тот же инструмент, тот же протокол (268) и то же boot-подключение, которое применял для чтения. Не меняй инструмент между чтением и записью.
• Стабильное питание на столе — нормальный стабилизированный блок на 13.5 V, а не зарядное устройство для аккумулятора, и надёжный контакт с boot-площадкой. Если запись внутренней флеш-памяти TC1796 в boot прервётся, восстановить всё можно, но это будет тот ещё геморрой.
• После записи снова считай micro и сравни его с записанным файлом. Побайтно всё должно совпадать, кроме областей, которые ЭБУ перезаписывает сам.

Два небольших замечания: твой KTAG «backup» (1258 KB) — это собственный контейнерный формат инструмента, а не файл, который нужно записывать вручную. Он нужен только для функции восстановления инструмента, поэтому его размер отличается от размера сырых дампов. И со стороны DPF/EGR программное изменение корректно работает только при соответствующем состоянии железа (gutted/removed DPF, заглушенный EGR), иначе появятся странности с регенерацией и расходом воздуха. И, конечно, в Северной Америке это разрешено только для использования вне дорог общего пользования.

Если выложишь fc /b сводку (только несколько первых и последних строк и количество различий), я скажу, похож ли результат сравнения на нормальное изменение EDC17 калибровки.

Что такое fc/b?

Короткий ответ зависит от того, где вы это увидели, поэтому поясню два значения, которые эта аббревиатура обычно имеет в таких темах:

• b/B (бит на байт) — это показатель энтропии дампа. 8 b/B = полностью random/compressed/encrypted, 0 b/B = везде одно значение. Ваша extflash была считана с показателем около 2,28 b/B (много заполнения FF, то есть большие стёртые области), micro — около 5,46 b/B (плотный код + карты). Это лишь грубый индикатор «это реальный дамп или мусор», ничего прошивать или редактировать тут не нужно.
• FC (счётчик прошивок) — счётчик программирований, который находится в области EEPROM/immo и увеличивается при каждой записи в ECU. Именно его дилер видит в диагностике как счётчик «programming/flash». Запись в boot-mode инструментом типа KTAG обычно не затрагивает его так, как запись по OBD, но это одна из причин, почему ваши контрольные считывания отличаются между сессиями (плюс данные adaptation/error-memory в EEPROM).

Если это было в окне программы или в имени файла, а не в тексте темы, выложите скриншот или точную строку — скажу, что именно имеется в виду.

Раз уж речь зашла, по вашему предыдущему вопросу: файл, который вернул тюнер, называется CHK_tune_dpfegr micro.bin, то есть модификация и коррекция контрольной суммы были сделаны в файле micro (внутренняя flash TC1796). Отправленный вами extflash (pats extflash s29cd016g 2 .bin) — нетронутый оригинал, поэтому записывать туда ничего не нужно. Прошейте только исправленный micro-файл в том же boot-mode, в котором его считали, и перед началом сохраните в надёжном месте оригинальное считывание micro и все три бэкапа.

Перед тем как нажимать запись, стоит уточнить у тюнера одно: что он работал именно с вашим считыванием micro и вернул полный файл размером 2 МБ такого же размера (2,00 МБ — это правильно), а также что исправленные им контрольные суммы включают контрольные суммы карт внутренней flash, а не только внешнюю.

Тюнер прислал мне это (первый файл), а затем я использовал онлайн-коррекцию checksum, чтобы получить это (второй файл)

Короткий ответ на ваш вопрос: файл, который у вас есть, — это образ micro (внутренней флеш-памяти), поэтому записывать нужно только его. Extflash не трогайте и EEPROM никогда не записывайте.

Почему я так говорю: в файле тюнера и файле CHK присутствует один и тот же блок сигнатуры внутренней флеш-памяти, начиная со смещения 0x100000 (103756426811 52K3ZL, ME(D)/EDC17 SB_V12.00.01/1796, TPROT_V10.00.00/1796), а первый 1 MB заполнен 00. Ваш дамп extflash имеет другую структуру — данные в первом 1 MB, а FF выше. Значит, тюнер работал с дампом micro, что для CP14 нормально: карты находятся во внутренней флеш-памяти TC1796, а внешняя S29CD016G в основном хранит код. Extflash без изменений = записывать туда ничего не нужно.

Теперь то, что меня беспокоит

Во всех областях двух файлов, которые вы выложили и которые я вижу, — обнулённой нижней половине, блоке заголовка по адресу 0x100000 (включая 4 байта по адресу 0x100030: 29 1B 60 11) и последних 0x180 байтах — файл тюнера tune_dpfegr.bin и файл с «исправленной контрольной суммой» CHK_tune_dpfegr micro.bin побайтно идентичны. Это лишь выборка, а не полное сравнение, поэтому доказательством это не служит. Но 0x100030, находящийся в области заголовка и не меняющийся, — это как раз то место, где можно было бы ожидать изменения исправленного значения. Возможны два объяснения:

• Тюнер уже исправил контрольные суммы, поэтому онлайн-сервису было нечего исправлять (хорошо).
• Онлайн-сервис не понимает EDC17 CP14 и просто вернул ваш файл без изменений (плохо).

Сделайте это, прежде чем что-либо записывать

• Побайтно сравните два файла. В HxD: File > Compare > Compare, выберите tune_dpfegr.bin и CHK_tune_dpfegr micro.bin. Если будет указано ноль различий, сервис контрольных сумм ничего не сделал — тогда нужно выяснить, сделал ли это уже тюнер.
• Побайтно сравните ваш исходный дамп micro с tune_dpfegr.bin. Должно быть небольшое количество изменённых областей (данные карт), а не тысячи разбросанных байтов. Если изменения только в нескольких компактных блоках, тюнер корректно отредактировал данные.
• Спросите тюнера напрямую: «исправлены ли контрольные суммы в файле, который вы мне отправили?» Большинство нормальных файловых сервисов делает это стандартно. Две коррекции, применённые одна поверх другой, не проблема; проблема — ноль коррекций.

Общее руководство, не то, что я могу подтвердить по вашим файлам: EDC17 использует несколько CRC плюс блок TPROT, а обычные веб-«исправители контрольных сумм» обычно неверно обрабатывают CP14 или игнорируют его. Вам нужен инструмент, который действительно знает этот ECU (WinOLS с правильным модулем контрольных сумм, либо проверенный сервис контрольных сумм, который указывает семейство ECU). Если контрольные суммы неверны, обычный результат — двигатель не запустится или сразу уйдёт в аварийный режим, а не кирпич, — но для восстановления всё равно придётся перепрошивать, так что сначала сделайте всё правильно.

Когда будете записывать

• То же подключение, которым считывали (boot pad + контакты разъёма), стабильное питание 12.5–13 V, ничего больше не должно давать нагрузку.
• Не обрезайте, не дополняйте и не «приводите в порядок» файл — записывайте его ровно в том же размере и структуре, в которых его выдал инструмент (2048 KB с нетронутой обнулённой нижней половиной). Инструмент ожидает собственный формат считанного файла.
• Сохраните нетронутые исходные дампы micro, extflash и EEPROM в папку, которую случайно не перезапишете. Это ваш единственный путь назад.
• После записи снова считайте micro и сравните его с тем, что записывали. Идентичны = запись проверена.

Учтите ещё один момент, поскольку это североамериканский CJAA: файл DPF/EGR-off там не разрешён для дорог общего пользования и не пройдёт никакую проверку выбросов, так что рассматривайте это только как bench/off-road для обучения.

Если выложите результат сравнения HxD (количество и расположение различий), я смогу сказать, похоже ли это на реальную коррекцию контрольных сумм или на отсутствие изменений.

тюнинг-файл и исправленный файл отличаются: есть изменения по 000413000 и блок различий с 000FFE70 по 000FFEF0, а дальше они идентичны

Короткий ответ: такая картина diff — именно то, что и нужно видеть. Коррекция контрольной суммы должна менять только checksum/CRC байты и ничего больше. Карты остаются такими, какими их оставил калибровщик, а несколько байт пересчитываются, чтобы ECU перестал ругаться.

Что показывает ваш diff

• Блок по адресу 0x0FFE70–0x0FFEF0 (128 байт, прямо перед границей 0x100000) похож на таблицу CRC/checksum — список записей, по одной на каждую защищённую область flash. Для областей данных EDC17 это классическое место. Это вывод по адресу и размеру, а не то, что я могу доказать по вашим двум файлам.
• Единственная точка, которую вы назвали «000413000», — в этом адресе на одну цифру больше для файла на 2 MB. Полагаю, вы имеете в виду 0x041300. Одиночное небольшое изменение там, скорее всего, означает CRC одной области (либо checksum по таблице checksums). Если хотите определить точно, выложите точное смещение и байты before/after.
• Дальше всё идентично = хорошо. Значит, сервис коррекции не сдвинул, не дополнил и не обрезал файл.

По двум прикреплённым файлам: оба ровно по 2048 KB, и все области, которые я вижу в извлечённых фрагментах (начало файла, область заголовка вокруг 0x100000 с 1037564268...1152K3ZL и хвост, оканчивающийся на DE AD BE EF), между ними побайтно идентичны. Это согласуется с правкой только checksum вне этих окон. Весь объём 2 MB я не сравнивал, так что считайте это «согласуется с», а не «проверено».

Единственное, что нужно точно выяснить перед записью
Вы отправили калибровщику и micro, и extflash. Вернувшийся файл называется «...micro.bin», что указывает на изменённую внутреннюю flash (micro), но не гадайте. Сделайте так:

• Сравните tune_dpfegr.bin с вашим исходным считанным micro.
• Сравните tune_dpfegr.bin с вашим исходным считанным extflash.

Один из этих двух покажет «идентично, кроме нескольких областей карт». Это файл, с которым работал калибровщик, его и записывайте. Ориентируйтесь так:

• Если он совпадает с micro: записывайте только micro. extflash и EEPROM вообще не трогайте.
• Если он совпадает с extflash: записывайте extflash — а затем также нужно проверить, хранится ли во внутренней flash CRC по внешней flash, потому что в таком случае micro тоже требует коррекции. Скажите, если так, и разберёмся.
• Никогда не записывайте контейнер «backup» размером ~1258 KB. Это собственная обёртка KTAG (в неё включены данные EEPROM/live, поэтому она менялась между чтениями). Это не образ для прошивки.

Процедура записи — намеренно простая и скучная

• Перед тем как что-либо трогать, скопируйте исходные чтения в два разных места, а не только в папку инструмента.
• Bench/bootПитание от нормального стабилизированного источника, 12.5–13 V, без других потребителей. Не работайте с ноутбуком только от батареи, отключите энергосбережение sleep/USB и не давайте антивирусу сканировать папку инструмента.
• Запишите, затем считайте обратно и сравните считанное с записанным файлом. Если совпадает — flash в порядке. Именно этот шаг отличает «должно быть нормально» от «всё нормально».
• EEPROM не трогали — значит, immo/adaptations тоже не тронуты, никаких проблем с иммобилайзером.

Два практических замечания

• Отключение DPF/EGR программно, пока железо всё ещё установлено и подключено, обычно вызывает свой набор ошибок, а на CJAA для рынка США за экологией следят строго — продумайте не только файл, но и железо с юридической стороны.
• Если ECU после записи не выходит на связь, почти всегда его можно восстановить в boot mode с вашими исходными файлами micro/extflash. Для этого резервные копии и нужны.

Выложите точное смещение и значения байтов в месте первого различия, а также укажите, с каким исходником совпадает ваша прошивка — скажу, выглядит ли эта пара изменений нормальным набором checksums или сервис пропустил один.

Моя ошибка, это 00041300,
прошивка 68 10 00 00 94 10 EA93 FF FF 1B 00 3C 00 26 02
Файл checksum 68 10 00 00 1C 00 49 72 FF FF 1B 00 3C 00 26 02

Эти два diff-а — именно то, как должна выглядеть правильная Коррекция контрольной суммы, так что это хорошая новость, а не проблема.

Что здесь видно

В 0x00041300:
Изменились только 4 байта по смещению +4. Байты вокруг них (68 10 00 00, FF FF 1B 00 3C 00 26 02) — это поля дескриптора, length/flags/pointers, — и они не тронуты. Значит, корректор перезаписал сохранённое значение checksum (скорее всего, 32-битный CRC либо пара из 16-битной суммы и 16-битного CRC), относящееся к одному блоку калибровки. Это вывод по шаблону байтов, а не по декодированной карте этого ECU, но это классическая структура записей checksum калибровки EDC17.

Блок 0x000FFE70–0x000FFEF0 размером около 128 байт расположен прямо в конце нижнего мегабайта, непосредственно перед областью программы, которая начинается с 0x00100000. Именно там в таких образах обычно находится таблица checksum master/global. Корректор перезаписал всю эту таблицу.

Дальше всё идентично, то есть корректор не изменил ни одного байта кода или карт. Так и должно быть: сервис checksum, который меняет данные карт, — это тревожный сигнал.

Какой файл записывать

Оба приложенных вами файла — это внутренняя flash-память TC1796 ("микро"), а не внешняя flash-память. Это видно по самим образам:

• В них есть ME(D)/EDC17 SB_V12.00.01/1796, ME(D)/EDC17 B_CB.02.03.00 и TPROT_V10.00.00/1796 — строки загрузчика / сервисного блока / защиты от чтения, которые находятся в микроконтроллере, а не во внешней NOR flash.
• Software ID 1037564268 / 1152K3ZL и 37/1/EDC17_CP14/5/P1152//C1152K3ZL///, что соответствует вашему CP14 семейства 1039S67144 CJAA.
• Пустые области читаются как 00, а не как FF, что соответствует стёртому состоянию внутренней flash TriCore (внешняя NOR стирается в FF).

Итого: записывайте только микро. Не записывайте extflash, а также EEPROM или «backup». Калибровка DPF/EGR на этом ECU находится во внутренней flash, и тюнер явно работал именно с этим образом.

Это также объясняет вашу прежнюю путаницу: изменения «backup» между чтениями — это нормально, в нём содержатся данные live/adaptation, которые ECU перезаписывает, поэтому его нужно оставить в покое.

Перед записью

• Сравните ваш оригинальный считанный micro с tune_dpfegr.bin. Изменения должны быть только в области calibration/data плюс поля checksum. Если увидите правки в области кода выше 0x100000, остановитесь и спросите у тюнера, что он сделал.
• Прогоните исправленный файл через второй инструмент проверки checksum, который только показывает статус, а не «исправляет» вслепую. Если он скажет, что исправлять нечего, checksum согласованы. Если он захочет изменить что-то ещё, значит, первый сервис пропустил блок.
• Сохраните вне ноутбука два одинаковых оригинальных чтения micro перед записью. У вас уже есть идентичные чтения, так что здесь всё в порядке.
• Записывайте в boot тем же протоколом 268, которым читали: стабильный лабораторный источник питания (13.5 V, нормальный запас по току, хорошая масса), ничего лишнего на компьютере стенда, щуп не трогать.
• После записи снова считайте micro и побайтно сравните с файлом, который записывали. Это единственное реальное доказательство, что запись завершилась.

Одно практическое предупреждение

Калибровка DPF/EGR-off будет работать нормально только если тюнер также отключил связанные мониторы и DTC; иначе получите MIL и аварийный режим, даже если запись прошла без проблем. Стоит уточнить у него, что именно он отключил. И для Jetta 2015 года для рынка США отключение экологических систем там не разрешено для дорог общего пользования — как с этим поступать, решать вам, но это выявится при любой инспекции или проверке готовности системы контроля выбросов.

Если выложите смещения, которые отличаются между вашим оригинальным чтением и тюнинг-файлом, я смогу сказать, похожи ли они на правки в области калибровок или на то, что трогать не следует.

Спасибо за помощь, залил файл в машину — всё хорошо, работает отлично.

Отлично, что всё прошло чисто и машина работает как надо — для первой работы с EDC17 отлично справился. Обязательно сохрани где-нибудь в надёжном месте тот исходный микрорид (и отдельную копию не на рабочем ПК), это твой путь назад, если когда-нибудь понадобится всё вернуть.