Цитата(Raven @ Jun 9 2016, 15:34)
Я, признаться, пока на внутренности XDS100 не смотрел. Если они на FT2232H - тем лучше.
Стандартная плата ft2232h - тоже хорошо, будет дублером для перепроверок. Если на ней есть header'ные контакты - то соединения можно будет делать и без паяльника, с помощью готовых оконцованных проводочков. С STM Discovery я пока, как ни странно, дела не имел, и поэтому для меня он в качестве инструмента пока отодвигается в конец списка. А вот если для вас он - старый добрый друг, то вполне может сгодится на каком-то этапе (с микроконтроллером какие-то итерации исследований/тестов могут быть быстрее).
Ну, я не совсем электронщик - так что друг он не старый. Но проводки есть. Разве что с платой ezdsp5502 они бесполезны, т.к. в отличие от STM Техас не предусмотрели возможность подключения внешнего отладчика, только впаянный. А с платой 5509a я не могу так свободно экспериментировать: только с имеющимся xds100v2-кабелем.
Цитата(Raven @ Jun 9 2016, 15:34)
Взглянул на оба BSDL-файла. Очень интересно. Факты таковы:
1) У 5502 и 5509, похоже, принципиально разный интерфейс к OCD-функционалу. 5502 предполагает работу с использованием "длинного" 38-битового IR, а 5509 выглядит в этой части более похожим на нынешний OCD-мейнстрим со сравнительно "коротким" IR (у 5509 - 6 бит).
Хочется верить, что факты, а не ещё не исправленные баги, как:
Цитата
5502:
BSDL Revision : 1.1 - Changed Inst length from 6 to 38 bits.
И, кстати, не смотря на 38 бит, всё равно Edmundo обнаружил, что слать надо 54, а, значит, и устанавливать irlen в 54.
Цитата(Raven @ Jun 9 2016, 15:34)
2) 5502, как можно догадаться по номеру, древнее 5509, и НЕ ПОДДЕРЖИВАЕТ IDCODE инструкцию (это из BSDL видно). Давненько такое в мои руки не попадало
Соответственно, автоматические процедуры распознавания устройств в JTAG-цепочке будут упираться лбом в 5502. Что потребует какого-то ручного разъяснения для них, кто есть кто. 5509 поддерживает IDCODE (0x0805002F).
Как-то я этим номерам не очень доверяю, кто из них древнее. Хотя IDCODE и опциональна, но всё равно не верится, чтобы она была не реализована. Это же просто беспрецедентно за всю историю развития UrJTAG и OpenOCD!
Цитата(Raven @ Jun 9 2016, 15:34)
3) Чтобы их JTAG-пины подключились к TAP'у и заработали именно в качестве JTAG-интерфейса (а не обслуживали factory test mode), нужно, чтобы в момент положительного фронта TRSTn (т.е., в момент выхода из Test Reset) на пинах EMU0 и EMU1 были определенные уровни: 0b11 для 5502, и 0b00 для 5509. Возможно, на плате все уже для этого сделано и намертво притянуто к нужным уровням, но проверить не помешает (если будут проблемы).
Так для отладки и для boundary scan разные условия для этих пинов? И т.к. xds100v2 предназначен в первую очередь для отладки, не окажется, что там пины намертво так притянуты, что нельзя выбрать нужный для скана режим? Вот проверить все эти соответствия на схеме с описаниями и таймингами и не запутаться для меня сложновато. Надеюсь, к ним есть программный доступ через libftdi.
Цитата(Raven @ Jun 9 2016, 15:34)
Понял. Я буду начинать с CygWin'а. Кстати, вы собирали HEAD или TAG_0-10-0?
TAG_0-10-0 - это, наверное, релиз 0.10, вышедший 7 лет назад. А HEAD - это только указатель. Собирал я git master (основная ветка, где, как правило, ведётся разработка). Сам UrJTAG разрабатывается в svn, а git - это только зеркало. Поэтому в логе можно видеть текущую svn-ревизию (git-svn-id: ... trunk@2052 ...):
Код
$ git log -1
commit bac6b34d8e278df25b178ea929d2c41ba6a146e5
Author: Mike Frysinger <vapier@gentoo.org>
Date: Sun Oct 11 04:57:45 2015 +0000
ignore .dirstamp files
git-svn-id: svn://svn.code.sf.net/p/urjtag/svn/trunk@2052 b68d4a1b-bc3d-0410-92ed-d4ac073336b7
Цитата(gagel @ Jun 10 2016, 02:45)
Надеюсь, к ним есть программный доступ через libftdi.
Так, глянул на ezdsp5502_Schematics_RevC.pdf. EMU0 и EMU1 пулапнуты. Значит, TAP и для дебага, и для boundary scan - один и тот же. И значит, нет доступа только к factory test, что и не нужно. Да и с libftdi, значит, меньше ошибок будет.
А вот для 5509a - требования с точностью до наоборот: пины должны быть заземлены для boundary scan.
Чтобы не запутаться:
Цитата
5502
============
EMU0 (I/O/Z)
-----
Emulator 0 pin. When nTRST is driven low, EMU0 must be high for activation of the
nOFF condition. When nTRST is driven high, EMU0 is used as an interrupt to or from
the emulator system and is defined as I/O by way of the IEEE standard 1149.1 scan
system.
The EMU0 and EMU1/nOFF pins must be pulled up when an emulator is not
connected. Internal pullups have been included for the purpose. If the user chooses
to disable these pullups through the XBCR, external pullup resistors must be added
to these two pins.
EMU1/nOFF (I/O/Z)
-----
Emulator 1 pin/disable all outputs. When nTRST is driven high, EMU1/nOFF is used
as an interrupt to or from the emulator system and is defined as I/O by way of IEEE
standard 1149.1 scan system. When nTRST is driven low, EMU1/nOFF is configured
as nOFF. The EMU1/nOFF signal, when active (low), puts all output drivers into the
high-impedance state. Note that nOFF is used exclusively for testing and emulation
purposes (not for multiprocessing applications). Therefore, for the nOFF condition, the
following apply:
• nTRST = low,
• EMU0 = high,
• EMU1/nOFF = low
The EMU0 and EMU1/nOFF pins must be pulled up when an emulator is not
connected. Internal pullups have been included for the purpose. If the user chooses
to disable these pullups through the XBCR, external pullup resistors must be added
to these two pins.
Цитата
5509a
===========
EMU0 (I/O/Z)
-----
Emulator 0 pin. When nTRST is driven low, EMU0 must be high for
activation of the nOFF condition. When nTRST is driven high, EMU0 is used
as an interrupt to or from the emulator system and is defined as I/O by way
of the IEEE standard 1149.1 scan system.
EMU1/nOFF (I/O/Z)
-----
Emulator 1 pin/disable all outputs. When nTRST is driven high, EMU1/nOFF
is used as an interrupt to or from the emulator system and is defined as I/O
by way of IEEE standard 1149.1 scan system. When nTRST is driven low,
EMU1/nOFF is configured as nOFF. The EMU1/nOFF signal, when
active-low, puts all output drivers into the high-impedance state. Note that
nOFF is used exclusively for testing and emulation purposes (not for
multiprocessing applications). Therefore, for the nOFF condition, the
following apply: nTRST = low, EMU0 = high, EMU1/nOFF = low
Интересно, там ещё и прерывания есть.
Кстати, для сборки UrJTAG нужно иметь (среди прочих зависимостей) libusb-1.0 и libftdi (или 0.20 или 1.x). Я пока пробую с 0.20.
Да перенесут, ежели сочтут 
(для эмулятора TMS, TCK, TDI, TRST -- выходы, TDO, TCK_RET-входы; EMU0 и EMU1 не используются, но должны быть в "1").
А то как бы я вообще этим вопросом заинтересовался: есть ещё какие-то IDE для c55x?
Да и процессоры сейчас пошли сплошь многоядерные, а как там производится эмуляция -- тёмный лес для меня. 