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

Сообщение #1

zoltanauto

Под наблюдением
Канада
С нами
09.08.2026
Сообщения
1
Реакции
0
Страна
Канада
Я в этом новичок и пытаюсь разобраться, поэтому, пожалуйста, если будете отвечать, объясняйте так, будто я ребёнок. Я опытный механик, работающий на себя, и надеюсь немного заняться калибровками для собственного обучения и чтобы заработать на покупку нормального инструмента.
У меня EDC17CP14 TC1796 с Jetta 2.0 TDI CJAA 2015 года для североамериканского рынка, на ECU указано «assembled in Mexico». Я вскрыл ECU, чтобы получить доступ к boot-паду.
Пытался считать его оригинальным Launch X-prog 3 — он даже не смог определить блок, хотя инструмент читает коды ошибок через OBD и прочее, и вроде бы готов записать резервную копию.
Клон MPPS 2 V21 — пишет, что чтение защищено, и предлагает использовать boot mode. Попробовал boot mode — всё равно пишет, что чтение защищено.
Клон PCM flash / SM2 pro — не удаётся связаться с модулями 71 и 53.
Клон KTAG вроде бы читает и предлагает сохранить полученные файлы.
Файлы, которые я получаю из ktag, выглядят нормально, но меня смущает их размер: полный backup занимает 1258 KB, а Micro-файл — 2048 Kb, Extflash — столько же, плюс Eeprom размером 128Kb.
Насколько я понимаю, backup должен быть больше отдельных файлов. Так инструмент неправильно прочитал, некорректно сохранил файлы или всё нормально?
Следующий вопрос: знает ли кто-нибудь, работает ли опция патчинга последовательной связи в клоне ktag? Если нет, как обойти TPROT? Я искал в hex-редакторе строку TPROT, о которой нашёл информацию в интернете, но ничего даже отдалённо похожего найти не смог.
Я удалил DPF с автомобиля и теперь нужно изменить прошивку или купить модифицированную, чтобы это учесть. Заранее спасибо, буду благодарен за любую помощь.
 
Оценки и отзывы
Всего оценок: 0

Сообщение #2

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

По размерам файлов
Представление о том, что «бэкап должен быть самым большим файлом», как раз и сбивает с толку, так что отбросим его. В 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.

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