Рассматриваемый материал является результатом кропотливой работы по анализу протокола для ключей RW1990, проведённой Сергеем - sunstudent@yandex.ru - автором данного исследования. С его личного разрешения на страницах нашего сайта и публикуется эта статья.
Аппаратное обеспечение проекта. Чтобы не возникало вопросов относительно точности результатов, расскажу об аппаратной обеспеченности проекта:
1. Логический анализатор. Устройство собрано на макетной плате, его принципиальная схема показана на рис. 1. В качестве центрального звена в нем взят микроконтроллер фирмы Microchip PIC16F88. Исследуемый сигнал подается на 1-ый контакт микроконтроллера. Для передачи сигнала на компьютер используется аппаратный USART, настроенный на работу со скоростью 115,2 кбит/сек. Согласование уровней TTL с уровнями RS232 компьютера выполнено на микросхеме MAX232. В качестве программного обеспечения можно использовать любую программу типа гипер-терминала. Чтобы устройство начало работать необходимо, послать ему символ «0». Опрос канала производится не чаще 1 раза за 7 микросекунд, именно это вносит некоторую погрешность в полученные результаты (причем порой значительную). Если результат работы гипер-терминала записать в файл, то получиться временная развертка сигнала. Следует отметить, что запись каждого байта начинается с младшего значащего разряда. Исходные коды для анализатора написаны на паскале в среде программирования microPascal compiler for PIC v 8.0.0.1
Рис.1. Принципиальная схема анализатора
2. Дубликатор. Был куплен в одном из Интернет-магазинов. Чтобы не показалось, что я лоббирую, интересы каких-то сторонних лиц, рекламу поставщика делать не буду. Одно могу сказать – дубликатором доволен, свои обязанности он выполняет на все 110%. Дополнительно использую его в качестве ридера iButton.
3. Заготовки RW1990.2. Специально для тестирования и отладки своего будущего прибора мной была куплена целая партия ключей RW1990.2. (рис. 2). Стоимость каждого составляет 20 рублей. Из сорока штук ключей, присланных из далекого Российского города, пять экземпляров оказалось абсолютно нерабочих. Этот момент меня несколько огорчил, но связываться с пересылкой товара обратно продавцу не стал.
Рис. 2. Заготовка ключа RW1990
4. Устройство для работы по протоколу 1-wire. Здесь пришлось поступить, так же как и с логическим анализатором. Буквально на коленке, мной был собран прибор на базе всё того же PIC16F88 (рис. 3). Информацию, считанную по протоколу 1-wire, устройство по протоколу RS232 посылало в компьютер. Для корректной работы с прибором, необходимо настроить скорость передачи по COM-порту равной 115,2 кбит/сек и запустить любую программу, прослушивающую COM-порт (самым наглядным примером такого ПО может являться Hyper Terminal).
Рис. 3. Принципиальная схема устройства для работы по 1-wire
Каждое удачное считывание сопровождается подмигиванием светодиодом HL1 и отправкой считанной информации на компьютер. Информация посылается как текстовая строка, представленная в шестнадцатеричной системе. В программе реализован алгоритм проверки правильности считанной информации – CRC.
5. Дополнительные принадлежности. Фирменный ключ DS1990A-F5, который был куплен исключительно для того, чтобы изъять у него контактную площадку. Для этого пришлось попотеть. Верхняя часть ключа была рассверлена и с помощью плоскогубцев аккуратно отогнута. К контактным поверхностям с помощью кислоты и паяльника были подведены 2 провода (рис. 4).
Рис. 4. Контактная площадка ключа DS1990A-F5
Держатель iButton для монтажа на поверхности DS9094FS. Чтобы было удобнее пользоваться разработанным снифером протокола, эта деталька просто необходима (рис. 5)
Рис. 5. Держатель iButton
Первые шаги по исследованию протокола. Исследование протокола решено было начать с самого простого. Немного переделав прошивку устройства для работы по протоколу 1-wire, описанного в предыдущей теме под пунктом 4, я начал последовательно посылать ключу RW1990 команды от 00h до FFh. После каждой такой посылки, устройство ожидало, какого либо ответа от ключа. Всего было найдено 3 команды, 2 из которых специфицированы в документации на DS1990A фирмы Maxim:
1) 33h – основная команда, которая используется для чтения ПЗУ. В ответ на неё ключ возвращает 8 байт (1 байт – код семейства, 6 байт – уникальный серийный номер, 1 байт – байт контроля четности CRC). Более подробно описание команды можно изучить в документации производителя, в пределах данной статьи не вижу в этом необходимости.
2) F0h – тоже специфицированная команда, которая называется поиск ПЗУ (Search ROM). Она предназначена для определения количества одновременно подключенных к шине Slave-устройств. Тут хочется отметить, что поддержка этой команды не реализована в ряде устройств, среди таковых попадаются некоторые модификации ключа DS1990.
3) C4h – команда не специфицирована. В ответ на неё RW1990 отвечает одним байтом FEh. Пока однозначно сказать, для чего предназначена данная команда, не могу. Командой записи быть не может, ибо тогда всё получается очень просто. Я думаю, что FEh – идентификатор ключа, поэтому если кто может сказать, для чего нужна команда C4h, пусть не молчит, а напишет мне. Вместе мы сможем воссоздать полную картину и написать подробный Datasheet RW1990.
Теперь подойдем к этому проекту с другой стороны, со стороны дубликатора. Снимем характеристику прибора, так сказать, на «холостом» ходу. Такой маневр позволит нам в будущем выделять из временных диаграмм записи ключей стандартные элементы, каковыми являются сброс и т.п. Согласно технической документации на протокол, мастер-устройство (в нашем случае – дубликатор) должно генерировать чередующиеся импульсы лог. «1» и лог «0» с продолжительностью более 480 микросекунд (для стандартной скорости). Длительный импульс логического нуля говорит о том, что мастер-устройство посылает сигнал сброса.
Рис. 6. Временная диаграмма работы дубликатора на "холостом ходу"
Обращаю Ваше внимание на то, что на рисунке показаны усредненные значения временных интервалов. Самый длительный провал напряжения составляет 6.3 мсек – этого вполне достаточно, чтобы полностью разрядить конденсатор внутри таблетки. Впрочем, для этих целей хватит и 385 микросекунд, которые мы также можем наблюдать на диаграмме. Непонятным остается тот момент, для чего дубликатором дополнительно генерируется сигнал логической единицы продолжительностью порядка 100 микросекунд. Итак, когда мы с Вами будем анализировать протокол записи, то удержание мастером линии более 385 микросекунд будем однозначно считать сбросом.
Анализ протокола записи RW1990.2. Теперь разберемся с протоколом записи ключей типа RW1990.2. Лог записи номера F9000009E5544C01 на болванку можно взять здесь. Запись последнего произведена с помощью логического анализатора, описанного выше. В архиве содержится 2 файла. Файл 2.txt является двоичным логом записи, причем первым в каждом байте записан младший значащий разряд. Файл 2.doc представляет собой переработанный в табличную форму файл 2.txt. Таблица состоит из 4-х колонок:
Колонка «№ п/п» - номер по порядку, колонка «Лог. сост» - логическое состояние (соответственно может быть только "0" и "1"), колонка «Кол-во» - число измерений (выборок), приходящееся на соответствующее логическое состояние и колонка «Время, мкс» - время в микросекундах, в течение которого было соответствующее логическое состояние.
Итак, весь процесс записи ключа дубликатором можно разбить на несколько этапов:
1) Проверка первоначально записанного кода;
2) Если записанный код не совпадает с записываемым, то дубликатор посылает ряд команд (если быть точным, то 2);
3) Сверка записанного кода.
Весь процесс занимает 2-3 секунды.Теперь разберем каждый этап более подробно
Проверка первоначально записанного кода. Данный этап полностью специфицирован в документации на DS1990, представленной на сайте производителя - компании Maxim IC. Коротко коснемся основных моментов.
Дубликатор посылает ключу команду(33h) на чтение ПЗУ. В ответ на что, RW1990.2 отсылает 64 битный "уникальный" код. Давайте обратимся к логу записи: дубликатор целых 3 раза посылает команду на чтение ПЗУ (см. позиции лога записи с 75 по 87, с 220 по 234 и с 359 по 374). Видимо два предыдущих варианта окончились неудачно, т.е. в считывающем устройстве не сошлась контрольная сумма, пересылаемая ключом в последнем байте, и ему пришлось повторно отправить команду на чтение.
Посылка управляющих команд. Как видно из лога, при подготовке к записи дубликатор длительно удерживает импульс логической единицы (см. 502 позицию), затем "играет" уровнями (с точки зрения описания протокола 1-Wire это по другому назвать нельзя). Такой процесс идет вплоть до 518-ой позиции, при этом хочется отметить, что в этом "беспорядке" можно неоднократно проследить импульсы логического нуля, которые по длительности соответствуют, в некоторых случаях даже превышают, импульс сброса (рис. 7).
Рис. 7. Подготовка к передаче первой команды.
Передача команды начинается с позиции 519. Давайте обратимся к графику (рис. 8, 9), на котором я прорисовал всю последовательность инициализации.
Рис. 8. Передача первого байта
Рис. 9. Второй байт данных.
Как ни странно в первом пакете можно обнаружить всего 15 бит информации. Скорее всего один бит просто "слился" с предыдущим в виду схемотехнических особенностей моего логического анализатора. На графике этот момент отмечен красным. Свои попытки поймать 16 бит я делал неоднократно, но увы за 3 испытания мне ничего уловить так и не удалось. Вот только результат с каждой попыткой получался всё хуже и хуже. В одной из попыток у меня получилось всего 13 бит в данном пакете.
Давайте теперь определим, что именно передается/посылается за эти 16 бит. Тут возможны 2 варианта:
1. Дубликатор посылает только 8 бит и 8 бит получает в ответ от ключа.
2. Дубликатор посылает 16 бит ключу, хм... а ключ ничего не отвечает. Или ответом ключа является последующая последовательность бит, которую я ошибочно принял за вторую команду.
На сегодняшний день будут прорабатываться 2 рабочие версии. Итак, на рис. 8 мы видим пересылку команды 1Eh по протоколу 1-Wire, а на рис. 9, скорее всего, ответ ключа RW1990.2 на данный запрос (байт FFh), либо это просто – RW1990 отмолчался (смотря как к этому относиться). После первых 16 бит, дубликатор посылает сброс и передаёт вторую управляющую команду (рис. 10). Расшифровывая протокол, я столкнулся с некоторой неопределенностью, которая возникает при чтении лога (позиции 553-568). Опираясь на протокол получается, что следующий команда – 1Ch, если же взывать к логике, и проследить аналогию с последующими битами, то вроде выходит – 1Dh.
Рис. 10. Передача второй команды
Сразу после неё дубликатор передает сам "уникальный" код, который будет записан в энергонезависимую память RW1990.2. Запись происходит по следующему алгоритму: чтобы передать "1" дубликатор передает логический ноль в течение до 14 микросекунд, а затем логическую единицу в интервале времени до 13 милисекунд; для передачи "0" время логического нуля увеличено с 14 до 60 микросекунд при оставшемся неизменным по времени уровне логической единицы (рис. 11). В EEPROM таким образом передается 64 бита.
Рис. 11. Запись "уникального" номера в RW1990
Выше была рассмотрена последовательность команд, которую дубликатор посылает ключу RW1990.2 для записи в его внутреннюю память EEPROM уникального серийного номера. Однако процесс на этом не заканчивается. После этого ключик принимает ещё несколько команд, и лишь с 813 позиции лога, дубликатор посылает команду 33h для проверки того, что записалось в память RW1990.2
Исходя из вышесказаного, можно сделать следующие выводы:
1. В логе записи ключа RW1990.2 нас интересуют лишь позиции с 501 по 812 (включительно).
2. Несмотря на наличие лога записи, дубликатора и некоторого количества заготовок, заставить записать какую-либо информацию на ключ у меня так и не получилось.
1. Запись ключа 01563412FF000F96 на заготовку с ключом 01AB896745230179
2. Запись ключа 01AB896745230179 на заготовку с ключом 01563412FF000F96
3. Запись ключа 010000000000003D на заготовку с ключом 01563412FF000F96
В архиве, как обычно, 2 типа файлов: *.txt, *.xls. Документ Excel представляет собой переработанный в табличную форму файл с расширением *.txt
Далее основные усилия были направлены на модернизацию логического анализатора. Коллега (hexFFh) помог собрать прибор на микроконтроллере ATMEGA16 и написал прошивку для него.Основное отличие данного анализатора от предыдущего варианта заключается в том, как данные передаются на компьютер. Если первоначально я передавал состояние линии непрерывно и разрешающая способность прибора обуславливалась пропускной способностью COM порта – 115 кБит/с, то вариант hexFFh расшифровывает протокол внутри микроконтроллера и посылает готовые данные на компьютер.
Рассмотрим протокол записи двух самых распространенных болванок: RW1990.2 и RW1990 (рис. 12). До недавнего времени я думал, что две эти заготовки абсолютно идентичны по протоколу, однако этот миф также быстро развеялся. Вначале моё предположение подтвердилось в описании, размещенном на сайте http://ikey.ru, а затем и опытным путем. Новый код для RW1990 записывается инверсно. Как обычно передача начинается с family code, младшим байтом вперед, но биты в каждом байте инвертированы. Больше отличий в протоколах нет, поэтому все последующие высказывания будут относиться к заготовке второй версии.
Рис. 12. Внешний вид болванок RW1990 и RW1990.2
Протокол передачи данных по шине 1-Wire состоит из четырех типов сигнализации на одной линии: последовательность сброса с импульсом сброса и импульсом присутствия, запись нуля, запись единицы и чтение данных. За исключением импульса присутствия, все эти сигналы инициируются мастером.
Последовательность записи в EEPROM RW1990.2 через 1-Wire порт следующая:
1) Чтение ПЗУ;
2) Инициализация записи;
3) Запись кода в EEPROM;
4) Проверка записанного кода;
5) Ожидание момента, когда ключ уберется с лузы дубликатора.
Все транзакции на шине 1-Wire начинаются с последовательности инициализации. Последовательность инициализации, как правило, состоит из импульса сброса, передаваемого мастером шины, за которым следует импульс присутствия, передаваемые ведомым, в нашем случае таковым является ключик-заготовка. Длительность стандартных импульсов можно посмотреть в документации, например, на DS1990, которая любезно выложена на сайте Maxim.
Импульс присутствия сообщает мастеру шины, что RW1990.2 подключен к шине и готов к работе.
Для того, чтобы запись заготовки происходила достаточно уверенно, а записанные данные не носили случайный характер, необходимо обеспечить ток порядка 1 мА. У меня RW1990.2 стабильно записывается при номинале подтягивающего резистора 200 Ом (вход подтянут относительно положительного потенциала напряжения питания +5 В). Запись происходит, как уже писалось выше, в несколько этапов. Подробно разберем каждый из них.
1. Чтение ПЗУ. Перед тем как записать заготовку дубликатор трижды считывает уникальный код, находящийся в ПЗУ RW1990.2. Как известно из технической документации для этого предназначена команда 0x33, перед которой следует чередование сигналов Reset и Presence. Для того, чтобы упростить чтение лога введем следующие сокращения: R – Reset, P – Presence. Также не забываем, что чтение и запись информации идёт начиная с младшего бита, а инициирует передачу/прием всегда только мастер.
2. Инициализация записи. В таблице 2 представлена последовательность, которую дубликатор посылает перед записью ключа. Следует отметить, что перед посылкой первого пакета Reset->Presence (см. п.1 табл.2) выдерживается уровень логической единицы порядка 4 мс. Перед передачей Reset (см. п.5 и п.9 табл.2) длительность импульса логической единицы составляет 13 мс, перед Reset (п.9 табл. 2) – 16 мс. Все остальные временные промежутки согласно документации на DS1990.
3. Запись кода в EEPROM. Для того чтобы запись кода происходила корректно, необходимо после передачи каждого бита выдержать импульс логической единицы более 10 мс. Здесь действует правило – лучше передержать, чем недодержать. Импульсу Reset (позиция 8 в табл. 3) предшествует импульс логической единицы длительностью 13 мс
Рис. 13. Передача "уникального номера" в RW1990.2
4. Проверка записанного кода. Данный этап происходит аналогично пункту 1.
5. Ожидание момента, когда ключ уберется с лузы дубликатора. До тех пор, пока Вы не уберете ключ с лузы дубликатора идет чередование Reset -> Presense.
На этом наш обзор протокола RW1990 завершён. Если у Вас есть вопросы, обращайтесь к автору данного материала на адрес sunstudent@yandex.ru
Авторские права на публикацию принадлежат: http://sunstudent.narod.ru
