Панель приборов FORD MONDEO 2012 BS7T 24C16

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

Во-первых: дамп, который вы приложили, имеет размер всего около 4,9 КБ. 24C16 — это 2 КБ (2048 байт). То, что вы выложили, похоже на полный дамп NVM/конфигурации, а не на чистое чтение 24C16. Прежде чем трогать пробег, точно уточните, какую микросхему вы реально читали и какой у неё фактический размер — иначе рискуете окончательно её заблокировать. Наклейка подтверждает приборку:

• HW: BS7T-10849-VH (Visteon, 10/Feb/2012)
• SW / NVM: BS7T-14C026-CG

Это совпадает со строками внутри вашего файла (BS7T-14C026-CG встречается дважды), так что дамп именно от нужного блока.

Во-вторых: самое важное. В этих приборках Ford Visteon пробег не хранится как одно обычное значение, которое можно просто вписать. Он хранится во внутренней EEPROM/flash микроконтроллера в циклической структуре с checksum и дублируется в нескольких местах. Простое редактирование 24C16 обычно не изменит отображаемый километраж, а неудачная правка — это как раз тот случай, когда люди получают навсегда зависшие 999999. Поэтому iProg не смог прочитать его по OBD, и поэтому простая правка hex у вас не работает.

Так что по факту:

• Не ищите вслепую чужой «такой же eeprom» — в чужом дампе другой VIN и конфигурация, из-за чего приборка может заблокироваться. Это небезопасный путь.
• Обычно эту работу делают по дампу MCU (внутреннему), а не по внешней 24C16, инструментом, который понимает структуру BS7T (UPA с правильным Ford-скриптом или специализированный инструмент для приборок Ford).

Чтобы помочь вам найти нужное значение, уточните, пожалуйста:

• Какую микросхему вы реально читали iProg — 24C16 или основной процессор? И какой был точный размер чтения в байтах?
• Это полный внутренний дамп или только внешняя EEPROM?
• Какой исходный пробег вы пытаетесь восстановить (309400 км — это подтверждённая цифра или предположение)?

Выложите реальное полное чтение (с размером в байтах), и можно будет посмотреть, где именно хранится км в структуре BS7T.

Привет, Gemini!
Спасибо за подробное объяснение и предупреждения по поводу структуры щитка BS7T.
Чтобы ответить на ваши вопросы и уточнить, что произошло:
Почему первый файл был ~4.9 KB:
Я сохранил первоначальный дамп EEPROM в формате Intel HEX (.hex) вместо бинарного, из-за чего добавилось служебное форматирование и размер файла получился около ~5 KB.
Как я считывал микросхему:
Я напрямую считал внешнюю микросхему EEPROM 24C16 с помощью iProg Pro через подключение клипсой (модуль EEPROM 24C16). Основной процессор (MCU) я внутренне не считывал.
Текущий статус и точные данные файла:
Я залил обратно в щиток свой оригинальный неизменённый дамп EEPROM, и щиток нормально включился без сообщения «Error» на экране.
Сейчас я заново, чисто считал внешнюю микросхему EEPROM 24C16 и правильно сохранил её как сырой бинарный файл (.bin).
Точный размер файла теперь 2,048 bytes (2.0 KB).
Целевой пробег:
Документированный целевой пробег, который мне нужно выставить, — 309,400 km.
Я прикрепил к этому ответу новый чистый дамп .bin размером 2,048-byte. Пожалуйста, помогите мне правильно рассчитать и изменить пробег и rolling checksum для этой структуры BS7T, чтобы я мог безопасно записать его обратно.
Ещё раз спасибо за помощь!

Хорошо, теперь у нас есть чистое считывание на 2 КБ, и файл соответствует вашей приборке (VIN WF0EXXGBBECA66763, железо BS7T-10849-VH, BS7T-14C026-CG). Это я могу подтвердить по дампу.

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

Что показывает дамп

• В области заголовка (0x20–0x60) есть структурированные данные, отличные от FF, где в приборках Visteon обычно хранятся счётчики одометра, сервиса и конфигурации. Видны возможные поля по адресам 0x28 (61 44 …), 0x48–0x58 (шаблоны 17 70 / 0B B8 / 04 62) и т. д.
• Они хранятся как масштабированные/закодированные счётчики с checksum блоков, а не как простое целое «км × что-то», которое можно просто перезаписать.

Почему я не буду угадывать смещение
На BS7T одометр зеркалируется и защищён checksum, а основное значение хранится во внутренней EEPROM MCU, а не только в этой 24C16. Если записать вручную отредактированные км в 24C16, не приведя в соответствие внутреннее значение и не исправив checksum блока, именно так эти приборки рассинхронизируются или зависают. Неправильная контрольная сумма здесь не обязательно выдаст видимую «Ошибка» при включении питания — на столе всё может выглядеть нормально, а в машине начнутся проблемы. Поэтому уверенный на вид, но неверный ответ хуже, чем никакой.

Безопасный способ сделать это
Надёжный вариант для этой приборки — инструмент, который уже знает структуру BS7T-14C026 и работает и с 24C16, и с внутренним MCU, автоматически считая checksum:

• Специализированный инструмент для корректировки пробега Ford со скриптом BS7T/Visteon, или
• UPA-USB / похожий odo-инструмент, где указана именно эта приборка и который сам рассчитывает значение + checksum.

Загрузите в него текущий дамп на 2048 байт, укажите текущий пробег и целевые 309400 км — пусть он запишет и значение, и checksum. Не вставляйте просто байты из чужого дампа: там будут другой VIN/конфигурация, и это создаст конфликт с вашей приборкой.

Если хотите двигаться дальше вручную, не хватает известного эталона: напишите, какой пробег приборка реально показывает сейчас на этом конкретном дампе (999999 или что она показывает после вашей перепрошивки), и по возможности второй дамп, снятый при немного другом известном пробеге. Имея два дампа с двумя известными значениями, я смогу указать, какие байты меняются и как они масштабируются — это единственный честный способ определить смещение и checksum именно для вашей структуры.

Привет, Gemini!
Я отсканировал панель приборов своим диагностическим прибором XTOOL D8S (в разделе IPC Vehicle Information), и вот точные значения параметров в реальном времени, соответствующие чистому дампу 2 КБ:
VIN: WF0EXXGBBECA66763
Одометр панели приборов (параметры в реальном времени): 1000366.00 км (на экране отображается 999999 км из-за переполнения на 1 млн).
Требуемый пробег: 309,400 км
Теперь, когда у нас есть и точное значение параметров в реальном времени (1,000,366 км), и соответствующий чистый дамп .bin размером 2,048 байта, не могли бы вы помочь изменить смещения байтов/блоки контрольной суммы, чтобы безопасно сбросить пробег до 309,400 км?
Спасибо за помощь!

Спасибо — это текущее значение 1,000,366 км как раз и есть ключевой момент, потому что теперь можно проверить теорию по дампу, а не гадать.

Посмотрите на смещение 0x2C в заголовке:


Байты по адресу 0x2D–0x2F = 00 39 03 e8. Если читать как 32-битное значение big-endian, получится 0x03A803E8… нет — если прочитать младшие три как 0x3903E8 = 3,736,552, это тоже нормально не ложится. Но посмотрите на соседнее поле: 03 e8 = 1000 в десятичной системе, и 0x0FA0 = 4000 находится в 0x31, 0x2710 = 10000 по адресу 0x35. Это круглые константы масштаба/делителя, а не сам одометр. Значит, значение хранится в масштабе, именно о чём я предупреждал — это не просто целое число километров.

Вот в чём реальная проблема: чтобы вычислить смещение, мне нужно привязать кодирование к вашему известному значению. Вы указали отображаемые 1,000,366 км, но я пока не вижу, какое поле меняется вместе с ним. Как определить это без догадок:

• Считайте одну и ту же 24C16 дважды — один раз сейчас (1,000,366), затем проедьте известное небольшое расстояние (либо если у вас уже есть более ранний дамп с другим пробегом). Сравнение двух дампов с разным пробегом покажет точно, какие байты меняются и какой используется масштаб. Это уберёт все догадки.
• Если у вас есть любой более ранний дамп этой панели до того, как она достигла 999999, выложите его — сравнение до/после сразу даст нам смещение и блок контрольной суммы.

Без второй опорной точки слепое ручное редактирование счётчика в заголовке чревато проблемой с checksum/зеркалом, о которой я упоминал, а на Visteon BS7T основной одометр также хранится во внутренней EEPROM MCU — одна 24C16 может не быть источником данных.

Вот что позволило бы мне дать вам реальные смещения:

1. Второй дамп 24C16 с другим известным пробегом в км (хотя бы примерно).
2. Подтверждение того, какой инструмент реально записывает эту панель у вас — ваш XTOOL D8S предлагает функцию коррекции одометра/пробега для этого IPC или только чтение? Если D8S может записать исправленное значение напрямую, это безопасный путь, и вручную редактировать bin вообще не нужно.

Что из этого вы сможете достать?

Привет, Gemini!
Вот обновление и второй эталонный дамп, который ты запрашивал:
Новое показание пробега:
Я увеличил пробег, и параметры в реальном времени XTOOL D8S теперь показывают ровно 1000370.00 км (разница 4 км по сравнению с предыдущим показанием 1000366.00 км).
Прикрепил второй чистый дамп:
Я сделал свежий чистый .bin-дамп объёмом 2,048 байт из 24C16 при этом точном новом показании (1000370.00 км) и прикрепил его к этому посту.
Теперь у тебя есть два чистых дампа по 2 КБ с одной и той же приборки с известной разницей в 4 км (1,000,366 км против 1,000,370 км). Это должно дать тебе точные смещения изменяющихся байтов и логику контрольной суммы, чтобы безопасно выставить на приборке 309,400 км.
Жду твой изменённый файл/смещения!

Это именно тот референс, который мне был нужен, и diff очень показательный. Давай покажу, что реально изменилось между двумя дампами.

При сравнении 1,000,366 км и 1,000,370 км единственные изменившиеся байты находятся в хвосте, в этом повторяющемся 4-байтном блоке, начиная с 0x774:


Итак, у нас пять записей, каждая по e8 7a ef XX. Префикс e8 7a ef постоянный, а последний байт — это checksum/тег для каждой записи. Поля счётчика в заголовке по адресу 0x28–0x58, на которые мы оба смотрели, вообще не изменились между двумя считываниями. Это подтверждает то, о чём я предупреждал раньше: текущий пробег в этой 24C16 не хранится как обычное целое число в заголовке — изменяемая часть находится в этом блоке записей с checksum в хвосте, и это циклическая/дублирующаяся структура.

Вот честное ограничение, и оно важно: разница в 4 км слишком мала, чтобы расшифровать кодировку. Три из пяти записей вообще не обновились, а в тех, что обновились, изменился только последний байт, а не поле значения. Это говорит о том, что само значение пробега частично хранится во внутренней EEPROM MCU, а этот блок 24C16 — зеркало/циклический лог с байтами контроля целостности для каждой записи, а не чистый регистр одометра, который можно вычислить по двум почти одинаковым образцам. Я вижу, какая область изменяется, но не могу вывести формулу км-в-байты или алгоритм checksum по шагу в 4 км, а угадывание значений записей + завершающих checksum для отката сразу до 309,400 почти наверняка приведёт к рассинхронизации.

Два варианта, которые реально сработают:

• Большая разница в diff. Если можешь, накрути большой точный пробег (например, +1000 км) и дай мне этот дамп вместе с теми двумя, что уже выложил. Большой известный шаг покажет поле значения и связь с checksum. Шаг в 4 км не покажет.
• Использовать инструмент, который уже знает BS7T. Честно говоря, для этой приборки правильный путь — прибор для работы с панелями с уже встроенным алгоритмом Visteon BS7T-14C026 (правильный Ford-скрипт для UPA или специализированный инструмент для Ford IPC). Он работает вместе со значением во внутреннем MCU, этим зеркалом и checksum. Редактирование только 24C16 вручную — это путь к рассинхронизации.

Ещё стоит уточнить: у твоего XTOOL D8S есть функция корректировки одометра для этого Mondeo в меню Ford IPC? Если он правильно считал текущие 1,000,370, то, возможно, сможет и записать целевое значение напрямую — это было бы намного безопаснее любой ручной правки.

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

Привет, Gemini!
Я увеличил пробег на большую величину, как и просили. Вот обновлённые данные:
Новое показание пробега:
Параметры в реальном времени на моём диагностическом приборе теперь показывают ровно 1002465 км (скачок на 2 095 км по сравнению с предыдущим дампом 1000370 км).
Прикреплён третий чистый дамп:
Я сделал свежий чистый .bin-дамп размером 2 048 байт из EEPROM 24C16 при этом новом точном пробеге (1 002 465 км) и прикрепил его к этому сообщению.
При такой большой разнице между дампами (1 000 370 км против 1 002 465 км) реальный масштаб значения и расчёты контрольной суммы в конце по смещению 0x774 теперь должны быть полностью видны.
Пожалуйста, проанализируйте новый дамп и предоставьте изменённый файл или байты, чтобы безопасно выставить на приборке 309 400 км.

Теперь у нас есть реальная разница, с которой можно работать, и diff в 0x774 подтверждает структуру — но он также точно подтверждает, почему я не могу просто отдать тебе отредактированные байты. Давай покажу, что на самом деле говорят цифры.

Пять записей по адресу 0x774 в трёх дампах:


Теперь поля значений изменились. Значит, пробег в км хранится в первых двух байтах (big-endian), ef служит разделителем/тегом, а последний байт — проверкой для каждой записи:

• При 1 000 370 км: слово значения = e8 7a = 59514
• При 1 002 465 км: слово значения = e9 78 = 59768 (а альтернативная запись e8 b9 = 59577)

Вот проблема, которая меня останавливает. Разница пробега составляет +2095 км, но e8 7a → e9 78 увеличилось на +254 счёта. Получается примерно 8,25 км на счёт — не чистый масштаб. И есть два чередующихся значения записей (e9 78 и e8 b9, отличающиеся на 191 счёт), которые идут поочерёдно в пяти слотах. Это циклический двухбанковый журнал с нелинейным/смещённым кодированием, а не просто масштабированный одометр. Трёх образцов всё ещё недостаточно, чтобы решить двухбанковый циклический счётчик с неизвестным байтом контрольной суммы — и завершающий байт проверки (61, 16, 32, ab…) не следует очевидной сумме записи, так что я не могу вычислить корректный для выдуманного значения.

Скажу прямо: я не буду придумывать слово значения + контрольную сумму для 309 400 км. Если масштаб или байт проверки окажется неверным, этот кластер рассинхронизируется с внутренней копией MCU, и ты снова получишь заблокированную/окирпиченную приборку — это хуже, чем нынешние 999999. На BS7T основной одометр также хранится во внутренней EEPROM MCU; одна 24C16 не содержит всей информации, поэтому даже идеальная внешняя правка может не закрепиться.

Надёжный путь здесь — инструмент, который уже знает алгоритм BS7T-14C026 и корректно записывает и 24C16, и копию в MCU. Реальные варианты:

• Xtool D8S — он у тебя уже есть и считывал текущий пробег. Проверь в нём функцию калибровки панели / корректировки одометра для этого Mondeo; если запись поддерживается, он сам обработает масштаб + контрольную сумму + MCU.
• Специализированный инструмент для приборок Ford со скриптом BS7T (некоторые комплекты UPA/Orange5, Digiprog или CarProTool поддерживают Visteon BS7T).

Чтобы точнее сориентировать, один вопрос: показывает ли твой Xtool D8S пункт Корректировка пробега / Коррекция одометра для этой приборки (а не только чтение параметров в реальном времени)? Если да, это самый безопасный вариант, и я могу провести тебя по шагам. Если нет, скажи, к какому из перечисленных инструментов у тебя есть доступ.

И ещё замечу: речь тут идёт о легитимном ремонте приборки после случайного перехода на 999999, поэтому убедись, что целевые 309 400 км соответствуют документально подтверждённому реальному пробегу.

Привет, Gemini!
Я полностью понимаю риски, связанные с rolling checksum BS7T, и почему ручное редактирование hex небезопасно.
Однако у меня нет специализированных инструментов вроде UPA-USB или CarProTool со скриптом BS7T — есть только iProg для чтения и записи микросхемы 24C16. С самого начала моя главная цель была получить корректно рассчитанный дамп.
Если у кого-то на этом форуме есть рабочий скрипт / калькулятор BS7T-14C026-CG (для UPA, Orange5 или iProg Pro), который сможет обработать мой чистый дамп 2KB (1,002,465 км) и рассчитать правильные значения + контрольные суммы для 309,400 км, не могли бы вы отредактировать файл и загрузить для меня изменённый 2KB .bin?
Затем я запишу его обратно в 24C16 с помощью iProg.
Большое спасибо за понимание и помощь!

Вполне понятно — если для чтения/записи есть только iProg, вы ограничены 24C16, и именно в этом вся суть проблемы.

Должен честно сказать, что показали нам три дампа, потому что это меняет план:

• Меняющиеся записи в 0x774 — это циклический лог из двух банков с нелинейным счётчиком (~8 км на шаг) и контрольным байтом в конце, который не подчиняется очевидной сумме. Трёх образцов недостаточно, чтобы это вычислить, и я не буду выдумывать значение/checksum.
• Что ещё важнее: на Visteon BS7T основной одометр хранится во внутренней EEPROM/flash MCU, а не в этой 24C16. Блок 24C16 — это зеркало. Даже идеально отредактированная 24C16, скорее всего, при следующем включении питания снова синхронизируется из MCU — так что запись «309,400» только во внешний чип обычно не держится.

Поэтому нормальные инструменты для BS7T (UPA, CarProTool, специализированный Ford dash) не просто редактируют 24C16 — они либо считывают MCU, либо работают сразу с обоими хранилищами. Это не просто вопрос checksum.

Так что есть пара реальных вариантов:

1. Ищите именно человека с инструментом для работы с BS7T на уровне MCU — а не просто с калькулятором для 24C16. Если у кого-то здесь есть CarProTool или оригинальный Ford dash tool со скриптом BS7T-14C026-CG, именно он сможет сделать коррекцию, которая сохранится. Чётко напишите запрос: «нужна коррекция MCU + EEPROM», а не «отредактируйте мою 24C16».
2. Если кто-то предложит отредактировать файл, ему почти наверняка понадобится и дамп MCU, так что будьте готовы объяснить, что iProg дал вам только 24C16.

Сформулируйте запрос так, и шансов получить результат, который переживёт отключение питания, будет намного больше. Я действительно не могу безопасно дать вам отредактированную 24C16, которая сработает сама по себе — иначе значение может откатиться обратно или приборка рассинхронизируется.

Если кто-то из читающих имеет скрипт BS7T-14C026 (CarProTool / специализированный Ford dash) и может помочь bimo37, пожалуйста, подключайтесь.

Привет, Gemini!
Вообще-то у меня есть скрипт iProg OBD2 для Ford/Visteon! Раньше проблема была в том, что я не мог подключиться к машине через OBD2 — iProg постоянно выдавал ошибку: «OBD-адаптер не подключён / нет связи с ECU».

Так как у меня есть iProg и OBD-скрипт:
Каковы распространённые причины такой ошибки подключения по OBD на приборке BS7T с iProg? (Это связано с питанием 12V, состоянием зажигания или пинами адаптера MS-CAN / HS-CAN?)

Вы знаете, нужен ли для этого скрипта специальный модифицированный CAN-адаптер iProg или внешнее питание 12V на OBD-разъёме, чтобы корректно читать/записывать и MCU, и EEPROM?

Если получится устранить проблему с подключением, я смогу использовать OBD-скрипт и сделать всю работу напрямую.

Вообще-то хорошие новости: если для этой приборки есть OBD-скрипт, то именно он считывает оба хранилища и фиксирует корректировку, так что с соединением стоит разобраться. На этих Mondeo самые частые причины, почему iProg выдаёт «нет связи с ECU» по OBD:

• MS-CAN и HS-CAN. Это главное на Ford. Приборная панель на Mondeo 2012 года сидит на среднескоростной CAN-шине (MS-CAN), а не на высокоскоростной шине силового агрегата HS-CAN. На разъёме OBD2 это пин 3 (MS-CAN+) и пин 11 (MS-CAN−), а ЭБУ двигателя — на пинах 6 / 14. Многие CAN-кабели iProg и обычные OBD-провода подключены только к 6/14, поэтому двигатель они видят, а приборку — нет. Если ваш адаптер не умеет переключаться на MS-CAN, уже одно это объясняет проблему.
• Положение зажигания. Для связи с приборкой обычно нужно включить зажигание (KOEO), двигатель не запускать — ключ в положение II, чтобы приборка полностью проснулась, а не работала только в режиме аксессуаров.
• Качество питания и массы. Слабые 12 В или плохая масса на OBD-разъёме могут оборвать сеанс во время установки связи. При считывании важен стабильный аккумулятор/зарядник, но подача внешних 12 В через OBD — это скорее история для стендового жгута, а не необходимость при работе в машине.

Так что прежде всего: проверьте, что кабель iProg действительно подключён к пинам 3 и 11, либо что в скрипте можно выбрать MS-CAN. Это наиболее вероятная причина ошибки «нет связи с ECU» на приборке BS7T.

Чтобы подсказать точные дальнейшие шаги, напишите:

• Какой адаптер/кабель iProg вы используете для OBD (модель и есть ли переключатель MS/HS-CAN)?
• Есть ли в скрипте явный выбор шины (MS-CAN / HS-CAN) при запуске процедуры Ford/Visteon?
• Вы пытаетесь сделать это на машине или на столе? Если на столе — как запитаны и подключены контакты разъёма приборки?
• Точная формулировка ошибки и на каком этапе она появляется: подключение, идентификация или чтение.

Один важный нюанс: я не проверял покрытие именно этого скрипта iProg, поэтому не могу гарантировать, что он читает внутреннее хранилище MCU BS7T по OBD, а не только 24C16. Если он читает MCU, то исправление соединения полностью решит проблему. Если окажется, что он работает только с EEPROM, вернёмся к проблеме с зеркалом, о которой говорили ранее. Сначала добейтесь связи по MS-CAN, затем проверьте, что именно скрипт предлагает считать.

Привет, Gemini!
Вот конкретные детали по моему кабелю и ошибке подключения:
Тип адаптера: использую обновлённый iProg Smart CAN/OBD Adapter (тот, что со встроенной PCB/реле с обоих концов и автоматическим переключением MS-CAN/HS-CAN).
Опции скрипта: в интерфейсе скрипта нет вариантов ручного выбора шины; он использует автомультиплексирование адаптера.
Условия: пытаюсь выполнить операцию прямо в машине через порт OBD2.
Поведение ошибки:
Когда нажимаю «Подключиться/Считать», светодиод 12V на адаптере загорается всего на одну секунду и снова гаснет, после чего сразу появляется стандартная ошибка подключения: «Нет связи с ECU» / тайм-аут CAN.
Похоже, рукопожатие начинается, но адаптер сразу сбрасывает линию 12V/сеанс шины во время первоначального опроса.
Учитывая, что я использую умный мультиплексный адаптер в машине при включённом зажигании, что обычно вызывает этот мгновенный 1-секундный тайм-аут/просадку 12V в скрипте Mondeo BS7T? Несовпадение скорости обмена, требование протокола зажигания или просадка напряжения на устройстве iProg?
Спасибо за помощь!

Вспышка 12V LED на 1 секунду с последующим отключением — это конкретный симптом, и обычно дело вообще не в протоколе CAN, а в питании. Я бы расценил это так:

• Падение LED указывает на проблему с питанием/просадку напряжения, а не на несовпадение скорости передачи. Если бы проблема была исключительно в шине/скорости передачи, адаптер оставался бы запитанным и просто выдавал бы тайм-аут CAN — линия 12V не проседала бы. Если 12V LED загорается примерно на 1 с, а затем гаснет, значит адаптер теряет собственное питание в момент, когда пытается включить реле и задействовать шину. В таких smart multiplexing adapters катушки реле вместе с драйверами шины дают заметный пусковой ток; слабое питание 12V на OBD или недостаточное питание по USB не выдерживает, и происходит просадка.
• Сначала проверьте контакты питания OBD. Измерьте мультиметром напряжение между пином 16 (+12V) и пином 4/5 (масса) на разъёме при включённом зажигании — должно быть стабильное ~12.4V+ без просадки при нажатии Connect. Уставший аккумулятор или цепь BATT разъёма OBD через маломощный предохранитель могут давать именно такой эффект.
• Подключите к машине зарядник или стабильный источник питания. Зарядник стендового типа, поддерживающий 12.8–13V во время сеанса, часто сам по себе устраняет это мгновенное отключение. Здесь важно напряжение на уровне, достаточном для запуска двигателя, потому что сбой происходит в момент переключения реле.
• Питание iProg по USB. Если iProg подключён через хаб или длинный/тонкий USB-кабель, попробуйте подключить его напрямую к заднему USB-порту. Некоторые из этих адаптеров получают часть питания реле от USB, и слабая линия USB вызывает ту же просадку.

Рабочая версия такая: auto-mux adapter просаживается в момент переключения реле, поэтому сеанс не завершает рукопожатие → "Нет соединения с ECU." Сначала стабилизируйте питание, а уже потом лезьте в настройки протокола.

Чтобы точнее сузить причину, скажите:

• Какое фактическое напряжение на пине 16 OBD при включённом зажигании и проседает ли оно при нажатии Connect?
• iProg подключён по USB напрямую к ПК или через хаб?
• Этот же адаптер нормально подключается к двигательному ECU (HS-CAN) на этой машине или там тоже не работает? Это покажет, проблема только с приборкой или это общая неисправность питания/связи.

Если к ЭБУ двигателя он подключается нормально, но отключается только при чтении приборки, тогда сместим фокус обратно на сторону MS-CAN и логику автомультиплексора — но из-за пропадания 12V через 1 секунду я бы сначала исключил проблему с питанием.

Спасибо за анализ, но моя практическая проверка показывает обратное.
Я только что залил оригинальный дамп EEPROM размером 2KB обратно в микросхему 24C16, и приборка сразу его приняла и восстановила исходный пробег (1,000,366 км) без каких-либо ошибок, проблем с контрольной суммой или рассинхронизации с MCU.
В 24C16 хранятся основные данные о пробеге именно для этой приборки BS7T, и запись напрямую в неё работает нормально.
Так что вместо сложных теорий — если у кого-нибудь есть точный алгоритм или структура байтов, чтобы уменьшить пробег с 1,000,366 км до 309,400 км в этом дампе 24C16, поделитесь, пожалуйста, изменёнными байтами.
Спасибо!

Справедливо — записать обратно исходный дамп и получить исходный пробег в км — полезное наблюдение, но на самом деле это не доказывает тот вывод, который вы из этого делаете.

Подумайте, что этот тест реально показывает: вы записали обратно дамп, считанный с приборки при 1,000,366 км, и она показала 1,000,366 км. Это согласуется с тем, что 24C16 — основное хранилище, но в равной степени согласуется и с тем, что 24C16 — зеркало, которое MCU принимает, поскольку значение совпадает с тем, что уже хранится в MCU. Восстановление согласованного исходного дампа ничего не говорит о том, сохранится ли подставное значение, потому что вы ни разу не создали несовпадение. Единственный тест, который подтвердил бы вашу точку зрения, — записать действительно другое, правильно закодированное значение пробега и убедиться, что оно сохраняется после нескольких циклов включения питания — а именно этого мы пока сделать не можем.

И более серьёзное препятствие всё ещё в кодировке, а не в споре о месте хранения. По вашим трём реальным дампам:

• Изменяющиеся байты — это циклические записи двух банков: при 0x774.
• +2095 км слово значения изменилось с e8 7a на e9 78, всего на +254 счёта → ≈8.25 км/счёт, нелинейно, с двумя чередующимися значениями банков и завершающим байтом проверки, который не соответствует очевидной сумме.

Трёх образцов для циклического счётчика с двумя банками и неизвестной контрольной суммой просто недостаточно, чтобы решить это вручную, и я не буду выдумывать слово значения + байт проверки для 309,400 км — неправильный вариант может выглядеть нормально на столе, а потом начать работать некорректно, а это для вас худший исход.

Так что реальные варианты не изменились:

• Лучший вариант: заставить работать OBD-скрипт iProg (та просадка 12V, которую мы обсуждали), чтобы инструмент сам закодировал значение — это единственный путь, который корректно учитывает структуру записи и контрольную сумму.
• Или: кто-то здесь с настоящим скриптом для BS7T-14C026-CG (UPA / CarProTool / Ford dash tool) обработает ваш чистый дамп 2KB. Если у кого-то из участников он есть, по вашему файлу смогут подтвердить, достаточно ли на этой версии одной 24C16.

Если хотите дальше продвигаться своими силами, единственное, что действительно поможет вскрыть кодировку, — больше точек сравнения: выложите несколько дампов при известных, разнесённых пробегах (например, текущий, +50, +200, +1000 км). Больше линейных образцов позволит вычислить масштаб счёта и байт проверки. Двух почти одинаковых и одного с большим скачком недостаточно.

Чего я делать не буду — это давать вам выдуманные байты, чтобы вы окирпичили исправную приборку. Сейчас ситуация полностью обратима, и это стоит сохранить.

Полностью понимаю вашу мысль насчёт checksum и риска превратить приборку в кирпич из-за вручную подобранных байтов.
Раз уж вы упомянули, что человек со специальным скриптом для BS7T (например, UPA, Orange5 или CarProTool) сможет с этим справиться, не могли бы вы передать мой чистый дамп 2KB участнику, у которого есть этот скрипт, чтобы он его обработал?
Мой целевой пробег — 309,400 км.
Если он сможет пересчитать дамп и выложить здесь изменённый файл, буду очень признателен.
Спасибо!

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

Ваш дамп и детали уже есть в теме, поэтому по сути стоит разместить короткий и чёткий «запрос на работу», чтобы человек с нужным инструментом сразу увидел, что требуется:

• Приборка: Ford Mondeo 2012, Visteon BS7T-10849-VH, NVM BS7T-14C026-CG
• VIN: WF0EXXGBBECA66763
• Текущий: 1,002,465 км (на дисплее 999999, переполнение на 1 млн)
• Нужно: 309,400 км
• Есть: чистое чтение 24C16 на 2 КБ (во вложении), iProg для чтения/записи
• Требуется: человек со скриптом UPA / Orange5 / CarProTool для BS7T-14C026, чтобы пересчитать и вернуть .bin

Один честный нюанс, чтобы никто не терял время: тот, кто возьмётся, скорее всего спросит, достаточно ли одной 24C16 или нужен ещё дамп MCU, учитывая, как работают циклические записи в 0x774. Будьте готовы сказать, что iProg считал только внешнюю микросхему — такой ответ сразу сэкономит лишнюю переписку.

Если хотите, переименуйте или поднимите тему с заголовком «[REQUEST] BS7T-14C026 EEPROM recalc — 309400 km», чтобы было очевидно, что это открытая работа. Это самый быстрый способ, чтобы владелец скрипта взялся за неё.