Кампания по продвижению нанокомпьютера black swift в самом разгаре (см. также публикацию на habrahabr). black swift построен на базе SoC Atheros AR9331, что позволило сделать его с одной стороны крошечными, недорогим, и малопотребляющим, а с другой стороны в распоряжении пользователя находится процессорное ядро MIPS 24Kc, работающее на частоте до 400 МГц. Недавно на форуме black-swift.ru был задан вопрос В данной публикации я вставлю свои пять копеек приведу конкретный простой сценарий использования JTAG-интерфейса SoC Atheros AR9331 для отладки программного обеспечения. Публикация может быть интересна не только разработчикам ПО для AR9331, но и всем интересующимся внутрисхемной отладкой на процессорах с архитектурой MIPS при помощи свободного ПО. Плат black swift в свободном доступе на момент написания данной публикации ещё нет, однако доступны готовые устройства на базе SoC Atheros AR9331; для демонстрации я буду использовать TP-Link MR3020. Различие между MR3020 и black swift минимально, более того, освоившему работу с MR3020 переход на black swift может показаться даже облегчением: подключаться к внешним интерфейсам SoC станет проще, а программных препонов меньше. План демонстрации: мы остановим процессор сразу после старта и запустим на нём вместо штатного зашитого в ПЗУ загрузчика U-Boot другой загрузчик — barebox. Какую пользу (применительно к MR3020) можно извлечь от использования EJTAG?
- ребята из TP-Link наложили ограничения на внесения изменений в прошивку устройства (хотя, они не очень сильно старались) — возможность использовать EJTAG снимает эти ограничения;
- возможность использовать EJTAG сразу после старта процессора значительно упрощает отладку начальной стадии загрузчика barebox (действительно, использовать EJTAG гораздо комфортнее, нежели возиться с перепрошивкой загрузочного ПЗУ на программаторе);
- EJTAG позволяет восстановить работоспособность устройства после «окирпичивания» в результате порчи содержимого загрузочного ПЗУ.
Чтобы не доходить до уровня изложения «делай раз, делай два, нажми на кнопку — получишь результат» я постараюсь давать минимальные пояснения. Начать стоит с пояснения того, что такое EJTAG.
EJTAG в процессорах с архитектурой MIPS
Без стадии отладки не обходится разработка никакого программного продукта, и счастье программисту, если в его распоряжении имеется толковый отладчик (англ. debugger). Разработчики ПО для *nix или Windows могут воспользоваться развитыми средствами отладки — можно прогнать свою программу шаг за шагом, посмотреть значения переменных в тот или иной момент времени, поставить точки останова. Но как быть разработчику ПО для встраиваемой системы? Такое ПО может работать вне окружения какой-либо ОС, а сама встраиваемая система мало похожа на ПК — ни клавиатуры ни монитора как правило нет. Для того чтобы как-то упростить жизнь в описанной ситуации придумана технология внутрисхемной отладки (англ. in-circuit debugging), которая заключается в следующем: в состав процессора вводится специальный блок (назовём его «блок отладки»), следящий за процессом исполнения инструкций и способный на него повлиять. Этот блок действует не сам по себе, но по командам пользователя (каковым является программист, проводящий отладку ПО). Для внешнего управления этим блоком отладки часто используется интерфейс JTAG. Для процессоров MIPS стандартным является набор аппаратных и программных средств для внутрисхемной отладки под названием EJTAG. EJTAG стандартизирован в документах MIPS EJTAG Specification; существует сразу несколько версий этой спецификации; к примеру в состав процессорного ядра 24Kc входит блок отладки, соответствующий спецификации EJTAG 2.60.
Что надо для работы с EJTAG?
- Процессор MIPS с поддержкой EJTAG (англ. target или целевой процессор);
- Инструментальная ЭВМ с которой мы будем управлять целевым процессором;
- Устройство, обеспечивающее подключение ЭВМ к интерфейсу JTAG (англ. dongle);
- ПО, которое исполняется на инструментальной ЭВМ, получает от пользователя указания по управлению целевым процессором, и через dongle отправляющее в целевой процессор необходимые команды.
Сразу заметим, что от пользователя не требуются глубокие знания по организации EJTAG, указания по управлению целевым процессором вполне абстрактны, например:
- остановить исполнение инструкций процессором;
- начать исполнение инструкций с адреса такого-то;
- выполнить одну инструкцию и остановиться;
- посмотреть содержимое регистров процессора.
Для нашей демонстрации будем использовать:
- процессор с EJTAG — MIPS 24Kc из состава SoC Atheros AR9331;
- инструментальная ЭВМ — ПК с процессором с архитектурой x86/amd64, работающий под управлением ОС Debian Linux (хотя другие ОС на базе Linux тоже подойдут);
- JTAG dongle — макетная плата с микросхемой FT2232H (а именно microsin.net/adminstuff/hardware/ft2232h-board.html) (далее просто макетка);
- ПО для управления AR9331 через EJTAG —
openocd(http://openocd.sourceforge.net/).
Кроме того, очень желательно подключиться также к интерфейсу UART AR9331, он пригодится для взаимодействия с программами, исполняющимися на процессоре (без подключения к UART демонстрация была бы довольно скучной). Для отправки и приёма символов в UART AR9331 используем программу minicom. Макетка FT2232H обеспечивает подключение сразу и к UART и к JTAG.
Подключение макетки FT2232H к MR3020
Вот схема подключения (см. также статью на wikidevi.com):
Внешний вид MR3020 с подключённой макеткой FT2232H:
Подключение к UART
Вывод интерфейса UART из MR3020 не представляет проблем: на плате уже есть отверстия для впайки штырей. Обозначения TX и RX на фотографии указаны с точки зрения AR9331, т.е. TX AR9331 (pin 1 на плате) надо подключать к RX FT2232 (BDBUS1). Рекомендую подключить UART MR3020 к макетке, а саму макетку к инструментальной ЭВМ, и затем, включив питание MR3020, пронаблюдать при помощи minicom сообщения штатного загрузчика U-Boot. Вот что для этого надо выполнить ряд шагов.
Проверка подключения макетки к инструментальной ЭВМ
Подключить UART MR3020 к макетке; подключить макетку FT2232H к инструментальной ЭВМ по USB; на инструментальной ЭВМ в командной строке запустить dmesg — убедиться, что появились сообщения вроде
[1573965.608101] usb 1-2: new high-speed USB device number 63 using ehci-pci [1573965.740851] usb 1-2: New USB device found, idVendor=0403, idProduct=6010 [1573965.740862] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [1573965.740868] usb 1-2: Product: Dual RS232-HS [1573965.740874] usb 1-2: Manufacturer: FTDI [1573965.741737] ftdi_sio 1-2:1.0: FTDI USB Serial Device converter detected [1573965.741938] usb 1-2: Detected FT2232H [1573965.741948] usb 1-2: Number of endpoints 2 [1573965.741957] usb 1-2: Endpoint 1 MaxPacketSize 512 [1573965.741966] usb 1-2: Endpoint 2 MaxPacketSize 512 [1573965.741974] usb 1-2: Setting MaxPacketSize 512 [1573965.742920] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0 [1573965.743493] ftdi_sio 1-2:1.1: FTDI USB Serial Device converter detected [1573965.743662] usb 1-2: Detected FT2232H [1573965.743672] usb 1-2: Number of endpoints 2 [1573965.743681] usb 1-2: Endpoint 1 MaxPacketSize 512 [1573965.743690] usb 1-2: Endpoint 2 MaxPacketSize 512 [1573965.743699] usb 1-2: Setting MaxPacketSize 512 [1573965.744669] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB1 Из этого сообщения следует, что на инструментальной ЭВМ появились два новых последовательных интерфейса /dev/ttyUSB0 и /dev/ttyUSB1. В соответствии со схемой подключения к UART MR3020 оказывается подключён второй из двух интерфейсов, то есть /dev/ttyUSB1.
Что такое JTAG-программатор?Установка и настройка minicom
Установка программы minicom в основанных на Debian дистрибутивах очень проста:
$ sudo apt-get install minicom Программа minicom очень добра к новичку — все настройки можно провести через меню, однако эта доброта имеет и обратную сторону — довольно неудобно объяснять как именно выставить необходимые настройки. Чтобы не связываться с системой меню minicom поступим проще — произведём настройки при помощи конфигурационного файла. Для простоты сделаем глобальный конфигурационный файл, для этого от root’а выполним:
# cat < /etc/minicom/minirc.USB1 pu port /dev/ttyUSB1 pu baudrate 115200 pu escape-key ^B pu rtscts No EOF Замечание для пользователей не-Debian дистрибутивов: конфигурационные файлы для
minicomмогут располагаться в месте, отличном от/etc/minicom/.
Указанный конфигурационный файл говорит minicom‘у, что отклонения от настроек по умолчанию заключаются в следующем:
- используется порт /dev/ttyUSB1;
- настроить скорость порта 115200;
- клавиша начала команд
minicom— ctrl-b; например, для вызова главного меню надо нажать ctrl-b, затем z; - аппаратное управление потоком отключено (действительно, для подключения мы использовали только линии RX и TX, какое уж там аппаратное управление потоком).
Запуск minicom
Для простоты запустим minicom от root’а;
# minicom USB1 При этом minicom использует настройки из файла /etc/minicom/minirc.USB1 (если конечно файл ~/.minirc.USB1 не существует). Теперь включаем питание MR3020 и наблюдаем в minicom сообщения от U-Boot:
U-Boot 1.1.4 (Aug 17 2012 - 15:21:03) AP121 (ar9330) U-boot DRAM: 32 MB led turning on for 1s... id read 0x100000ff flash size 4194304, sector count = 64 Flash: 4 MB Using default environment Далее будут выданы сообщения о загрузки linux, но они нам не очень-то и интересны; если какой-то разумный вывод из UART поступает, то можно переходить к подключению JTAG.
Подключение к JTAG
Подключение к JTAG не тривиально, но возможно. См. статью на wikidevi.com. Кроме четырёх линий JTAG необходимо также обеспечить отключение загрузочного ПЗУ; в статье на wikidevi.com для этого предлагается разрывать линию ChipSelect при помощи перемычки (джампера). Дело в том, что штатный загрузчик U-boot, находящийся в ПЗУ, почти сразу после старта блокирует работу JTAG. В случае же старта процессора с неработающим ПЗУ ничего страшного не произойдёт, процессор будет вместо программы из ПЗУ выполнять «мусор». Процессор попадёт в сложное положение, но EJTAG останется доступным. После того, как все линии JTAG оказались соединены с соответствующими выводами FT2232H, а загрузочное ПЗУ отключено, можно попробовать просканировать JTAG-цепочку при помощи openocd. Но прежде чем запустить openocd, его придётся установить и настроить… Установка программы openocd не сложнее установки minicom:
$ sudo apt-get install openocd openocd: начальная настройка
В openocd встроен язык tcl, все сценарии работы и конфигурационные файлы пишутся на нём. Однако для нашего простейшего случая конфигурационный файл будет совсем прост. Создадим файл ft2232h-scan.cfg, в котором укажем openocd, что будем использовать dongle на базе FT2232H для доступа к JTAG:
$ cat < ft2232h-scan.cfg interface ftdi ftdi_vid_pid 0x0403 0x6010 ftdi_layout_init 0x0018 0x05fb adapter_khz 100 shutdown EOF В этом файле мы укажем, что для подключения к JTAG будем использовать «драйвер» ftdi, который и обслуживает все многочисленные dongl’ы на базе FT2232H. Опция ftdi_vid_pid указывает Vendor ID и Device ID микросхемы FT2232H на шине USB (по умолчанию это как раз 0x0403 0x6010; эти ID были в выводе dmesg, в любой момент их можно просмотреть при помощи программы lsusb). Опция ftdi_layout_init указывает настройки GPIO выходов FT2232H. Опция adapter_khz определяет максимальную частоту тактового сигнала JTAG; 100 КГц (невысокая частота) хорошо подходит для сканирования. Директива shutdown заставит openocd завершить работу сразу после сканирования JTAG. Давайте запустим openocd от root’а (Внимание! Запускать openocd следует после включения питания MR3020, причем в момент включения питания должна быть нажата кнопка SW2 на плате MR3020; также не забудьте заблокировать загрузочное ПЗУ):
ZMI 10 (QB820) — один из самых технологичных внешних аккумуляторов на рынке# openocd -f ft2232h-scan.cfg Open On-Chip Debugger 0.8.0 (2014-10-20-22:02) Licensed under GNU GPL v2 For bug reports, read http://openocd.sourceforge.net/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' adapter speed: 100 kHz shutdown command invoked Info : clock speed 100 kHz Warn : There are no enabled taps. AUTO PROBING MIGHT NOT WORK!! Warn : AUTO auto0.tap - use "jtag newtap auto0 tap -expected-id 0x00000001 ..." Warn : AUTO auto0.tap - use "... -irlen 5" Warn : gdb services need one or more targets defined В этом выводе наибольшего внимания заслуживают строчки, содержащие AUTO auto0.tap — в них приводится информация о найденных абонентах JTAG (tap-контроллерах), причём сразу приводится пример строки которую надо занести в конфигурационный файл openocd для работы со свежеобнаруженным tap-контроллером. Воспользуемся этими строчками и создадим конфигурационный файл для openocd, который обеспечит загрузку в ОЗУ образа загрузчика barebox. Но прежде чем грузить образ barebox, его надо где-то взять; а так как готовых подходящих образов нигде нет, будет собирать образ самостоятельно из исходных текстов.
Сборка barebox
Образ barebox для AR9331 должен состоять из инструкций процессора MIPS32, а наша инструментальная ЭВМ почти наверняка построена на базе процессора с системой команд x86 или amd64 (так их, во всяком случае, называет Debian). Для того, чтобы при помощи процессора x86/amd64 породить инструкции MIPS32, нам понадобится кросс-компилятор (то есть компилятор, который исполняется на ЭВМ с одной архитектурой команд, а генерирует код для ЭВМ с другой системой команд). Сборка кросс-компилятора с требуемыми свойствами — задача совсем не тривиальная и для её облегчения создано немало всяких инструментов, известных по ключевым словам buildroot, openwrt, crosstool-ng. Однако в этой демонстрации мы пойдём простым путём — скачаем готовый кросс-компилятор от MentorGraphics. Итак, скачиваем и распаковываем в /opt готовый кросс-компилятор:
$ wget http://sourcery.mentor.com/public/gnu_toolchain/mips-linux-gnu/mips-2014.11-22-mips-linux-gnu-i686-pc-linux-gnu.tar.bz2 $ sudo tar fx mips-2014.11-22-mips-linux-gnu-i686-pc-linux-gnu.tar.bz2 -C /opt В результате, к примеру, путь к кросс-компилятору Си будет таким: /opt/mips-2014.11/bin/mips-linux-gnu-gcc. Теперь скачаем и распакуем исходные тексты загрузчика barebox:
$ wget http://barebox.org/download/barebox-2015.01.0.tar.bz2 $ tar fx barebox-2015.01.0.tar.bz2 Произведём сборку barebox:
$ cd barebox-2015.01.0 $ make ARCH=mips tplink-mr3020_defconfig $ make ARCH=mips CROSS_COMPILE=/opt/mips-2014.11/bin/mips-linux-gnu- $ cd .. Если всё прошло хорошо, то получим файл barebox-2015.01.0/barebox.bin.
openocd: более полная настройка
Теперь у нас есть то, что мы можем грузить в ОЗУ MR3020; парадоксально, но у нас нет самого ОЗУ! Дело в том, что когда для сохранения работоспособности EJTAG мы отключили загрузочное ПЗУ вместе с ним мы отключили начальную инициализацию аппаратуру AR9331, в том числе инициализацию контроллера ОЗУ и контроллера UART. На наше счастье, последовательность записей в регистры для инициализации аппаратуры уже известна. Окончательно файл ft2232h-mr3020.cfg, который обеспечит подключение к блоку отладки AR9331, начальную инициализацию аппаратуры, загрузку образа barebox.bin в ОЗУ MR3020 по адресу 0xa0100000 и запуск его на выполнение выглядит так:
interface ftdi ftdi_vid_pid 0x0403 0x6010 ftdi_layout_init 0x0018 0x05fb adapter_khz 600 jtag newtap auto0 tap -expected-id 0x00000001 -irlen 5 target create auto0.tap mips_m4k -endian big -chain-position auto0.tap init halt # pll initialization mww 0xb8050008 0x00018004 mww 0xb8050004 0x00000352 mww 0xb8050000 0x40818000 mww 0xb8050010 0x001003e8 mww 0xb8050000 0x00818000 mww 0xb8050008 0x00008000 sleep 1 # Setup DDR1 config and flash mapping mww 0xb8000000 0x7fbc8cd0 mww 0xb8000004 0x9dd0e6a8 mww 0xb8000010 0x8 mww 0xb8000008 0x133 mww 0xb8000010 0x1 mww 0xb800000c 0x2 mww 0xb8000010 0x2 mww 0xb8000010 0x8 mww 0xb8000008 0x33 mww 0xb8000010 0x1 mww 0xb8000014 0x4186 mww 0xb800001c 0x8 mww 0xb8000020 0x9 mww 0xb8000018 0xff # UART mww 0xb8020004 0x4388 mww 0xb8020008 0xc2000 # GPIO mww 0xb8040028 0x48002 load_image barebox-2015.01.0/barebox.bin 0xa0100000 bin resume 0xa0100000 shutdown openocd: загрузка barebox
Итак, загрузим и запустим barebox (Не забудьте про джампер отключения ПЗУ. Также не забывайте держать нажатой кнопку SW2 в момент включения питания MR3020! Наберитесь терпения — загрузка занимает более 100 секунд):
# openocd -f ft2232h-mr3020.cfg Open On-Chip Debugger 0.8.0 (2014-10-20-22:02) Licensed under GNU GPL v2 For bug reports, read http://openocd.sourceforge.net/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' adapter speed: 600 kHz Info : clock speed 600 kHz Info : JTAG tap: auto0.tap tap/device found: 0x00000001 (mfg: 0x000, part: 0x0000, ver: 0x0) target state: halted target halted in MIPS32 mode due to debug-request, pc: 0xb0ddd068 Error: No working memory available. Specify -work-area-phys to target. Warn : not enough working area available(requested 128) Error: No working area available Warn : Falling back to non-bulk write 185568 bytes written at address 0xa0100000 downloaded 185568 bytes in 102.970634s (1.760 KiB/s) shutdown command invoked После окончания работы openocd в окне minicom мы можем наблюдать сообщения о старте barebox’а:
barebox 2015.01.0 #1 Thu Jan 29 02:13:17 MSK 2015 Board: TP-LINK MR3020 m25p80 m25p80@00: unrecognized JEDEC id 900040 m25p80 m25p80@00: probe failed: No such device malloc space: 0xa0400000 -> 0xa07fffff (size 4 MiB) environment load /dev/env0: No such file or directory running /env/bin/init... /env/bin/init not found barebox:/ Далее желающие могут поиграть с командами barebox, список которых откроется по команде help. Обратите внимание на сообщение об ошибке probe failed: No such device, оно появилось из-за того, что barebox попытался «нащупать» загрузочное ПЗУ на шине SPI. Но так как для оживления EJTAG загрузочное ПЗУ было отключено, то попытка barebox’а чего-либо найти обречена на неудачу. Если исхитриться надеть перемычку, отключающую загрузочное ПЗУ во время загрузки barebox в память, то можно вместо
Плата SOIC8 и SSOP8m25p80 m25p80@00: unrecognized JEDEC id 900040 наблюдать более оптимистическое
m25p80 m25p80@00: s25sl032p (4096 Kbytes) Хотя barebox-2015.01.0 поддерживает аппаратуру SoC AR9331 в минимальном объёме (интерфейсы USB и Ethernet не поддерживаются), но прочитать и записать загрузочное ПЗУ barebox’у вполне по силам.
Что дальше? (вместо послесловия)
Загрузка данных в ОЗУ — это не предел возможностей EJTAG. Но нельзя объять необъятное — в публикации не освещены вопросы собственно отладки — этот материал остаётся для будущих публикаций. Законное негодование вызывает низкая скорость передачи данных — менее 2 Кбайт в секунду, этот момент также надо попытаться исправить.
Благодарности
Автор выражает благодарность людям, без участия которых данная публикация едва ли была бы возможна:
- Алексею Ремпелю, который освоил подключение к JTAG MR3020 и опубликовал свои заметки;
- Цена: 55 USD
Любой более-менее интересующийся электроникой человек сегодня знает, что такое «прошивка». Многие из этой категории встречались с ситуацией «прошивка слетела». Самым неприятным подвидом ситуации является состояние «кирпич». Под катом немного теории и практики «раскирпичивания» с использованием устройства-героя обзора. Я не занимаюсь профессионально ремонтом электроники и не пытаюсь заработать на этом денег. Но исследовательский зуд вкупе с минимальными познаниями в области электроники и информатики иногда толкает меня на залезание в потроха какому-нибудь очередному дивайсу (и как следствие, незапланированные покупки).Предыстория. Как-то в гостях у знакомого я наткнулся взглядом на валяющийся в куче хлама спутниковый тюнер, еще вполне себе современный. Выяснилось, что аппарат неисправен со следующими симптомами: когда-то грузился со второго раза, потом стал грузиться с третьего, потом с пятого, потом с десятого, потом перестал совсем. В сервисе за ремонт заломили неадекватную сумму, в результате просто был куплен новый тюнер, а этот брошен в кучу хлама. На предложение купить его за символическую сумму владелец с радостью согласился, в результате я стал обладателем неисправного тюнера Skyway Light с практически полным комплектом — нашелся пульт, блок питания и даже выносной ИК-приемник.Первое включение. Как ни странно, но включился он у меня не с двадцатого раза, а всего лишь с третьего. Отсканировал каналы и начал показывать. Но при попытке запустить приложение Youtube повис. Десять следующих перезагрузок методом перетыкания питания ни к чему не привели. Прошлый владелец не обманул.Подозрение первое. Питание. В интернете полно отчетов по оживлению тюнеров методом восстановления питающих напряжений. Обычно хватает замены вспухших электролитических конденсаторов в «холодной» части блока питания. Но это явно обещало быть не моим случаем. Во-первых, блок питания выносной, замена его на однотипный от исправного тюнера не помогла. Во-вторых, никаких крупных электролитических конденсаторов на плате не нашлось, в основном мелкие сигнальные в аналоговых цепях.Подозрение второе. Прошивка. Обновить прошивку не удалось ни с флэш-драйва методом зажатой кнопки «вниз», ни через COM-порт с помощью программы Porter Express. В первом случае индикатор чтения на флэшке мигал несколько секунд, после чего наступала тишина. Во втором программы выдавала сообщение «ошибка записи» без какого-либо объяснения, что ее не устраивает. Так я подобрался к третьему подозрению.Подозрение третье. Чип флэш-памяти. Натолкнули на эту мысль сразу несколько фактов. Во-первых, в консоли загрузки, которая стала доступна после подключения по COM-порту, при старте вываливалось сообщение «CRC error». Во-вторых, при попытке снять конфигурацию тюнера при помощи Porter Express слитый файл получался каждый раз другим, не совпадающим в предыдущим при побайтовом сравнении.Что делать дальше? Беглое изучение Aliexpress показало, что такую микросхему можно купить за небольшие деньги. Но вот тут обнаружилась главная проблема: просто купить флэшку мало. Ее нужно прошить. Либо на программаторе, либо прямо на плате. В моем случае это чип Spansion S29GL256P90TFCR2 — параллельная флэш-память в корпусе TSOP-56. Поиск такого программатора ни среди друзей-электронщиков, ни в веб-магазинах по адекватной цене не увенчались успехом. Остается единственный вариант — прошить флэшку прямо на плате после запаивания. И тут впервые мысленно была произнесена фраза, которая обычно на форумах электроники звучит как приговор: «поможет только JTAG».Немного про JTAG. Практически в каждой современной системе-на-чипе есть возможность отладки и тестирования. Чаще всего она реализована в виде последовательного интерфейса с сигналами ввода, вывода, тактирования, выбора и сброса, который и называют JTAG. Обычно эти выводы разведены на плате в виде пинов или контактных площадок. Проблема в том, что стандартизирован только электрический интерфейс. Команды для управления конкретным чипом индивидуальны, мало того, большинство производителей их не разглашают и выяснять их приходится методом реверсивного инжиниринга. Именно поэтому в паблике практически нет инструментов для работы с современными популярными чипсетами.Заказ адаптера. Гугление коммерческих продуктов, которые умеют работать с моим чипсетом ST40, привело меня на ресурс ejtag.ru, где обитает комьюнити по ремонту и находится небольшой интернет-магазин. Присмотрев для себя самый дешевый адаптер и убедившись, что он умеет работать с ST40, начал переговоры с жабой приступил к процессу покупки. Процесс отличается от того, к чему мы привыкли в популярных интернет-магазинах. Никаких пэйпэлов и диспутов. Регистрируемся, кладем товар в корзину, оформляем заказ. Через некоторое время приходит сообщение с номером WM-кошелька и суммой для оплаты. Оплачиваем, приходит подтверждение оплаты, через несколько дней — уведомление об отправке. Остается только ждать. Гарантия сделки — доброе имя продавца.Получение, распаковка, регистрация. Пластиковый пакет почты России, внутри обернутый пупыркой и положенный в антистатический пакет адаптер, кабель USB A male — Mini USB, шлейф с десятипиновой колодкой (будет виден на других фото, на момент съемки был подцеплен к тюнеру), переходник для прошивки последовательных флэшек самых популярных серий — 25-й, 93-й и в теории 24-й.
JTAG – это нечто большее, чем просто отладка и перепрограммирование микросхем
Если Вы применяли какие-либо инструменты, использующие JTAG, то Вы уже знакомы с этим интерфейсом. Например, процессоры часто используют JTAG для доступа к своим отладочным функциям, также все ПЛИС используют JTAG для перепрограммирования.
Название JTAG чаще всего ассоциируется с инструментами отладки и перепрограммирования микросхем. Однако, в этих инструментах реализована только часть возможностей JTAG.
Эта часть возможностей, известная под названием Test Access Port или, сокращённо, TAP, является частью стандарта IEEE Std. 1149.1. Этот стандарт был разработан для тестирования сборок печатных плат (Printed Circuit Board Assemblies – PCBA) без необходимости доступа на так называемом «низком» (физическом) уровне, который требуется для анализа «сложных» случаев. Стандарт также не предусматривает разработку и использование специфических функциональных тестов. Изначально TAP был разработан только для взаимодействия с дополнительными регистрами, специально вставляемыми в микросхему с целью реализации данного метода тестирования.
Однако достаточно быстро производители микросхем заметили потенциал использования TAP и для других целей, например, для доступа к регистрам, предназначенным для отладки и перепрограммирования микросхем.
Теперь в микросхемы добавляется специальный регистр для тестирования через JTAG под названием Boundary Scan Register (BSR). Как и подразумевает название этого регистра, отдельные его части (или, по-другому, ячейки (Cells)) являются «пограничными» для микросхемы, так как располагаются между функциональным ядром и контактами корпуса микросхемы. По этой причине тестирование через JTAG часто называют пограничным сканированием (boundary scan).
Как технология пограничного сканирования, реализуемая стандартом JTAG, используется для тестирования печатных плат?
Ячейки регистра пограничного сканирования (Boundary Scan Register) могут работать в одном из двух режимов: 1) функциональный режим – ячейки не влияют на работу прибора, прибор работает в своём обычном виде; 2) тестирующий режим – ячейки отсоединяют функциональное ядро микросхемы от контактов корпуса. Тестирующий режим используется для управления значениями на контактах корпуса микросхемы (и в соответствующих цепях печатной платы), а также для считывания значений с подключённых цепей печатной платы.
Отключение функционального ядра микросхемы существенно упрощает разработку тестов, так как использование пограничного сканирования (boundary scan) позволяет не разрабатывать программу для микропроцессора или прошивку для ПЛИС и не включать прибор в «рабочем» режиме. Механизм управления и наблюдения за контактами корпуса микросхемы через четырёх-контактный TAP, JTAG интерфейс позволяет получить низкоуровневый доступ к контактам микросхемы для физического тестирования печатной платы.
Существует два способа тестирования печатной платы при помощи пограничного сканирования (boundary scan). Первый способ – тест соединений (connection test). Он даёт хорошее покрытие, особенно для поиска таких неисправностей, как замыкания. Этот способ использует только возможности микросхемы с поддержкой JTAG, при этом тестируются соединения (например, пропайки) и цепи, а в случае применения системы XJTAG, тестируются ещё и логические функции платы. Второй способ – использование микросхемы с поддержкой JTAG для взаимодействия с микросхемами без поддержки JTAG, такими как DDR RAM или Flash память.
Что такое тест соединений (connection test) через JTAG?
Тест соединений (connection test) проверяет, соответствует ли изготовленная печатная плата исходному проекту, а также наличие на ней не предусмотренных проектом разрывов цепей или лишних замыканий.
Если согласно проекту какие-то контакты микросхемы должны быть соединены где-то на плате, то можно проверить факт наличия соединения, подавая значения на один из контактов и считывая с других. Если согласно проекту контакты микросхемы НЕ соединены, то можно проверить, нет ли между ними лишнего замыкания, подавая на один из них значения и проверяя, что на остальные это не влияет.
Кроме того, тест соединений (connection test) позволяет обнаружить отсутствие нужных подтягивающих резисторов, и «залипания» сигналов. Это также делается путём выставления на контактах определённых значений и сравнения считанных значений с заданной таблицей истинности.
Система XJTAG на основе нетлиста печатной платы и информации, считанной с поддерживающих JTAG микросхем, полностью автоматически генерирует тестовые вектора для проведения теста соединений (connection test) всей платы.
Что же делать с остальными микросхемами на плате, которые не поддерживают JTAG?
Как правило, основные микросхемы на плате, такие как процессоры и ПЛИС, поддерживают JTAG, но существует множество вспомогательных микросхем, которые JTAG не поддерживают. Как пример можно привести такие микросхемы, как ЦАП, АЦП, DDR, SDRAM, SRAM, Flash, Ethernet контроллеры, температурные сенсоры, генераторы частот и многое другое.
Тест соединений (connection test) позволяет проводить тестирование на замыкания цепей между микросхемами с поддержкой JTAG и микросхемами без поддержки, при этом достигается хорошее покрытие. Однако протестировать обрывы в таких цепях уже не получится.
С целью тестирования на наличие обрывов цепей между микросхемами с поддержкой JTAG и микросхемами без таковой, требуется использовать так называемые функциональные тесты. Если функциональные тесты пройдены, то это означает, что обрывов быть не может. Функциональные тесты могут быть как очень простыми, например, включение светодиода и ожидание подтверждения от оператора, что светодиод действительно загорелся, так и посложнее, например, запись данных в память, считывание их же и сравнение считанных данных с ожидаемыми.
Насколько сложно подготовить JTAG тесты?
При помощи библиотеки тестов для стандартных микросхем без поддержки JTAG, поставляемой с системой XJTAG, возможна подготовка и запуск набора функциональных тестов без необходимости программирования. Библиотека тестов содержит тесты как для простых элементов, таких как резисторы и буферные элементы, так и для сложных микросхем, таких как память DDR3 и так далее.
Т.к. пограничное сканирование (boundary scan) отключает контакты корпуса микросхемы от функционального кремниевого ядра, единая тестовая модель может быть использована для управления периферийными микросхемами вне зависимости от того, какая микросхема с поддержкой JTAG использована.
Как правило, в печатную плату не требуется вносить никаких изменений, так как большинство плат уже содержат JTAG контакты для отладки процессоров или программирования ПЛИС.
Что ещё нужно для использования микросхем с поддержкой JTAG?
Для тестирования печатной платы при помощи пограничного сканирования (boundary scan) требуется для каждой микросхемы с поддержкой JTAG скачать с сайта производителя микросхемы так называемый BSDL-файл – Boundary Scan Description Language. Это текстовый файл, описывающий назначения ножек корпуса микросхемы.
Используется ли JTAG тестирование в основном на производстве?
Не совсем. Одним из важнейших преимуществ тестирования через пограничное сканирование (boundary scan) является тот факт, что из дополнительного оборудования требуется только JTAG контроллер. Другие технологии тестирования, такие как летающие щупы (flying probe), рентгеновское сканирование, многозондовое тестирование (bed-of-nails) и так далее требуют наличия дорогостоящего оборудования, которое не всегда доступно.
Использование пограничного сканирования (boundary scan) при первом тестировании позволяет проводить тестирование более уверенно, так как не требует включения платы в основной режим работы и даже может быть выполнено ещё до окончания разработки «прошивки». Эти же тесты, разработанные при проектировании, могут быть использованы и на производстве.
BGA
С увеличением доли микросхем, реализованных в корпусе BGA (Ball Grid Array), применение традиционных систем тестирования печатных плат, таких как многозондовое тестирование (bed-of-nails) или летающие щупы (flying probe) становится всё более ограниченным, так как «внутренние» контакты физически недоступны.
Пограничное сканирование (boundary scan) на основе JTAG при помощи простого «четырёхконтактного» интерфейса позволяет произвольно управлять контактами корпуса микросхемы с поддержкой JTAG, в том числе считывать значения, не имея к контактам физического доступа.
Стенд
В процессе проектирования и отладки временн´ые и денежные затраты на разработку/приобретение испытательных/отладочных стендов могут быть очень существенными, а в некоторых случаях и превышать затраты на само проектирование. Во многих случаях использование пограничного сканирования (boundary scan) позволяет вообще отказаться от применения испытательного стенда, а в остальных случаях подойдет и значительно более простой и дешёвый стенд.
Малые партии
случае, когда у компании имеется много проектов плат, выпускаемых малыми партиями, задача удешевления тестового оборудования особенно актуальна. Единственно приемлемым вариантом в данном случае является покупка системы «летающие щупы» (flying probe), но если цена при этом делится на все проекты, то временн´ые затраты на подготовку теста для каждого проекта остаются неприемлемыми. Использование пограничного сканирования (boundary scan) позволяет ускорить подготовку теста для каждого проекта, при том, что покупка дорогостоящего тестового оборудования теперь не требуется.
Стоимость разработки теста
Так как разные микросхемы (процессоры и ПЛИС) взаимодействуют с периферией разными способами, разработка традиционного функционального теста отдельно для каждой платы является очень затратной. Пограничное сканирование (boundary scan) существенно сокращает стоимость разработки тестов благодаря упрощённому способу управления контактами корпуса микросхемы для взаимодействия с остальными компонентами на плате. А унифицированный интерфейс JTAG позволяет формировать отдельные тесты как библиотечные элементы и использовать их в разных проектах вне зависимости от применяемых микросхем с поддержкой JTAG.
И для тестирования и для программирования
JTAG часто применяется для программирования микросхем (ПЛИС) на плате в процессе производства. А если к программированию дополнительно добавить тестирование платы через так называемое пограничное сканирование (boundary scan), то получится существенно сэкономить время и упростить производство.
Использование на производстве тех же тестов, которые применялись при проектировании
Обычно для тестирования изделий на производстве применяется большое дорогостоящее оборудование. Всё, что требуется для применения пограничного сканирования (boundary scan) через JTAG – это контроллер XJLink, размерами сопоставимый с компьютерной мышью.
Удобная диагностика неисправностей
Пограничное сканирование (boundary scan) через JTAG, в отличие от специально разработанных функциональных тестов, позволяет получать информацию о точном месте возникновения неисправности, что очень помогает при восстановлении платы. А применение системы XJTAG ещё и позволяет визуализировать место неисправности на плате и указать точное место в принципиальной схеме.
Восстановление нерабочих плат, где функциональные тесты бессильны
Пограничное сканирование (boundary scan) через JTAG можно использовать на плате, где не работает ничего, кроме самого JTAG интерфейса. Если плата не включается, то провести традиционные функциональные тесты не получится. Простейшая неисправность в таких элементах на плате, как память или генератор синхросигнала не позволят применить функциональный тест, но легко обнаруживается при помощи JTAG.
Other resources
High-Level Guide to JTAG
See what JTAG can do
Technical Guide to JTAG
A low-level look at how JTAG is implemented
Design for Testability (DFT) Guidelines
Suggestions for improving the testability of circuits
JTAG Testing with XJTAG
How XJTAG extends the possibilities of JTAG
Используемые источники:
- https://habr.com/post/375995/
- https://mysku.ru/blog/russia-stores/30477.html
- https://www.xjtag.com/ru/about-jtag/what-is-jtag/
Загрузка...
CH341A, USB-UART-конвертер и I2C/SPI-программатор за $5
Блог Алексея Воронина
Схема импульсного преобразователя SEPIC: два варианта выполнения
Блог Валерия Малько