Прошивка EEPROM блока AirbagVW10 при помощи USB-программатора CH341A
В предыдущем посте — www.drive2.ru/l/540840424927920973/ у меня отвалился блок управления airbag.
Прозвонил несколько мест, которые восстанавливают блоки управления подушками после аварий, правят дампы EEPROM и после всех этих разговоров, сказок и ценников принял решение разобраться с этим вопросом самостоятельно, тем более, что опыт в перепрошивке всего чего только можно у меня приличный, да и программатор где-то завалялся.
Первым делом добрался и снял блок управления Airbag, находится он в центральной консоли под органами управления климатом или кондиционером.
Чтобы туда добраться, нужно снять пластиковую боковину справа от ног водителя, открутив один болт при помощи Torx T15, а затем открутить кронштейн, к которому крепится эта пластиковая боковина, при помощи головки на 10. Пластиковый кронштейн крепится на шпильках и притянут пластиковыми гайками на 10.
Далее видим сам блок управления подушками безопасности, он крепится тремя гайками на 10, одна гайка со стороны водителя, две — со стороны пассажира. Ко всем гайкам можно добраться из-под ног водителя, к одной прямо, к двум остальным — на ощупь.
После того, как гайки откручены, можно вынимать блок SRS Airbag и отключать его от косы-разъема. Вот, как это выглядит вкратце.
Далее я принёс блок домой к компу и столкнулся со сложностью, которая заключалась в нестандартных винтах, которые имеют пятигранную форму внутри и по центру имеют штырёчек, который мешает туда что-либо вставить, чтобы зацепиться за вырезы в головке.
Плоской отвёрткой я отломал центральные штырьки, наклонив их сперва в одну сторону, затем в другую. Обламываются они под корень, очень аккуратно, затем плоской отвёрткой побольше зацепился за выступы и спокойно открутил все винты. Затянуты они были прилично.
Блок разбирается на три части, одна из них печатная плата с чипом EEPROM, который нужно расчехлить.
На плате нужно найти чип, который нам нужно прошить нормальным дампом. В моём случае это чип с маркировкой ATMEL 25640AN.
Работа с параметрами в EEPROM, как не износить память
Доброго времени суток. Прошлая моя статья про параметры в EEPROM была, мягко говоря, немного недопонята. Видимо, я как-то криво описал цель и задачу которая решалась. Постараюсь в этот раз исправиться, описать более подробно суть решаемой проблемы и в этот раз расширим границы задачи.
А именно поговорим о том, как хранить параметры, которые необходимо писать в EEPROM постоянно.
Многим может показаться, что это очень специфическая проблема, но на самом деле множество устройств именно этим и занимаются — постоянно пишут в EEPROM. Счетчик воды, тепловычислитель, одометр, всяческие журналы действий пользователя и журналы, хранящие историю измерений, да просто любое устройство, которое хранит время своей работы.
Особенность таких параметров заключается в том, что их нельзя писать просто так в одно и то же место EEPROM, вы просто израсходуете все циклы записи EEPROM. Например, если, необходимо писать время работы один раз в 1 минуту, то нетрудно посчитать, что с EEPROM в 1 000 000 циклов записей, вы загубите его меньше чем за 2 года. А что такое 2 года, если обычное измерительное устройство имеет время поверки 3 и даже 5 лет.
Кроме того, не все EEPROM имеют 1 000 000 циклов записей, многие дешевые EEPROM все еще производятся по старым технологиям с количеством записей 100 000. А если учесть, что 1 000 000 циклов указывается только при идеальных условиях, а скажем при высоких температурах это число может снизиться вдвое, то ваша EEPROM способно оказаться самым ненадежным элементом уже в первый год работы устройства.
Поэтому давайте попробуем решить эту проблему, и сделать так, чтобы обращение к параметрам было столь же простым как в прошлой статье, но при этом EEPROM хватало бы на 30 лет, ну или на 100 (чисто теоретически).
Итак, в прошлой статье, я с трудом показал, как сделать, так, чтобы с параметрами в EEPROM можно было работать интуитивно понятно, не задумываясь, где они лежат и как осуществляется доступ к ним
Для начала проясню, для чего вообще нужно обращаться по отдельности к каждому параметру, этот момент был упущен в прошлой статье. Спасибо товарищам @Andy_Big и @HiSER за замечания.
Все очень просто, существует огромный пласт измерительных устройств, которые используют полевые протоколы такие как HART, FF или PF, где пользовательские команды очень атомарные. Например, в HART протоколе есть отдельные команды — запись единиц изменения, запись верхнего диапазона, запись времени демпфирования, калибровка нуля, запись адрес опроса и т.д. Каждая такая команда должна записать один параметр, при этом успеть подготовить ответ и ответить. Таких параметров может быть до 500 — 600, а в небольших устройствах их около 200.
Если использовать способ, который предложил пользователь @HiSER- это будет означать, что для перезаписи одного параметра размером в 1 byte, я должен буду переписать всю EEPROM. А если алгоритм контроля целостности подразумевает хранение копии параметров, то для 200 параметров со средней длиной в 4 байта, мне нужно будет переписать 1600 байт EEPROM, а если параметров 500, то и все 4000.
Малопотребляющие устройства или устройства, питающиеся от от токовой петли 4-20мА должны потреблять, ну скажем 3 мА, и при этом они должны иметь еще достаточно энергии для питания модема полевого интерфейса, графического индикатора, да еще и BLE в придачу. Запись в EEPROM очень энергозатратная операция. В таких устройствах писать нужно мало и быстро, чтобы средний ток потребления был не высоким.
Очевидно, что необходимо, сделать так, чтобы микроконтроллер ел как можно меньше. Самый простой способ, это уменьшить частоту тактирования, скажем до 500 КГц, или 1 Мгц (Сразу оговорюсь, в надежных применениях использование режима низкого потребления запрещено, поэтому микроконтроллер все время должен работать на одной частоте). На такой частоте, простая передача 4000 байт по SPI займет около 70 мс, прибавим к этому задержку на сохранение данных в страницу (в среднем 7мс на страницу), обратное вычитывание, и вообще обработку запроса микроконтроллером и получим около 3 секунд, на то, чтобы записать один параметр.
Поэтому в таких устройствах лучше чтобы доступ к каждому параметру был отдельным, и обращение к ним должно быть индивидуальным. Их можно группировать в структуру по смыслу, или командам пользователя, но лучше, чтобы все они не занимали больше одной страницы, а их адреса были выравнены по границам страницы.
Но вернемся к нашей основной проблеме — мы хотим постоянно писать параметры.
Как работать с EEPROM, чтобы не износить её
Те кто в курсе, можете пропустить этот раздел. Для остальных краткое, чисто мое дилетантское пояснение.
Как я уже сказал, число записей в EEPROM ограничено. Это число варьируется, и может быть 100 000, а может и 1 000 000. Так как же быть, если я хочу записать параметр 10 000 000 раз? И здесь мы должны понять, как внутри EEPROM устроен доступ к ячейкам памяти.
Итак, в общем случае вся EEPROM разделена на страницы. Страницы изолированы друг от друга. Страницы могут быть разного размера, для небольших EEPROM это, скажем, 16, 32 или 64 байта. Каждый раз когда вы записываете данные по какому-то адресу, EEPROM копирует все содержимое страницы, в которой находятся эти данные, во внутренний буфер. Затем меняет данные, которые вы передали в этом буфере и записывает весь буфер обратно. Т.е. по факту, если вы поменяли 1 байт в странице, вы переписываете всю страницу. Но из-за того, что страницы изолированы друг от друга остальные страницы не трогаются.
Таким образом, если вы записали 1 000 000 раз в одну страницу, вы можете перейти на другую страницу и записать туда еще 1 000 000 раз, потом в другую и так далее. Т.е. весь алгоритм сводится к тому, чтобы писать параметр не в одну страницу, а каждый раз сдвигаться в следующую страницу. Можно закольцевать эти действия и после 10 раз, снова писать в исходную страницу. Таким образом, вы просто отводите под параметр 10 страниц, вместо 1.
Да придется пожертвовать память, но как сделать по другому, я пока не знаю. Если есть какие мысли — пишите в комментариях.
Анализ требований и дизайн
Итак, мы почти поняли что хотим. Но давайте немного формализуем это. Для начала, назовем наши параметры, которые нужно писать постоянно — AntiWearNvData (антиизносные данные). Мы хотим, чтобы обращение к ним было такое же простое и юзер френдли, как и к кешируемым параметрам из предыдущей статьи.
Все требования можно сформулировать следующим образом:
Пользователь должен задать параметры EEPROM и время обновления параметра
На этапе компиляции нужно посчитать количество необходимых страниц (записей), чтобы уложиться в необходимое время работы EEPROM. Для этого нужно знать:
Количество циклов перезаписи
Время обновления параметра
Время жизни устройства
Хотя конечно, можно было дать возможность пользователю самому задавать количество записей, но что-то я хочу, чтобы все считалось само на этапе компиляции.
Каждая наша переменная(параметр) должна иметь уникальный начальный адрес в EEPROM
Мы не хотим сами руками задавать адрес, он должен высчитываться на этапе компиляции
При каждой следующей записи, адрес параметра должен изменяться, так, чтобы данные не писались по одному и тому же адресу
Это также должно делаться автоматически, но уже в runtime, никаких дополнительных действий в пользовательском коде мы делать не хотим.
Мы не хотим постоянно лазить в EEPROM, когда пользователь хочет прочитать параметр
Обычно EEPROM подключается через I2C и SPI, передача данных по этим интерфейсам тоже отнимает время, поэтому лучше кэшировать параметры в ОЗУ, и возвращать сразу копию из кеша.
При инициализации мы должны найти самую последнюю запись, её считать и закешировать.
За целостность должен отвечать драйвер.
За алгоритм проверки целостности отвечает драйвер, если при чтении он обнаружил несоответствие он должен вернуть ошибку. В нашем случае, пусть в качестве алгоритма целостности будет простое хранение копии параметра. Сам драйвер описывать не буду, но приведу пример кода.
Ну кажется это все наши хотелки. Как и в прошлой статье давайте прикинем дизайн класса, который будет описывать такой параметр и удовлетворять нашим требованиям:
Класс AntiWearNvData будет похож на, CachedNvData из прошлой статьи, но с небольшими изменениям. При каждой записи в EEPROM, нам нужно постоянно сдвигать адрес записи, поэтому необходимо хранить индекс, который будет указывать на номер текущей записи. Этот индекс должен записываться в EEPROM вместе с параметром, чтобы после инициализации можно было найти запись с самым большим индексом — эта запись и будет самой актуальной. Индекс можно сделать uint32_t точно хватит на 30 лет — даже при 100 000 циклах записи.
И вот наш класс:
Посмотрим на то, как реализуются наши требования таким дизайном.
Пользователь должен задать параметры EEPROM и время обновления параметр
В отличии от CachedNvData Из предыдущей статьи здесь появился параметр updateTime . На основе этого параметра можно посчитать сколько записей необходимо для того, чтобы уложиться в ожидаемое время жизни EEPROM. Сами параметры EEPROM можно задать в отдельном заголовочнике. Например, так:
Вообще можно было бы обойтись и без updateTime . И для каждого параметра задавать необходимое количество самим. Но я решил, все переложить на компилятор, потому что самому считать лень. В итоге сам расчет необходимого количества записей, с учетом, что все они выравнены по границам страницы, будет примерно таким:
При каждой следующей записи, адрес параметра должен изменяться, так, чтобы данные не писались по одному и тому же адресу
Еще одной особенностью нашего противоизносного параметра является тот факт, что кроме самого значения, мы должны хранить еще и его индекс. Индекс нужен нам для двух вещей:
По нему мы будет рассчитывать следующий адрес записи
Для того, чтобы после выключения/включения датчика найти последнюю запись, считать её и проинициализировать значением по адресу этой записи кеширумое значение в ОЗУ.
Для этого заведена специальная структура tAntiWear . Её то мы и будем сохранять при вызове метода Set(. ) , который, кроме непосредственно записи, еще сдвигает индекс текущей записи на 1.
Давайте посмотрим как реализован метод расчета текущего адреса записи:
Мы не хотим постоянно лазить в EEPROM, когда пользователь хочет прочитать параметр
Метод Get() — крайне простой, он просто возвращает копию из ОЗУ
Теперь самое интересное, чтобы проинициализировать копию в ОЗУ правильным значением, необходимо при запуске устройства считать все записи нашего параметра и найти запись с самым большим индексом. Наверняка есть еще разные методы хранения данных, например, связанный список, но использование индекса, показалось мне ну прямо очень простым.
В общем-то и все класс готов, полный код класса:
Полный код класса
По аналогии с CachedNvData из прошлой статьи, все параметры должны быть зарегистрированы в едином списке, причем, в этом списке мы можем регистрировать как и CachedNvData , так и наши AntiWearNvData параметры.
Я немного переделал список, так как IAR компилятор все еще не понимает много фишек из С++17, и собственно теперь список принимает только типы, а не ссылки на параметры. Кроме того, теперь у него появились методы SetToDefault и Init . Первый нужен, например, чтобы сбросить все параметры в их начальное значение. А второй, чтобы проинициализировать кешируемые в ОЗУ копии.
Также в CachedNvData я добавил параметр recordSize и recordCounts = 1 . Чтобы расчет адреса параметра был унифицирован для разного типа параметров.
Результат
Собственно все, теперь мы можем регистрировать в списке любые параметры:
Замечу, что пользователю параметров нужно только объявить параметр и список, а вся портянка с кодом, до этого, пишется один раз. Используются параметры точно также как и CachedNvData .
Что произойдет в этом примере, когда мы будем писать 10,11,12. 15 в наш параметр. Каждый раз при записи, адрес параметра будет смещаться на размер параметра + размер индекса + размер копии параметра и индекса. Как только количество записей превысит максимальное количество, параметр начнет писаться с начального адреса.
На картинке снизу как раз видно, что число 15 с индексом 5 записалось с начального адреса, а 10 теперь нет вообще.
В данном случае после сброса питания, при инициализации, будет найдена запись с индексом 5 и значением 15 и это значение и индекс будут записаны в кэшируемую копию нашего параметра.
Вот и все, надеюсь в этой статье цель получилось пояснить более детально, спасибо за то, что прочитали до конца.
Прочесть память. Как крадут прошивку устройств и как от этого защищаются
Статья написана по мотивам доклада Демида Узенькова — специалиста компании ИНФОРИОН. Выступление состоялось на конференции RuCTFE 2020. За помощь в подготовке публикации редакция благодарит команду «Хакердом».
Как ты помнишь, у ламповых приемников не было никаких прошивок, а единственное, что могло помешать твоему любопытству, — это анодное напряжение, которое, впрочем, хотя бы не нападало на тебя само. Сейчас же все по‑другому: мне попадались устройства, которые агрессивно противодействовали мне с самого начала, еще на этапе разборки корпуса. С него мы и начнем.
Вскрытие
Первое, что тебя может ждать на пути к заветной памяти с прошивкой, — это хорошо закрытый корпус. Вроде бы никаких проблем: взял крестовую отвертку… Постой, а точно ли крестовую? Сейчас существует минимум пара десятков форм головок винтов, и, конечно, далеко не все они откручиваются нормальными человеческими инструментами. Для разборки одного устройства, например, мне пришлось надфилем выпиливать из плоской отвертки нужную форму.
О трудностях с винтами можно почитать в статье на Egear.
Допустим, ты подобрал (или сделал) отвертку нужной формы. Молодец! Открутил винты, поднял крышку, послышался треск текстолита — и устройство можно отправлять на помойку. Все потому, что плата в твоем гаджете не просто болтается внутри корпуса, а сложным образом объединена с разными его частями. Обычно это делается с помощью специальных защелок, которые вставляются в отверстия платы, а при разборке корпуса ломают ее, делая дальнейшее изучение бесполезным.
Или треск не послышался. Тогда ты подключаешься к тому, что обнаружил, читаешь память, а читаются одни нули. Как такое могло произойти? Современные технологии позволяют производить крохотные SMD-фотоэлементы, вроде фототранзисторов, которые обычно применяются в такой защите. Когда устройство обнаруживает, что на его плату попадает хоть немного света (даже через маленькое отверстие в корпусе), прошивка контроллера стирается, а тебе остается нефункциональное устройство. И хорошо, если защита не спалит чего‑нибудь физически!
В некоторые устройства, например блоки питания компьютеров, производители встраивают сигнальную дымовую шашку, которая сообщает о поломке. При ее срабатывании ароматный синий дым отправит тебя в магазин за новым блоком питания.
Дело в том, что непривычный к подобным фокусам взор не может сразу отличить фототранзистор от того же светодиода, да и привычный тоже вряд ли с ходу справится. Если вообще заметит.
Осмотр платы
Если вскрытие не показало, что пациент умер от вскрытия, я сначала осматриваю плату в поисках пинов отладочных интерфейсов — обычно это JTAG или UART. Главная проблема не в том, что нужные контакты могут быть в очень неожиданных местах, а в том, что обычно они отключены. Конечно, даже в 2021 году все еще хватает уникумов, которые отправляют в прод устройства с включенным UART, но количество таковых стремительно падает.
Если тебе не повезло — вариантов немного: или плакать в подушку, или искать чип памяти на борту и читать его непосредственно.
И вот с этим тебя ожидает уйма интересного! Думал, нужно просто вытащить восьминогую микруху в DIP-корпусе, похожую на старый чип с BIOS? Как бы не так! Сейчас есть минимум четыре относительно широко применяемых вида памяти, и некоторые из них могут быть похожи друг на друга так, что не различишь.
Память
Прежде чем я расскажу, что и как делать с памятью, давай сначала разберемся, какая она вообще бывает и как ее отличить от других компонентов на плате.
По опыту процессор (на скриншоте выше по центру) обычно квадратной формы и исполняется в BGA, а память прямоугольная и делается в SOP-корпусах.
Часто в ультрапортативных вычислительно мощных устройствах (смартфонах, например) используется бутерброд из процессора и памяти — так меньше размеры и задержки при работе. Форм‑фактор, конечно, BGA — просто потому, что ничего другого в крохотный корпус запихнуть нельзя.
ROM — постоянную память — отличить довольно легко. Предположим, чип с ней ты уже нашел. Теперь давай разберемся, какая она бывает.
Нас интересует EEPROM (Electrically Erasable Programmable Read-Only Memory), FRAM (сегнетоэлектрическая память) и NOR/NAND flash — они тебе уже и так знакомы. Из них ты мог не слышать только о FRAM — ее начали применять около пяти лет назад, так что она еще не особо популярна.
EEPROM
Среди особенностей этой памяти — побайтовые чтение и запись. Такая память самая долговечная: по расчетам, она может сохранять информацию в течение примерно двухсот лет! Но за надежность приходится платить — главным образом объемом, с которым у этого вида памяти все плохо: типичный объем такого чипа измеряется в килобайтах. Из‑за низкого объема для хранения прошивок этот тип памяти почти не применяется. Ну а раз заговорили о минусах — стоит и о низкой скорости сказать.
Устройство ячейки памяти EEPROM
Ресурс ячейки — около миллиона циклов перезаписи. По сравнению с современными ячейками NAND, у которых этот показатель находится в пределах нескольких десятков тысяч циклов, EEPROM-память просто нереально надежная.
Продолжение доступно только участникам
Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее