Нужен оригинальный дамп внутренней флеш-памяти CAS3 (MC9S12XDP512 0L15Y) – BMW E87 2011 118d – 61.35-9237047-01

  • Автор темы Автор темы rockzt888r
  • Дата начала Дата начала

Сообщение #1

rockzt888r

rockzt888r

Участник в стоке
Филиппины
С нами
05.08.2026
Сообщения
6
Реакции
0
Страна
Филиппины
Всем привет,

Надеюсь, кто-нибудь сможет помочь восстановить мой модуль CAS. Ищу оригинальный дамп внутренней flash (512 KB) от такого же модуля CAS3. Если у кого-то такой CAS есть на столе и он готов поделиться дампом flash, буду очень благодарен.

Информация об автомобиле:

Автомобиль: BMW 320d
Кузов: E90 LCI
Год модели: 2011
Двигатель: N47 Diesel
Коробка передач: автоматическая
VIN: WBAUD71060P495192

Информация о модуле CAS:

Модуль: CAS3
Производитель: Siemens VDO
Номер детали BMW: 61.35-9237047-01
Номер Siemens: 5WK4 9515EBR
Версия ПО:
MCV: 00.00.00
FSV: 2.6.4
OSV: 3.3.0
HW/SW/Coding/Diag Index: C4 / 21.2 / 09 / 06A0
MCU: Freescale MC9S12XDP512
Mask: 0L15Y
Размер внутренней Flash: 512 KB
EEPROM: 95320 (4 KB)

Исходные данные:

VIN: WBAUD71060P495192
Пробег: 46,253 km
CAS ISN: 62B4AAF4
EEPROM: проверена и выглядит целой.

Что произошло???

При попытке сделать бэкап и перезаписать внутреннюю flash через XPROG 5.55 возникла ошибка связи во время программирования. После исправления пайки я смог успешно читать и записывать EEPROM, но внутренняя flash, похоже, оказалась повреждена или записана не полностью.

EEPROM корректно расшифровывается с:

правильным VIN
Correct ISN
правильным пробегом
валидными ключами

Но CAS больше не загружается.

Текущие симптомы:

CAS не выходит на связь через INPA/ISTA.
INPA сообщает IFH-0009: нет ответа от блока управления.
Ключ не фиксируется в слоте зажигания.
Автомобиль полностью мёртвый.
Нет зажигания (Terminal 15).
Стеклоподъёмники, свет и другие функции кузова не работают.
Панель приборов только кратко показывает сохранённый пробег при нажатии кнопки теста приборки.
ELV не определяется, потому что CAS offline.

Использованный программатор:

Программатор: XPROG 5.55
Подключение: прямое BDM-подключение пайкой
Питание: только адаптер XPROG (программирование на столе)
MCU: MC9S12XDP512 (0L15Y secured)
EEPROM: успешно прочитана и записана
Flash: программирование пишет об успехе, но последующие чтения часто заканчиваются "Device is silent".

Что я ищу:

Ищу 100% оригинальный дамп внутренней flash 512 KB от такого же модуля CAS:

BMW Part No.: 61.35-9237047-01
Siemens VDO 5WK49515EBR
CAS3
MC9S12XDP512
0L15Y

VIN and ISN не обязательно должен совпадать с моим автомобилем. Мне нужен только заведомо исправный оригинальный flash, чтобы сравнить его с моим бэкапом или попробовать восстановить модуль.

Если у кого-то есть точно такой CAS на столе и вы можете поделиться оригинальной внутренней flash 512 KB, буду искренне признателен за помощь.

Заранее спасибо всем, кто готов помочь.
 

Вложения

  • Нужен оригинальный дамп внутренней флеш-памяти CAS3 (MC9S12XDP512 0L15Y) – BMW E87 2011 118d – 61.35-9237047-01 — вложение 1
    BMW CAS MODULE.webp
    51,1 КБ · Просмотры: 26
Оценки и отзывы
Всего оценок: 0
Сортировать по дате Сортировать по голосам

Сообщение #2

Сначала хорошая новость: раз ваш EEPROM (95320) целый и корректно декодируется с правильными VIN, ISN, пробегом и рабочими ключами, это полностью восстановимо. Донорская внутренняя флеш от любого подходящего CAS3 снова даст блоку загрузиться, потому что во флеше лежит только программа/OS — все данные, привязанные к машине, находятся в 95320. Вам не нужна VIN-matched флеш, нужна только совместимая по версии.

Главный момент для чистого восстановления: подобрать флеш под ваш уровень прошивки, чтобы структуры флеша и EEPROM совпадали. По вашей наклейке:

  • MCU: MC9S12XDP512, маска 0L15Y
  • FSV 2.6.4 / OSV 3.3.0
  • HW/SW/Cod/Diag индекс: C4 / 21.2 / 09 / 06A0
  • P/N 61.35-9237047-01, Siemens 5WK4 9515EBR

Безопасный вариант — донорская флеш из той же семьи 5WK49515 / 9237047 с тем же OSV 3.3.0. Если залить другой OSV, ожидания по раскладке EEPROM могут отличаться, и потом может понадобиться обновлять/выравнивать EEPROM.

Пара моментов, которые стоит проверить, прежде чем считать, что вся проблема только во флеше:

  • Изначальная ошибка XPROG произошла в середине записи. Убедитесь, что пайка/BDM-подключение сейчас надежные и стабильные — плохой BDM-канал снова испортит запись. Переподключите, пропаяйте, проверьте прозвонкой все линии BDM и питание.
  • После записи донорской флешки сделайте полное повторное чтение и сверьте его с файлом. Одному "write OK" не доверяйте.
  • Убедитесь, что защищенные сектора и область D-Flash обрабатываются так, как XPROG ожидает для этого MCU — запись только части областей часто и оставляет блок мертвым.

Чтобы помочь подобрать правильного донора и понять, нужна ли еще какая-то правка EEPROM после прошивки, подтвердите:

  • Что именно записывал XPROG — только полный internal flash или flash + D-Flash/EEPROM?
  • XPROG сейчас еще видит/ID MC9S12XDP512 по BDM, или чтение тоже падает?
  • У вас остался исходный (поврежденный) дамп флеша, хотя бы частичный? Даже плохой дамп помогает подтвердить размеры областей.

Выложите это, и кто-нибудь с подходящим дампом 3.3.0 на столе сможет подогнать его под вас.
 
За 0 Против

Сообщение #3

Спасибо за подробный ответ. Благодарю за рекомендации.

Вот ответы на ваши вопросы:
  1. Что именно записал XPROG — только всю внутреннюю flash или flash + D-Flash/EEPROM?
Изначально я записал только внутреннюю flash (P-Flash). После этого отдельно восстановил свою оригинальную EEPROM (95320). Сейчас EEPROM совпадает с моим исходным бэкапом бит в бит и корректно декодируется с оригинальными VIN, ISN, пробегом (46,253 km) и ключами.

  1. XPROG сейчас всё ещё видит/ID MC9S12XDP512 по BDM, или чтение тоже не проходит?
Поведение нестабильное.
  • XPROG всё ещё может определить MC9S12XDP512 (0L15Y) и получать доступ к EEPROM.
  • Чтение/запись/верификация EEPROM проходят успешно.
  • Доступ к flash ненадёжный. Иногда она читается, но в другие разы процесс останавливается на "Bypass Security" или выдаёт "Device is silent" во время чтения flash.
  • После записи обратное считывание показало, что большие участки первых 512 KB остались стёртыми, что говорит о том, что flash программируется не полностью.
  1. У вас всё ещё есть исходное (повреждённое) чтение flash, хотя бы частичное?
Да. У меня всё ещё есть:
  • Мой исходный бэкап внутренней flash 512 KB.
  • Мой исходный бэкап flash 2 MB в формате XPROG.
  • Несколько дампов flash, считанных обратно после программирования.
  • Оригинальная EEPROM.
  • Восстановленная EEPROM.
Я подробно их сравнивал. EEPROM подтверждённо в порядке.
Проблема изолирована во внутренней flash. Дампы, считанные после записи, никогда не совпадают с оригинальной flash, а CAS по-прежнему вообще не выходит на связь:
  • Нет связи с CAS в INPA (IFH-0009)
  • Ключ не фиксируется в слоте
  • Нет Terminal 15
  • Автомобиль полностью мёртвый
Информация по CAS:
  • Номер детали BMW: 61.35-9237047-01
  • Производитель: Siemens VDO
  • № Siemens: 5WK49515EBR
  • MCU: MC9S12XDP512
  • Маска: 0L15Y
  • FSV: 2.6.4
  • OSV: 3.3.0
  • Индекс диагностики: 06A0
Ищу именно заведомо исправную оригинальную внутреннюю flash 512 KB из той же линейки 5WK49515EBR / 61.35-9237047-01 / OSV 3.3.0. VIN does не обязательно должен совпадать, потому что я оставлю свою оригинальную EEPROM.

Буду очень благодарен за любую помощь или донорский flash из той же аппаратно-программной линейки. Спасибо.
 
За 0 Против

Сообщение #4

Спасибо за подробные ответы — это на самом деле сильно сужает круг, и всё указывает не на «мне нужен донорский файл», а на «путь записи по BDM/во flash всё ещё ненадёжен».

Два симптома, которые вы описываете, как раз всё выдают:

  • EEPROM (сторона D-Flash) читается/пишется/верифицируется идеально, но
  • P-Flash периодически зависает на Bypass Security / Device is silent, а при чтении обратно большие области остаются стёртыми (0xFF).

Такое сочетание почти никогда не означает плохой донорский образ — обычно это пограничная связь по BDM, нестабильное питание цели или незавершённая разблокировка защищённой flash. Если бы чип был реально «окирпичен», он бы вообще не определялся и не общался с EEPROM. Поэтому перед прошивкой любого донора:

  • Питание: запитайте CAS от чистого, стабильного лабораторного БП, а не только от паразитного питания через BDM. Просадка напряжения во время импульса mass-erase/program — классическая причина «Device is silent» в середине записи.
  • Целостность BDM: «то читает, то молчит» = физическая проблема. Ещё раз проверьте целостность и длину линий BDMCLK, BDMDATA, RESET и GND; провода держите короткими. Плавающая линия RESET может уронить чип прямо посреди последовательности.
  • Security/erase: зависание на «Bypass Security» означает, что шаг unsecure/mass-erase не завершается. На XDP512 обычно нужно, чтобы полный mass-erase (P-Flash и защищённые секторы) завершился перед чистой записью — частичное/прерванное стирание как раз и оставляет такой рисунок стёртых областей, который вы видите. Дайте ему полностью пройти unsecure/erase, подтвердите blank check, потом программируйте, затем сделайте полное чтение обратно и побайтовое сравнение.

Только когда вы сможете надёжно прочитать обратно все 512 KB и верифицировать, донорская flash имеет смысл — и да, ваша целая 95320 значит, что донор той же версии (та же семья 9237047 / 5WK49515, OSV 3.3.0) его запустит.

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

  • Точная версия/сборка XPROG и какой script/adapter вы выбираете для 0L15Y (там есть отдельные варианты «read» и «read+unsecure», здесь это важно).
  • Скриншот точного места, где он останавливается на «Bypass Security» / «Device is silent».
  • Питаете ли вы CAS внешне или только от программатора.

Если связь по BDM стабильная, а защищённое стирание всё равно не завершается, тогда я бы уже сказал, что контроллер P-Flash пострадал во время изначально прерванной записи — но сначала давайте исключим подключение, потому что всё, что вы описали до сих пор, выглядит восстановимым.
 
За 0 Против

Сообщение #5

Спасибо за подробный анализ и рекомендации. Ценю, что вы нашли время разобраться в моём случае.

1. Версия/сборка XPROG и использованный скрипт
  • Программатор: XPROG 5.55 (clone)
  • Выбранное устройство: MC9S12XDP512 – FLASH Secured – 0L15Y
  • Адаптер: стандартный адаптер XPROG MC9S12X с прямым подключением пайкой к BDM.
  • Никакой альтернативный скрипт "read + unsecure" я не использовал — только стандартную опцию secured 0L15Y, доступную в XPROG.
2. Где останавливается

Поведение нестабильное.
  • Сначала я смог успешно прочитать и EEPROM, и FLASH.
  • Во время первоначального программирования XPROG выдал ошибку связи. После пропайки BDM-соединений я снова смог связаться с MCU.
  • Сейчас чтение FLASH иногда зависает на "Обход защиты" (0%), а иногда продолжается, но в итоге выдаёт "Устройство молчит."
  • Доступ к EEPROM остаётся стабильным. Я по-прежнему могу читать, писать и проверять 95320 без ошибок.
3. Источник питания

CAS питался только от адаптера XPROG во время всех операций чтения/записи. Внешний регулируемый лабораторный блок питания я не использовал.

После вашего объяснения я понимаю, что это могло повлиять на нестабильность во время стирания/программирования flash, особенно при цикле массового стирания.

Дополнительные наблюдения
  • У меня всё ещё есть оригинальный бэкап внутренней flash на 512 KB и оригинальная EEPROM.
  • EEPROM была восстановлена и побитно проверена по оригинальному бэкапу.
  • EEPROM корректно расшифровывается с оригинальными VIN, ISN, пробегом и ключами.
  • Каждое чтение FLASH после программирования отличается от исходного файла.
  • В одном сравнении первые 512 KB содержали большие области, оставшиеся как 0xFF, при этом были запрограммированы только отдельные сектора.
  • В автомобиле CAS полностью не выходит на связь:
    • INPA сообщает IFH-0009 (Нет ответа от блока управления).
    • Ключ больше не фиксируется в слоте.
    • Нет клеммы 15.
    • Автомобиль фактически мёртв.
Исходя из вашего объяснения, следующим шагом я улучшу схему программирования: буду использовать стабильный внешний лабораторный блок питания и заново проверю каждое BDM-соединение перед очередной попыткой записи флеш-памяти.

Если у кого-то есть опыт восстановления MC9S12XDP512 (0L15Y) после прерванной записи через XPROG или есть дополнительные рекомендации по XPROG 5.55 именно для этого CAS3, буду очень благодарен за совет.

Ещё раз спасибо за помощь.
 
За 0 Против

Сообщение #6

Вот оно — пункт 3 почти наверняка и есть корень проблемы. Питать CAS только от адаптера XPROG нормально для EEPROM (мизерный ток, нет высоковольтных операций), но mass-erase и программирование P-Flash на XDP512 потребляют больше и чувствительны к таймингам. Паразитное питание по BDM проседает ровно во время импульса стирания/записи, поэтому у вас "Bypass Security" висит на 0% и "Device is silent" появляется в середине прошивки, а EEPROM при этом читается/пишется железно.

Раз у вас всё ещё есть оригинальный бэкап flash на 512 KB, возможно, донор вообще не понадобится — попробуйте заново прошить свой родной дамп, когда питание и линия BDM будут стабильны.

Сделайте это по порядку, прежде чем трогать донорский файл:

  • Внешнее питание: подайте на CAS питание на нужный пин от регулируемого лабораторного БП (чистые 12–13.8 V, с запасом по току в пару ампер). Не полагайтесь на питание от адаптера при операциях с flash.
  • Связь BDM: BDMCLK/BDMDATA/RESET/GND должны быть короткими и надёжными. Ваше "то читает, то молчит" всё ещё частично физическая проблема — пропаяйте и проверьте прозвонкой все четыре линии.
  • Полное снятие защиты + mass-erase: с опцией secured 0L15Y дайте unsecure/mass-erase полностью завершиться и перед программированием запустите blank check. Большие стёртые области (0xFF) в ваших считываниях означают, что этап программирования обрывается, а не что файл плохой.
  • Запрограммируйте свой оригинальный бэкап 512 KB, затем сделайте полное чтение обратно и побайтово сравните с файлом. Доверять можно только если совпадение 100%.

Если после стабильного питания и подтверждённого полного mass-erase P-Flash всё равно не принимает полную запись и не читается обратно чисто, тогда кристалл мог пострадать от предыдущих сорванных записей — это единственный сценарий, где донорская flash становится реальным решением, а не обходным путём.

Один момент для проверки: на какой пин вы подаёте внешнее питание, и проходит ли у XPROG blank check по всем 512 KB после mass-erase? Если сам blank check падает или проходит нестабильно, это всё ещё проблема питания/линии BDM, а не содержимого flash.
 
За 0 Против

Сообщение #7

qq
 

Вложения

За 0 Против

Сообщение #8

Предупреждение по cas3_bkp_0L15Y.bin — это не чистый полный дамп, так что пока не отдавай его rockzt888r как донор.

Что видно по выбранным байтам:

  • Таблица векторов reset/interrupt в начале и код примерно с 0x40000 дальше выглядят как настоящая прошивка XDP512 CAS3, так что это реальное чтение с живой детали.
  • Но есть большие участки, забитые 0x3F (цепочки ??????) — например, около 0x3FF40–0x3FFFF и 0x7FE80–0x7FFF0. Такая заливка 3F — это ровно шаблон-заглушка "read failed / bus silent", а не валидное содержимое flash. Нормально запрограммированный сектор читается как реальный код или как 0xFF в стёртом состоянии, но никогда как сплошной 0x3F.
  • Общая энтропия всего 5.46 бит/байт, что низковато и похоже на частичное чтение, дополненное такими областями 3F.

Так что у этого файла та же сигнатура, с которой сейчас борется rockzt888r: нестабильное чтение по BDM, при котором выпадают целые сектора. Если это снято у тебя на столе при стабильном питании, стоит перечитать; если это предполагается как донор для него, CAS с этим не загрузится, потому что эти блоки 3F — не реальные программные данные.

С чьей детали это снято — у тебя на столе или с кандидата в доноры? И какой источник/статус чтения: было прочитано за один чистый проход с verify или это одно из прерывистых чтений? Если это донор, нужен дамп полной длины, который возвращается без заливки 3F и проходит повторное чтение байт-в-байт, прежде чем его можно будет использовать.
 
За 0 Против

Сообщение #9

Ещё раз спасибо за подробное объяснение. Это вполне логично, и я обязательно повторю восстановление с использованием стабилизированного внешнего лабораторного блока питания, а не буду полагаться только на адаптер XPROG.

Однако есть один момент, из-за которого я всё же хочу найти донорский flash.

Я не полностью уверен, что мой исходный бэкап flash на 512 KB действительно исправен.

Первоначальная запись не удалась из-за проблемы со связью во время процесса записи, а до этого у меня уже были периодические проблемы с BDM-соединением. Хотя у меня есть оригинальный бэкап 512 KB, который я сделал до записи, я не могу на 100% утверждать, что сам бэкап не был затронут нестабильным BDM-соединением или ошибками чтения.

Из-за этой неопределённости я не хочу считать свой исходный flash заведомо исправным эталоном. Мой план такой:
  1. Улучшить аппаратную часть, используя стабилизированный внешний блок питания, и проверить все BDM-соединения.
  2. Попробовать снова записать мой исходный бэкап 512 KB и выполнить полную побайтовую проверку чтением обратно.
  3. В то же время я всё равно хотел бы получить заведомо исправный донорский flash от того же семейства CAS (61.35-9237047-01 / Siemens VDO 5WK49515EBR / MC9S12XDP512 0L15Y / OSV 3.3.0).
Наличие проверенного донорского flash позволило бы понять, в чём проблема:
  • в ненадёжном исходном бэкапе,
  • в процессе записи,
  • или в самом MCU.
Так что, хотя я полностью согласен, что сначала нужно решить вопрос со стабильным питанием и целостностью BDM, я всё равно ищу донорский flash, потому что пока не могу гарантировать, что мой исходный бэкап не повреждён.

Если у кого-то есть оригинальная 512 KB внутренняя flash-память из того же семейства аппаратной/программной части CAS3 и он готов ей поделиться, буду искренне благодарен за помощь. Это было бы крайне ценно как заведомо исправный эталон для сравнения и восстановления.

Ещё раз спасибо всем, кто уделил время и помогал разобраться с этой проблемой.
 
За 0 Против

Сообщение #10

План у тебя абсолютно правильный, и иметь заведомо исправного донора как эталон — разумный способ отделить проблему бэкапа от процесса и от MCU. Но прежде чем искать донора, проверь свой собственный оригинальный бэкап — скорее всего, вопрос «мой бэкап нормальный?» можно закрыть прямо сейчас самому.

Тот же тест, который я применил к файлу, выложенному Bin: открой свой оригинальный бэкап 512 KB в hex-редакторе и посмотри, нет ли сплошных участков заполнения 0x3F. На этом семействе XDP512:

  • Нормально считанная flash выглядит как реальные данные кода/векторов или 0xFF в действительно стёртых областях.
  • Большие блоки сплошного 0x3F = заглушка «шина молчит / чтение не удалось», то есть плохое чтение, а не реальные данные.

Если твой бэкап чистый (реальные векторы вверху, код примерно с 0x40000, без областей заполнения 3F вроде тех, что на 0x3FF40 и 0x7FE80 в файле Bin), значит это хороший референс, и ему можно доверять, когда питание/BDM будут стабильны. Если там есть такие участки 3F, тогда да — он был снят по нестабильной линии, и донор действительно нужен.

По самому донору: если отбросить структуру файла, подходящий донор для твоего случая — P/N 61.35-9237047-01 / 5WK49515EBR / XDP512 0L15Y / OSV 3.3.0. Любой донорский файл, который тут предложат, нужно проверять так же, прежде чем ему доверять: полное чтение без заполнения 3F, которое проходит повторное побайтное считывание, иначе блок окирпичится точно так же.

Можешь выложить такой же hex-срез начала/конца своего оригинального бэкапа 512 KB (смещения 0x0, ~0x3FF00 и ~0x7FE00)? Этого достаточно, чтобы сразу понять, пригоден ли твой собственный бэкап и нужно ли вообще ждать донора.
 
За 0 Против

Сообщение #11

Спасибо, что предложили этот тест. Я проверил свой исходный backup 512 KB ровно так, как вы описали.
К сожалению, мой backup действительно содержит большие области, заполненные 0x3F, особенно в районе смещений 0x3FF00, 0x3FF40 и 0x7FE80.

В начале файла есть то, что похоже на корректный код/данные, но повторяющиеся шаблоны заполнения 0x3F совпадают с тем, что вы описали как неудачное или неполное чтение через BDM, а не как настоящие данные flash. Из-за этого я больше не могу быть уверен, что мой исходный backup — это корректный эталон. Теперь похоже, что сам backup мог быть снят уже в тот момент, когда связь по BDM была нестабильной.

Это подтверждает мое решение продолжать искать заведомо исправный донорский flash 512 KB из того же семейства hardware/software (BMW 61.35-9237047-01 / Siemens VDO 5WK49515EBR / MC9S12XDP512 0L15Y / OSV 3.3.0), параллельно улучшая свою схему программирования с регулируемым внешним блоком питания и проверяя подключения BDM.

Еще раз спасибо, что направили меня на проверку областей заполнения 0x3F — это был очень полезный диагностический шаг.
 
За 0 Против

Сообщение #12

Тогда всё ясно — в твоём бэкапе та же сигнатура заполнения 0x3F, что и в файле Bin, значит он был считан через нестабильное BDM-соединение и ему нельзя доверять как эталону. Хорошо, что ты подтвердил это сейчас, а не после ещё одной неудачной записи.

Так что твой план из трёх направлений — правильный: стабильное питание на столе + проверенный BDM, потом заведомо исправный донор, чтобы отделить проблему бэкапа от процесса и от MCU. Пока ждёшь донора, держи в голове две вещи:

  • Твои данные, привязанные к машине, в любом случае в безопасности — VIN, ISN, пробег и ключи все находятся в EEPROM 95320, которую ты уже побитно подтвердил как исправную. Донорская flash даёт только программу/OS, так что не-VIN-matched донор подойдёт, если он из той же семьи OSV 3.3.0.
  • Проверяй любого донора ровно тем же тестом 0x3F, прежде чем его прошивать. Кто угодно может выложить «хороший» дамп, который на самом деле был считан через глючное соединение — файл Bin это уже доказал. Годный донор должен показывать настоящие векторы в начале, код примерно с ~0x40000, без сплошных участков заполнения 0x3F, и у человека на его собственном столе он должен проходить полное повторное считывание байт-в-байт.

Один практический момент: отсюда я не могу подтвердить, есть ли у кого-то в теме реально чистый подходящий дамп на столе — это зависит от того, откликнется ли кто-то из участников. Такие запросы доноров обычно двигаются быстрее с баунти/предложением обмена, так что в запросе стоит прямо написать, что тебе нужен 61.35-9237047-01 / 5WK49515EBR / XDP512 0L15Y / OSV 3.3.0, полные 512 KB, считывание проверено на отсутствие 3F.

Когда заново сделаешь запись со стабилизированным питанием, выложи фрагменты начала и конца свежего повторного чтения, и я помогу подтвердить, что всё считалось чисто.
 
За 0 Против

Сообщение #13

Большое спасибо, что нашли время проанализировать мой бэкап и объяснили значение 0x3Fшаблона заполнения. Это наблюдение было тем, о чем я не думал, и оно полностью изменило мою уверенность в исходном бэкапе.

Проверив свой исходный flash на 512 KB, я нашел такие же большие 0x3Fобласти заполнения, так что согласен, что сам бэкап уже нельзя считать надежным эталоном. Теперь похоже, что исходное чтение могло быть затронуто нестабильным BDM-соединением еще до того, как я вообще попытался перепрограммировать CAS.

Хорошая новость в том, что мой 95320 EEPROM был проверен несколько раз. Он побитово identical исходному бэкапу и корректно декодируется с:
  • VIN: WBAUD71060P495192
  • Оригинальный ISN
  • Оригинальный пробег
  • Действительные ключи
Это по крайней мере дает мне уверенность, что данные, привязанные к автомобилю, сохранились.

Я обязательно последую вашим рекомендациям:
  1. Использовать регулируемый внешний лабораторный блок питания вместо питания от XPROG.
  2. Перед любыми операциями с flash заново пропаять/проверить все BDM-соединения.
  3. Проверять каждый flash полным обратным чтением и побайтовым сравнением.
  4. Проверять любой донорский flash на наличие областей заполнения 0x3F, прежде чем считать его пригодным эталоном.
Я все еще ищу проверенный, чистый внутренний flash 512 KB от следующего CAS:
  • BMW Part No.: 61.35-9237047-01
  • Manufacturer: Siemens VDO
  • Siemens No.: 5WK49515EBR
  • MCU: MC9S12XDP512 (0L15Y)
  • OSV: 3.3.0
  • FSV: 2.6.4
VIN does не обязательно должен совпадать. Мне нужен только заведомо исправный, проверенный дамп flash без областей заполнения 0x3F, который был успешно считан обратно и проверен.

Если у кого-то есть точно такой модуль CAS на столе и вы готовы поделиться проверенным дампом внутреннего flash 512 KB, буду крайне благодарен. Также готов компенсировать ваше время, если нужно.

Еще раз спасибо всем за технические советы и за помощь в сужении круга поиска. Это было невероятно полезно.
 
За 0 Против

Сообщение #14

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

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

  • Спецификация: 61.35-9237047-01 / 5WK49515EBR / XDP512 0L15Y / OSV 3.3.0 / FSV 2.6.4, полный 512 KB
  • Прямо попроси проверенный дамп без 3F, который прошёл полное повторное побайтовое чтение на собственном стенде донора
  • VIN match не требуется (данные, привязанные к машине, у тебя в 95320)

Когда кто-то предложит файл, перед тем как ему доверять, прогоняй на нём ровно тот же тест 0x3F — настоящие векторы в начале, код примерно с ~0x40000, без сплошных участков заполнения 0x3F. Если видны любые блоки 3F, значит, его читали по нестабильной линии, и он точно так же окирпичит блок, как бы уверенно файл ни был подписан как «хороший».

И когда будешь заново записывать свой файл с нормальным стабилизированным питанием и надёжным BDM, скинь сюда куски начала/хвоста (0x0, ~0x3FF00, ~0x7FE00) — по ним сразу будет видно, прошло ли твоё повторное чтение наконец чисто, и, возможно, на этом этапе донор уже даже не понадобится.
 
За 0 Против
Активность
Пока здесь никого нет