Предисловие

В предыдущей статье был рассмотрен механизм защиты от клонирования адаптеров программатора XELTEK SuperPro 6100.

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

Предыстория

В очередной раз у нас появилась задача, которая на первый взгляд решалась довольно просто — понадобилось сделать копию одной специализированной микросхемы флэш-памяти — mDOC H3 SDED5-512M.

Данная микросхема была разработана более десяти лет назад. Вот pdf (1) с ее описанием. Ниже приведена небольшая выдержка из русскоязычного анонса:

… компания msystems подготовила семейство mDOC, пригодное для использования в качестве «твердотельных дисков»…
Встроенное программное обеспечение TrueFFS, на которое возложены задачи управления флэш-памятью mDOC H3, выполняет собственный контроллер модуля, что превращает ее в завершенный, автономный блок, легко добавляемый к разнообразным карманным устройствам.…

В списке поддерживаемых программатором SuperPro 6100 такая микросхема значилась и для нее даже нашелся соответствующий адаптер DX5057. Но после сборки всего конструктора и выбора данной микросхемы в программе отобразилась следующая картина с загадочным пунктом «DimageMain», описания которого не нашлось ни в документации, ни на сайте разработчика.


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


Судя по надписи «mDOC H3 Write Image», «Image» — это образ, который можно записать в микросхему с помощью данного программатора. Но как этот образ прочесть из уже записанной микросхемы, как ее стереть и т.п.?

Чуть позже в интернете нашелся файл (2) от компании «Dataman», в котором частично приводится структура вышеуказанного образа и упоминается софт для его создания.
Таким образом, дальнейшие усилия были направлены на поиски утилит от «M-Systems», описанных в документе «Software Utilities for TrueFFS 7.1» (3).

Запрос в техподдержку бывшей «M-Systems», ныне «SanDisk», результата не дал — ответа просто не последовало.

На просторах интернета удалось отыскать только старые утилиты, которые не поддерживают версии микросхем H3. Полный SDK от SanDisk также найти не удалось, только его «осколки» (5) в плане реализации драйвера для Linux.

По мере изучения накопленной информации, в файле от «Dataman» привлекла внимания такая строка: «Image files can be created with the SanDisk Docshell utility or PG4UW».

«SanDisk Docshell» утилиты никоим образом себя не обнаруживали, поэтому пришлось разбираться, как PG4UW (4) работает с данной микросхемой. Они не стали внедрять весь SDK от «SanDisk» в свой софт, а создали плагин с экспортируемыми методами, необходимыми для работы TrueFFS утилит, которые затем вызываются из своей программы.
Этим же путем пойдем и мы.

Создание собственного программного модуля

Здесь приводится отказ от ответственности, заключающийся в том, что автор не несёт никакой ответственности за любое использование вами материалов данной статьи.
Иными словами — только вы сами будете отвечать за свои действия, на которые вас может подвигнуть ознакомление с данным материалом.

Условимся, как и в предыдущей статье, называть программу программатора от SuperPro 6100 просто «софтом», а компьютер, на котором эта программа работает — «хостом». Теперь у нас появляется еще одна программа, работающая в самом программаторе. Будем называть ее «программным модулем».

В руководстве «Software Utilities for TrueFFS 7.1» (3) описаны функции, реализуемые утилитами DOCSHELL, которые делятся на следующие четыре категории:

• DFORMAT — утилиты для форматирования mDOC девайса.
• DINFO — утилиты для получения разнообразной информации о mDOC девайсе и существующих на нем разделах.
• DIMAGE — утилиты для чтения, записи и сравнения образа mDOC девайса.
• SPLITIMAGE — утилиты для разделения образа mDOC девайса на части.

Утилиты DOCSHELL предназначались для командной строки, поэтому интерфейс общения с плагином «DOCSHELL.dll» был реализован с помощью такого же механизма текстовых команд.
Перед тем, как начать общение с «DOCSHELL.dll» необходимо вызвать каждый из экспортируемых методов и передать в них указатели на реализованные у себя в софте функции для физического обмена с микросхемой mDOC. Это запись и чтение (в нескольких модификациях), а также методы для принятия текстовых сообщений о ходе выполнения текущих операций и методы для работы с файлами образа.

Один из экспортируемых методов «mainEntry» в качестве входного аргумента
принимает ASCIIZ-строку — команду, описанную в руководстве «Software Utilities for TrueFFS 7.1» (3).

Парсер внутри «DOCSHELL.dll» обрабатывает полученную команду и в зависимости от самой команды и ее аргументов вызывает тот или иной метод из основного софта программатора по указателю, полученному при первоначальной инициализации.

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

Собственный пользовательский интерфейс для программатора был написан на C# в Visual Studio 2017. Исходники (6) прилагаются.

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


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

Ниже расположены два окна. В верхнее выводятся сообщения, отправляемые из программы в плагин «DOCSHELL.dll» и получаемые из него.

В нижнем окне можно набирать нужные вам команды и выполнять их двойным щелчком мыши в соответствующей строке.

При старте программы в нем будут отображены некоторые команды.

Если вдруг у вас дойдет дело до работы с реальной микросхемой — будьте осторожны, т.к. никаких предупреждений о том, что вы можете потерять все данные при форматировании и т.п. в программе не реализовано.

Файл «DOCSHELL.dll» обнаруживается в директории с установленной программой PG4UW (4) от «Dataman» (можно и от «Elnec»).

Чтобы иметь возможность использовать стороннюю DLL в своей программе необходим заголовочный файл с описанием экспортируемых методов и их аргументов. За его отсутствием пришлось эту информацию восстанавливать самостоятельно. Способы такого восстановления выходят за рамки данной статьи, поэтому аргументы экспортируемых методов можно найти в прилагаемых исходниках.

С пользовательским интерфейсом в части его взаимодействия с плагином дело несколько прояснилось. Теперь можно перейти к реализации общения с микросхемой на физическом уровне, чтобы иметь возможность выполнения получаемых из плагина команд чтения/записи из/в mDOC.

Программный модуль для программатора был написан на языке C в IDE «IAR Embedded Workbench for ARM». Исходники (7) прилагаются.

Его отладка осуществлялась с помощью JTAG отладчика J-Link, подключаемого к программатору через JTAG разъем, смонтированный на боковой панели корпуса и соединенный с материнской платой плоским шлейфом.

JTAG отладчик J-Link v9 приобретался на Aliexpress. Драйвера, устанавливаемые вместе с «IAR Embedded Workbench for ARM» с ним замечательно работают и даже обновление родной прошивки от SEGGER прошло успешно.


Конструктивно программатор выполнен в виде восьми плат, расположенных одна над другой и соединенных вместе разъемами.


На самой нижней плате размещены регулируемые DC-DC преобразователи для формирования нескольких напряжений, необходимых для работы с различными микросхемами памяти.
Над ней находится материнская плата, на которой располагаются ARM микроконтроллер ATMEL AT91SAM9G20, SDRAM, SPI FLASH с прошивкой, ID чип AE801 с моделью программатора и его серийным номером, микросхема USB контроллера ISP1582, цифро-аналоговый преобразователь TLC7226 для управления напряжениями DC-DC конвертеров, ряд других микросхем и внешние разъемы для подключения блока питания и USB кабеля для соединения с хостом.

На третьей снизу плате размещается микросхема XILINX XC2S50E, которая управляет ножками микросхемы на подключенном к программатору адаптере во время процедур чтения/записи и т.д.
На остальных пяти платах находятся последовательно загружаемые регистры и подключенные к их выходам сборки с транзисторными ключами, через которые можно подавать на те или иные ножки микросхемы в адаптере сформированные DC-DC преобразователями напряжения,
в том числе и «землю». Так как регистры, управляющие транзисторными ключами — с последовательной загрузкой, а количество управляемых ножек в адаптере может достигать 144, то на загрузку всех блоков ключей требуется значительное время. Поэтому с помощью транзисторных ключей на микросхему подаются только статические уровни: «земля», питание и т.п. А с помощью XILINX — динамические: адреса, данные, CS, OE, RD, WR и т.п.

Чтобы продвинуться дальше необходимо было, как минимум, иметь средство создания прошивки для микросхемы XILINX XC2S50E и принципиальную схему если не всего программатора, то хотя бы его части CPU — FPGA — адаптер — сокета.

Что касается IDE для XILINX Spartan-IIE, то пришлось использовать старую версию ISE 10.1, т.к. все последующие IDE не поддерживают модель FPGA Spartan-II.

С принципиальной схемой ситуация оказалась сложнее. Чтобы идентифицировать интересующие нас соединения пришлось «вынимать» из плат процессор U4 и XILINX U12 для получения доступа к контактным площадкам под их BGA корпусами, т.к. не все из них имеют переход на обратную сторону.
Механизм общения хоста с программатором осуществляется по USB через несколько конечных точек (Endpoints). Хост всегда выступает в роли ведущего. Через одну из конечных точек хост передает в программатор команду и через нее же получает подтверждение,
через другую обмениваются между собой данными.

Парсинг команд от хоста в программном модуле осуществляется в методе USB_ReceiveBuf_EP1RX_Parse().

Командный пакет описывается структурой CMD_PROG и состоит из нескольких полей. Если поле Cmd содержит 1, значит это команда для работы с микросхемой и поле ProgProcNum в этом случае является индексом в массиве _progProcedures структур PROG_PROC, в одном из полей которой хранится указатель на выполняемую команду.

В каталоге с установленной программой «SUPERPRO 6100N» находится подкаталог "\lib". В нем с расширением "*.bin" хранятся файлы прошивок XILINX для всех поддерживаемых программатором типов микросхем. Среди них есть две универсальных прошивки для проверки контакта ножек микросхемы с контактами сокеты в адаптере.

Это «GENERAL~.BIN» с внутренней подтяжкой всех ножек XILINX pull-up и «GENERAL_.BIN» с внутренней подтяжкой pull-down.

Проверка контакта ножек микросхемы осуществляется в методе SOCKET_CkeckInsertIC() программного модуля следующим образом.

Сначала в XILINX загружается прошивка «GENERAL_.BIN» и с ее помощью все ножки FPGA, подключенные к сокете настраиваются на вывод и на них подаются логические «1». Затем поочередно каждая ножка FPGA перенастраивается на ввод, с нее считывается логический уровень и затем на эту ножку вновь выводится «1».

Если ножка микросхемы имеет электрический контакт с соответствующей ножкой сокеты, то с нее должна читаться «1» (через внутренние защитные диоды микросхемы со всех остальных ножек). А в случае отсутствия контакта благодаря тому, что все выводы FPGA подтянуты в «землю» с этого входа прочтется «0». После этого массив считанных таким образом логических уровней отправляется в хост и там обрабатывается. Далее продолжается выполнение заданной операции, либо выводится сообщение о неконтакте соответствующих ножек микросхемы в сокете.
После успешного прохождения этого теста хост отправляет в программатор прошивку для XILINX, соответствующую установленной в адаптер микросхеме.

Компиляция программы для FPGA в ISE 10.1 ( последовательное выполнение процедур синтеза (Synthesize), реализации дизайна (Implement Design) и генерации файлов для программирования (Generate Programming File) ) создает в каталоге с проектом двоичный файл конфигурации «xeltek.bin» размером 78756 байт. Для этого в свойствах процесса «Generate Programming File» в окне «Processes» в категории «General Options» должны быть установлены две опции: «Create Bit File» и «Create Bibary Configuration File».

Неизвестно по каким причинам, но программисты из XELTEK решили модифицировать получаемые таким образом файлы путем зеркальной перестановки всех бит в каждом байте.

Если вам по каким либо причинам понадобится таким образом «зазеркалить» собственный файл, либо «отзеркалить» обратно в нормальный вид файл из каталога "\lib", в софте в меню «XILINX» есть для этого пункт «Bitstream Converter» (в конец названия полученного файла добавляется подчеркивание).

Для работы с микросхемой SDED5 на физическом уровне в программном модуле реализованы следующие четыре метода:

— PROGPROC_FLWRITE_IO_WORD() — запись слова (16 бит) по заданному адресу
— PROGPROC_FLREAD_IO_WORD() — чтения слова (16 бит) по заданному адресу
— PROGPROC_hal_blk_write_nor() — запись одного или нескольких секторов (по 512 байт) по заданному адресу
— PROGPROC_hal_blk_read_nor() — чтение одного или нескольких секторов (по 512 байт) по заданному адресу

Для взаимодействия с FPGA XILINX в своей прошивке мы определили четыре регистра (порта ввода-вывода, описанных в файле «common.h» исходников для ARM).

— _IC_ADDR (0x30000010)
— _IC_DATA (0x30000012)
— _IC_CTRL (0x30000014) // Out: 0 — WE, 1 — 0E, 2 — CE, 3 — RSTIN; In: 0 — BUSY
— _IC_ENABLE (0x30000016) // In: 7 — Разрешение работы ( 0 — активный, 1 — все ножки на сокете в Z )

_IC_ADDR и _IC_DATA — это 16-битные регистры адреса и данных для программируемой микросхемы SDED5;
_IC_CTRL — 8-битный контрольный регистр, через который осуществляется установка сигналов WE, OE, CE и RSTIN и чтение сигнала BUSY c SDED5.

В оригинальных программных модулях для общения с FPGA используются адреса с 0x30000000 по 0x3000000E. В качестве дешифратора адреса в программаторе установлена CPLD с надписью XELTEK, а так как ее прошивка нам не известна, мы, на всякий случай, использовали адреса с 0x30000010, чтобы уменьшить вероятность неожиданных последствий от проявления чужой логики поведения при использовании «стандартных» адресов.

После загрузки в FPGA своей прошивки все выходы FPGA, подключенные к ножкам микросхемы в сокете находятся в Z состоянии и чтобы начать с ней работу необходимо включить разрешение, записью нуля в седьмой бит регистра _IC_ENABLE.

Алгоритм работы всей системы может выглядеть следующим образом.

1. После старта софта на хосте он проверяет, есть ли соединение с программатором по USB и выводит соответствующее сообщение в статусной строке в нижней части главного окна
   (программатор может быть подключен и после старта программы).
2. Пользователь выбирает тип микросхемы, с которой намерен работать.
3. В базе данных (в простейшем случае — просто в файле) находится соответствие выбранной микросхемы типу необходимого адаптера и в программатор отправляется запрос на тип установленного в нем адаптера.
4. Программатор запрашивает у адаптера его тип и отправляет эту информацию обратно в хост, где эта информация сравнивается с найденной в базе данных и в случае совпадения типов адаптеров работа продолжается.
5. Для каждого типа выбранной микросхемы в софте должно отображаться соответствующее меню с доступными для этой микросхемы командами (чтение, запись, проверка на чистоту, сравнение и т.д.).
6. При выборе какой либо пункта меню для работы с микросхемой в программатор отправляется соответствующая команда, после чего программатор первым делом проверяет наличие электрического контакта контактов сокеты с ножками микросхемы, а затем в случае успеха, выполняет данную команду.

В прилагаемых к статье исходниках для упрощения задачи пункты со второго по пятый включительно не реализованы.

Итог

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

Спасибо за проявленный интерес!

Ресурсы

1. PDF — mDOC H3 Embedded Flash Drive (EFD) featuring Embedded TrueFFS Flash Management Software
2. PDF — Programming mDOC H3 Flash Memories Using Dataman Device Programmers
3. PDF — Software_Utilities_TrueFFS_7.1
4. Dataman Control Software — PG4UW
5. Реализация драйвера mDOC H3 для Linux (работоспособность не проверялась)
6. Исходные файлы программатора для хоста (Visual Studio 2017).
7. Исходные файлы программного модуля (IAR Embedded Workbench for ARM v8.30.1).
8. Исходные файлы для FPGA XILINX XC2S50E (XILINX ISE 10.1).