Нужна помощь с 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, чтобы всё выполнялось автоматически.