Bus Blaster — универсальный скоростной bit-bang интерфейс для терпеливых энтузиастов

в 17:23, , рубрики: avr, bit-bang, bus blaster, cpld, diy или сделай сам, FT2232H, ft232, ftdi, I2C, jtag, mpsse, SPI, xilinx, ПЛИС, программатор, метки:

Bus Blaster — универсальный скоростной bit-bang интерфейс для терпеливых энтузиастов - 1
Мне давно хотелось иметь какой-нибудь простой и универсальный аппаратный интерфейс с несколькими входными и выходными сигналами, функциональность которого определяется исключительно софтом, вроде достопамятного программатора PonyProg. И чтобы его можно было использовать не только как чтения/записи прошивок, но и для отладки программ через JTAG. При этом покупать что-либо промышленное, при моем нерегулярном баловстве с электроникой, избыточно и нерентабельно — требовалось что-то из серии «полуфабрикатов», на основе bit-bang.

Что такое bit bang и зачем он нужен

Кое-кто еще помнит, что в счастливые времена Windows 9x каждая системная плата и каждый ноутбук в обязательном порядке имели последовательный (COM) и параллельный (LPT) порты. В ту пору для организации интерфейса с микросхемой ППЗУ, служебными контактами мобильника или передней панели магнитолы достаточно было припаять к разъему порта несколько резисторов, диодов и транзисторов. Все остальное делали обычные пользовательские приложения, самостоятельно формировавшие сигналы нужного протокола путем выставления нулей или единиц на нужных выводах, и считывания сигналов на входах. У клятых буржуев это называлось bit-bang, а у нас — «дрыгоножество», «ногомашество» и т.п.

С переходом на 2k/XP возникли сложности с прямым доступом к портам ввода/вывода, но они успешно решались костылями вроде giveio. Гораздо сильнее портила жизнь более высокая фоновая активность в NT, из-за которой сложнее было выдержать стабильность передачи и приема.

Как известно, на современных компьютерах, тем более — ноутбуках, с аппаратными портами не густо, ибо большинству пользователей они не нужны. USB-адаптеры для подключения устройств с интерфейсами RS232 и Centronics (в просторечии — COM/LPT) хорошо работают лишь в рамках основного назначения, а делать на них «дрыгоножество» проблематично по целому ряду причин. Во-первых, большинство этих адаптеров умеет обрабатывать с хорошей скоростью только сигналы данных (те же Tx/Rx), а управляющие сигналы обрабатывает с большими задержками. Во-вторых, адаптеры различных производителей аппаратно несовместимы, а возможности нестандартного управления через драйвер производителя сильно ограничены. В-третьих, для передачи команд адаптеру почти все драйверы используют отдельные USB-пакеты, что ограничивает частоту смены состояний всего тысячей раз в секунду, чего для многих применений катастрофически мало.

К счастью, компания FTDI уже давно предлагает ряд решений для USB, ориентированных именно на скоростной обмен произвольными сигналами. Беглое изучение вопроса показало, что наиболее популярны в этом плане интерфейсы на микросхемах FT232H/FT2232H.

Простейшие решения

Поначалу FTDI реализовала в своих USB-интерфейсах FT232BM, FT232R и им подобных два дополнительных режима — асинхронный и синхронный bit-bang. Для этого добавлено восемь и более дополнительных сигнальных линий, каждая из которых может настраиваться на ввод или вывод. Буферизованные данные, передаваемые интерфейсу с компьютера, выставляются на выходных линиях по сигналам тактового генератора, входные данные считываются с линий, буферизуются и отправляются в компьютер. Привязка ввода/вывода к тактовому генератору обеспечивает хорошую точность интервалов — приложению больше не нужно заботиться об их выдерживании программным путем.

Таким образом, вместо традиционного цикла типа «установить на выходной линии активный уровень; выдержать паузу; считать состояние входной линии; установить на выходной линии пассивный уровень» приложение формирует последовательность байтов, каждый из которых задает состояние выходных линий в течение одного тактового периода. Последовательность отправляется в интерфейс, а оттуда считывается такая же последовательность, отражающая состояния входных линий. В асинхронном режиме ввод и вывод происходят независимо друг от друга. В синхронном чтение входов выполняется непосредственно перед выставлением сигналов на выходах, что позволяет надежнее работать с быстро меняющимися сигналами.

Контроллер MPSSE

В H-версии микросхем FTDI добавлен мультипротокольный синхронный последовательный контроллер (MPSSE), аппаратно реализующий различные режимы тактирования и обмена данными. Формирование сигналов нужного протокола выполняется передачей контроллеру серии его внутренних команд, задающих способы тактирования, моменты выставления/считывания сигналов (на фронте или спаде тактового импульса), порядок передачи битов (LSB/MSB). Обратно контроллер присылает последовательность «моментальных снимков» входных линий. Скорость передачи данных может достигать 30 Мбит/с.

Через MPSSE наиболее естественно реализуются протоколы JTAG, I2C и SPI, однако легко может быть реализовано почти любое «дрыгоножество» в рамках аппаратных возможностей контроллера.

FTDI предлагает обширную документацию по подключению и программированию своих интерфейсов, библиотеки и примеры программ для работы через MPSSE под Windows, Linux и MacOS, драйверы D2XX для прямого взаимодействия с интерфейсом.

Интерфейсы FTDI поддерживаются популярными программами OpenOCD, UrJTAG, flashrom, avrdude, HappyJTAG2, zJTAG и др.

Проблемы с подключением

Подробно выяснив еще в прошлом году все вышеперечисленное, я было воодушевился, но сразу же обнаружил, что FT232H/FT2232H, при всей своей универсальности, далеко не всегда могут быть подключены непосредственно к конечному устройству. Во-первых, внешние линии микросхем рассчитаны на уровень 3.3 В, а во многих современных устройствах используются уровни 2.5/1.8/1.5 В. Во-вторых, выходные линии не могут с высокой частотой переключаться в высокоимпедансное состояние и обратно — это возможно лишь при начальной настройке линий, путем выбора режима «вход» или «выход». То есть, для подключения микросхемы с MPSSE к целевому устройству необходима буферная схема, согласующая уровни сигналов и обеспечивающая оперативное отключение некоторых выходных линий (например, при пассивном уровне сигнала TMS/CS).

Погуглив на тему вариантов буферных схем, я обнаружил, что в мире наделано неимоверное количество адаптеров, отличающихся друг от друга только этим самым буфером. Некоторые программы (но не все) позволяют использовать разные типы буферов. Так что, выбирая определенную модель адаптера, одновременно ограничиваешь круг программ, которые будут с ним работать. А чтобы наперед определиться с типом, нужно было снова вдумчиво гуглить и вычитывать обсуждания на форумах, чего делать вовсе не хотелось. Некоторые адаптеры позволяли задавать конфигурацию буфера перемычками, но это чревато ошибками, да и стоят они недешево.

Bus Blaster — претензия на универсальность

Идея парней из Dangerous Prototypes была оригинальна вдвойне: первое — в качестве буфера подключить к FT2232H микросхему ПЛИС (CPLD) Xilinx XC2C32A, которую можно оперативно перепрограммировать под любую конфигурацию, а второе — использовать для ее перепрограммирования второй канал FT2232H. Кроме реализации буферной логики, ПЛИС выполняет согласование уровней — ее внешние линии работают в диапазоне 1.5-3.3 В.

В итоге получилась плата Bus Blaster. С момента появления проекта сменилось четыре версии платы. Наиболее стабильной и распространенной считается версия 3. Версия 4 содержит ПЛИС бОльшего объема, отработана не до конца и используется гораздо реже. Следующих версий, по-видимому, уже не будет, поскольку развитие проекта прекращено еще пару лет назад. У меня создалось впечатление, что плату толком мало кто распробовал — при своем высоком потенциале она не слишком проста в использовании. Для платы создан раздел форума, но с прошлого года там почти ничего не пишут.

Поразмыслив, я заказал на AliExpress версию 3c, как наиболее отработанную, за $34. Тогда их там продавал магазин от изготовителя — Seeed, а сейчас продают только дилеры от $52. Непосредственно у Seeed (вместе с пересылкой) обойдется где-то в $37.

Первые впечатления

Плата выглядит в точности так же, как на картинке — красивая, аккуратная, сделана качественно. На форуме кто-то жаловался на непропай выводов микросхем, поэтому я внимательно осмотрел свои под лупой — дефектов не нашел.

Драйверы D2XX у меня уже были установлены раньше, так что плата опозналась с ходу. Первым делом стал разбираться с программированием буферной логики в ПЛИС. Делается это с помощью программы UrJTAG, но специально подправленной под Bus Blaster для правильного доступа ко второму каналу FT2232H.

Сперва нужно скачать и установить базовую версию UrJTAG. Затем к ней нужно добавить модифицированный EXE-файл и описание ПЛИС (BSDL) из этого пакета. Для программирования встроенной ПЛИС нужно запускать модифицированный EXE, для работы со внешними устройствами — основной. Процедура программирования ПЛИС изложена здесь. Для удобства можно создать скрипты для UrJTAG под каждую версию буфера, и CMD-файлы с командными строками для их запуска.

Коллекция прошивок ПЛИС, описывающих буферы, совместимые с адаптерами JTAGkey, KT-Link и PicoTap выложена здесь, но для BBv3 там есть только один файл — под JTAGkey с поддержкой самотестирования (BBV3-JTAGkey-selftest-v1.1.svf). Большинству его достаточно, но у меня он не работал с flashrom, о чем будет сказано ниже.

Записав эту прошивку в ПЛИС, поставил в разъем перемычки для самотестирования, как описано в документации, замкнул на землю линию P28 (IO09) — на плате зажегся светодиод. Скачал и запустил программу тестирования — показала, что все в порядке.

Странно, кстати, что программа самотестирования называется «BusPiratev2Test», ибо Bus Pirate — совершенно другой проект, никак не совместимый с BB.

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

Попытки целевого применения

Скачав отсюда (сейчас там, увы, ошибка 404) flashrom v0.9.6.1-r1704/Win32, и отпаяв с какой-то дохлой системной платы микросхему MX25L8005 (SPI), попытался ее прочитать, указав в командной строке "-p ft2232_spi:type=busblaster". Однако flashrom заявил, что не находит FT2232. Чтение документации показало, что он работает только через libusb — универсальную интерфейсную библиотеку, изначально написанную под Linux, а затем портированную под Windows.

Через libusb он нашел интерфейс, но упорно утверждал, что не видит микросхемы. Нашел в коробке с плодами некрофилии какую-то другую SPI-микросхему — тоже не видит. Потыкал осциллографом — TMS шевелится, TCK есть, TDO идет, а на TDI — тишина. Вообще, ни единого всплеска. Подключил каналы осциллографа одновременно к TCK и TDO — сигналы меняются синхронно, четко. Идей о том, что можно проверить еще, в тот момент не возникло.

Временно бросив эксперименты с flashrom, подключил к интерфейсу ATTiny13. Скачав отсюда несколько разных версий avrdude, с версией 5.11-Patch7610/Win32 и типом программатора 2232HIO, наконец-то получил четкое опознание, чтение и запись контроллера. Обрадовавшись, подключил обратно SPI-микросхемы, но flashrom упорно отказывался их опознавать.

Заподозрив, что обе микросхемы мертвы, достал USBASP 2.0, перешитый под AsProg — он без проблем (хоть и очень медленно) прочитал обе. Кстати, три штуки USBASP я покупал вообще на роль удобных макетных плат на ATMega8, но устройство оказалось неожиданно многофункциональным.

Снова подключил микросхемы к BB и стал пробовать flashrom в разных режимах (Bus Blaster и JTAGKey), с разными значениями делителя (-p ft2232_spi:type=busblaster,divisor=n). Вдруг в одной из комбинаций микросхема опозналась, но читаться уже отказалась. Еще через несколько попыток пропало и опознание. Затем несколько раз удавалось получить несколько успешных опознаний подряд, но чтения добиться так и не удалось.

Написал в форум, но ничего толкового в ответ не получил. Порывшись в поиске, нашел жалобы нескольких человек на универсальную (с самотестированием) прошивку ПЛИС, нашел там еще три варианта прошивок, пробовал их в разных комбинациях с другими параметрами, но успеха не добился. Исчерпав все варианты, забросил эксперименты до прихода заказанного чуть позже BB логического анализатора.

Тестирование с анализатором

Получив клон популярного логического анализатора Saleae Logic 16, подключил его ко всем четырем линиям SPI. Программа, бесплатно доступная на сайте Saleae, умеет расшифровывать протоколы I2C, SPI и несколько других, так что она сразу показала расшифровку всех пакетов — как отправленных, так и полученных. Сразу стало видно, что пакеты «плывут» — одни и те же последовательности битов раз за разом группируются программой в пакеты на разных границах.

Сравнивая диаграммы сигналов на даташитах микросхем с записанными, в какой-то момент заметил, что сигнал TMS (подключенный к выводу CS) в начале каждого сеанса обмена уходит в низкий (активный уровень), в котором и остается, хотя по протоколу должен возвращаться в высокий (пассивный) в конце каждой операции. Сменил «официальную» прошивку ПЛИС на одну из альтернативных — TMS зашевелился активнее, границы пакетов выровнялись по нему, а после подбора делителя тактовой частоты в командной строке flashrom (остановился на 8) микросхема, наконец, стала четко отвечать на каждый запрос, прочиталась и перезаписалась.

Удивляясь, как я сразу не уделил должного внимания поведению TMS, сообразил, что меня сбила с толку успешная работа с AVR на этой же прошивке ПЛИС. Глянув в даташит на ATTiny13, обнаружил, что сигнал RESET, на который заводится TMS, может быть низким в течение всего времени обмена, его подъем для синхронизации не требуется. А SPI-микросхемам его подъем для синхронизации необходим.

По итогам тестирования, свел информацию о трех известных прошивках ПЛИС в одном форумном посте.

Предельное количество циклов перезаписи ПЛИС

В одном из обсуждений наткнулся на предостережение о том, что гарантированное количество циклов перезаписи прошивки этой ПЛИС всего около тысячи. Поначалу расстроился, поскольку в ходе экспериментов успел поменять прошивку около сотни раз, и уже представлял себе скорую гибель микросхемы. Она стоит-то всего ничего, но возиться с перепайкой совершенно не хочется. Потом сообразил, что при адекватном подходе оставшихся девяти сотен циклов хватит еще на много лет.

Внутрисхемная перепрошивка ППЗУ в маршрутизаторе

Через некоторое время у меня образовался свежеокирпиченный мини-маршрутизатор на RT5350F под условным наименованием «ZLMNet H-G5 / P8201» (обозначения взяты из web-интерфейса). Примерно в то же время прибыла и клипса для SOIC8/SOP8 — решил попробовать внутрисхемную работу с ППЗУ.

Сначала flashrom вообще не видел ППЗУ через BB. Осциллограф показал, что в борьбе между ПЛИС и процессором маршрутизатора за уровни сигналов CS и CLK неизменно побеждал процессор. Что неудивительно — в BB между выводами ПЛИС и разъемом стоят токоограничительные резисторы, спасающие слаботочные ключи ПЛИС от выгорания.

Подключил USBASP с AsProg — этот читает/пишет нормально, но опять-таки чертовски медленно (9 минут на чтение, 25 — на цикл стирания-записи-проверки). Для однократного оживления кирпича оно еще допустимо, но для экспериментов с нестабильными прошивками — уже нет. Тем более, что AsProg не умеет работать с отдельными страницами — только с микросхемой целиком.

Впаял между выходами TMS/TCK в BB и входами CS/CLK ППЗУ по эмиттерному повторителю — сигналы сразу привелись к почти правильным уровням, flashrom микросхему опознал, начал уверенно читать/писать. При делителе 8, полное чтение занимает меньше минуты, перезапись — около двух минут.

Оказалось, что общение программатора с ППЗУ совершенно не мешает работе процессора — маршрутизатор при этом работает совершенно исправно. Очевидно, линии CS/CLK выделены только для ППЗУ, которое однократно считывается при загрузке, после чего процессор к нему не обращается, если не затеять перепрошивку штатными средствами.

Недостатки программ, работающих с BB

Опробованные программы (zJTAG, flashrom, avrdude, UrJtag, OpenOCD), умеющие работать с MPSSE, произвели весьма грустное впечатление. Во-первых, в большинстве этих программ, при всем разнообразии адаптеров на FTDI, не предусмотрено явного указания VID/PID — идентификаторы известных адаптеров жестко зашиты в код. Но у JTAGkey, который эмулирует BB, PID установлен в CFF8, а у «чистой» FT2232H — в 6010. Конечно, можно сменить идентификаторы в BB утилитой FT_Prog, или пропатчить таблицу в программе, но оба варианта одинаково кривы. Хорошо, удалось найти версию flashrom с поддержкой BB, скомпилированную под Windows (иначе пришлось бы ставить CygWin), а avrdude нормально работает при указании типа программатора 2232HIO.

Во-вторых, часть программ работает с адаптером только через библиотеку libusb, которая, в свою очередь, работает через собственный драйвер, несовместимый с драйверами FTDI. Хорошо хоть, что в Windows для переключения между драйверами не нужно полностью удалять один и устанавливать другой — достаточно лишь «обновить», принудительно выбрав нужный драйвер для заданного устройства (канал A или B).

Выводы

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

Надо бы попробовать OpenOCD и JTAG на каком-нибудь из имеющихся маршрутизаторов, но все не доходят руки.

А еще у Dangerous Prototypes есть более старый проект Bus Pirate. Там плата на PIC и простом интерфейсном FT232BL в традиционном режиме serial. Для общения с контроллером используется обычный терминал и текстовые команды, ответы так же выводятся в текстовом виде. avrdude, flashrom и ряд других программ умеют работать и через BP, однако, по понятным причинам, скорость работы получается в несколько раз ниже. Малая скорость компенсируется широтой применения — есть множество вариантов применения BP для эмуляции различных протоколов.

Подумав, что в этой жизни надо испробовать все, заказал BP v3.6 с кабелем. Да-да, я помню и про мышей на кактусе, и про «завтра снова туда пойду». :)

Автор: emusic

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js