на самом деле не все панели капризничают .
Всё зависит от того , как в панели прописан сам алгоритм обновления данных. По причине того , что проц минимально может стирать только по 4 строки сразу (64 байта ) , а писать изнутри по 4 байта , то стиранием перед записью панель не заморачивается . Панель считает , что там пустого места , хоть конём гуляй. Но... Панель пишет 4 байта , а через некоторое время опять 4 байта... А прогер пишет сразу 16 байт. И вся строка получается записанной . Так вот ... Если панель захочет записать в строку вторые (или третьи или червертые ) 4 байта , то нарвется на уже записанные программатором байты , и произойдет ошибка записи, тк запись возможна только в стёртые байты. А , напомню , FF в этих процах , это не стёртое состояние, а уже записанное ))).
Во избежание недоразумений обычно читают 100 раз подряд рабочую панель , с передёргиванием питания . Получаете 100 отличающихся друг от друга дампов. И из 100 сохраненных дампов , вероятно будет хоть один , который не будет вводить панель в ступор. Просто этот дамп будет пытаться писать в начало строки.
Или поступать как в ренелайте . Стирать и писать не весь дамп , а только нужные блоки по 4 строки в каждом блоке . Но зачастую и это не спасает.
Или при записи подставлять нужные строки , которые 100% будут оставлять панель работоспособной.
Если в скрипте к айпрогу есть привязка к маркам или моделям , то это не 4 байтовое чтение или запись , а скорее всего подстановка нужных кусков , или автор скрипта досконально разобрался в дампе, и знает , что на что можно менять .
А настоящая запись по 4 байтам , это когда пофиг , какая марка и какая модель. Прочитал , записал , и всё работает.
Кстати ...В бодике камри 70 тоже такая история при записи оригинального дампа....