Имеется китайский клон USB загрузочного кабеля, который был приобретен года два назад.
На корпусе имеется надпись DLC9. Данный кабель без замечаний работает со Spartan-3.

Со свежекупленным китом на Spartan-6 работать отказывается.

При это iMPACT корректно определяет тип чипа.
Но при попытке что-нибудь сделать (считать ID, например) выдает
ERROR:iMPACT:583 - '1': The idcode read from the device does not match the idcode in the bsdl File.
INFO:iMPACT:1578 - '1': Device IDCODE : 00001111111111111111111111111000

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

А китайцы в настоящее время продают кабели с названием DLC9G

Какая частота TCK? Понижать пробовали? Другие устройства кроме 6 спартана в цепочке есть? Vccaux в порядке? Что на TDO твороится? Как насчёт дребезга и борьбы с ним?
Вопросы, вопросы...

Частоту пробовал менять. Эффекта нет.
Других устройств нет в цепочке.
Vccaux по моим представлениям в порядке = 3.3V.
На TDO пачки импульсов.
Имеются резисторы на линиях со стороны платы программатора. Дребезга в первом приближение не наблюдал.

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

Сам кит тоже китайский. Насколько google смог перевести с китайского, производитель настоятельно не рекомендует
использовать неоригинальный JTAG кабель.

Попробуйте прочитать ID оригинальным кабелем. Раз и то, и то китайское, по крайней мере, станет ясно, проблема в кабеле или в ките.

Эх, если бы он еще был...

Китайские кабеля работают и с шестым виртексом и с шестым спартаном. И родные кабеля тоже с ними работают.

Спасибо! Похоже в чем-то другом дело.

Да, действительно, странное поведение. Процедура энумерации JTAG цепочки проходит нормально (раз уж, как вы говорите, чип определяется корректно и рисуется цепочка), и на этом этапе IDCODE iMPACT'у нравится. А при попытке сделать почти то же самое, но слегка по-другому - уже нет. Я правильно понял ситуацию?

А другие действия (LOAD, например) -он тоже завершает с такими сообщениями?

Если да, и этот кабель 100% работает с другими платами, то придется все-таки проблему немного в iMPACT'овском JTAG Debugger'е поисследовать. Вручную тот самый IDCODE вычитать (это несложно, могу подсказать действия, если надо).

Кстати, а нет возможности на других платах перепроверится перед началом углубления в детали?

Вот полный лог из iMPACT.
В конце пытаюсь получить Device ID.
На все другие действия отвечает также.


Connecting to cable (Usb Port - USB21).
Checking cable driver.
Driver file xusbdfwu.sys found.
Driver version: src=1027, dest=1027.
Driver windrvr6.sys version = 10.2.1.0. WinDriver v10.21 Jungo © 1997 - 2010 Build Date: Aug 31 2010 x86_64 64bit SYS 14:14:44, version = 1021.
Cable PID = 0008.
Max current requested during enumeration is 280 mA.
Type = 0x0605.
Cable Type = 3, Revision = 0.
Setting cable speed to 6 MHz.
Cable connection established.
Firmware version = 1027.
File version of D:/Xilinx/13.4/ISE_DS/ISE/data/xusbdfwu.hex = 1100.
Firmware hex file version = 1100.
Downloading D:/Xilinx/13.4/ISE_DS/ISE/data/xusbdfwu.hex.
Downloaded firmware version = 1100.
PLD file version = 0012h.
PLD version = 0012h.
PROGRESS_END - End Operation.
Elapsed time = 0 sec.
Type = 0x0605.
ESN not available for this cable.
Attempting to identify devices in the boundary-scan chain configuration...
INFO:iMPACT - Current time: 6/21/2013 00:36:45
// *** BATCH CMD : Identify -inferir
PROGRESS_START - Starting Operation.
Identifying chain contents...'0': : Manufacturer's ID = Xilinx xc6slx16, Version : 4
INFO:iMPACT:1777 -
Reading D:/Xilinx/13.4/ISE_DS/ISE/spartan6/data/xc6slx16.bsd...
INFO:iMPACT:501 - '1': Added Device xc6slx16 successfully.
----------------------------------------------------------------------
----------------------------------------------------------------------
done.
PROGRESS_END - End Operation.
Elapsed time = 0 sec.
// *** BATCH CMD : identifyMPM
INFO:iMPACT - Current time: 6/21/2013 00:37:25
// *** BATCH CMD : ReadIdcode -p 1
INFO:iMPACT:583 - '1': The idcode read from the device does not match the idcode in the bsdl File.
INFO:iMPACT:1578 - '1': Device IDCODE : 00001111111111111111111111111110
INFO:iMPACT:1579 - '1': Expected IDCODE: 00000100000000000010000010010011



Вот лог при попытке сделать Chain Integrity Test


Maximum TCK operating frequency for this device chain: 25000000.
Validating chain...
INFO:iMPACT:1206 - Instruction Capture = '111111110101'
INFO:iMPACT:1207 - Expected Capture = '101010XXXX01'
INFO:iMPACT:2130 - Boundary-scan chain test failed . Please check tdi->tdo connection between the cable and device:'1' ( 'xc6slx16').
A problem may exist in the hardware configuration.
Check that the cable, scan chain, and power connections are intact,
that the specified scan chain configuration matches the actual hardware, and
that the power supply is adequate and delivering the correct voltage.



На других имеющихся платах пока, к сожалению, пока нет возможности проверить. У меня это хобби и со временем туго на данный момент.

Буду признателен, если подскажите, как читать IDCODE вручную.

Он у вас не прочел ID, ни в первый раз ни во второй. Проверяйте подключение JTAG. Возможно уровни напряжений на JTAG не соответствуют FPGA

На основании чего он тогда определяет тип чипа?

iMPACT предоставляет удобное средство для отладки с осциллоскопом:
<iMPACT Menu> :: Debug -> IDCODE Looping...

Дешево и сердито, особенно если не очень пока знаком с JTAG. Можно ввести количество циклов повторения IDCODE вычитывания. И спокойно изучать уровни и переключения на осцилле, сравнивать с ожидаемым (он в логе вроде бы фигурировал).

Если этого будет недостаточно для понимания / удобной отладки, тогда перейдем к ручному управлению JTAG сигналами - он тоже в iMPACT'е есть.

Действительно, в первый раз ID он похоже прочел (если конечно у него scan chain не сохранился от предыдущих запусков)
А вот судя по тому, что он прочел во второй раз - у него что то закончилось Зациклите чтение IDCode и посмотрите осцилографом

Не сразу обратил внимание: у вас проблемы начинаются при переключении JTAG clock на 25 МГц, а первоначальная энумерация происходит на 6 MHz. Это хорошо все объясняет. Проверьте сами :




Проверьте, что у вас выставлено для кабеля:
<iMPACT Menu> :: Output -> Cable Setup...

Для верности поставьте 1 МГц, а то и 100 кГц, и попробуйте...

Эта фраза указывает только на то, что максимальная частота для JTAG 25 МГц. Я конечно не знаю, но не факт, что он её переключает.
В настройках JTAG максимальная частота, которая может быть выбрана, 12 МГц. Пробовал понижать. Эффекта не было.


IDCODE Looping - хорошая идея. Надо будет попробовать.

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

Есть ли какие-то новости? Или это конструкция выходного дня, и спрашиваю рановато?

Была примерная проблема, с оригинальным программатором, правда в Linux. Переодически преставал программировать, причем цепочку то строил, то нет. Проблема была с драйвером.

А в BSDL-файле нет случайно раздела compliance pattern? C текстом, аналогичным нижеприведенному? (взял из первого попавшегося файла)

-- Compliance-Enable Description

attribute COMPLIANCE_PATTERNS of XC6VLX365T_FF1759 : entity is
"(PROGRAM_B, HSWAPEN) (10)";

Если "да", то для корректной работы JTAG-автомата необходимо эти условия соблюсти, т.е. произвести соответствующие переключения цепей, подходящих к данным пинам.

Действительно, конструкция выходного дня.
Снял осциллограммы. Но интерпретировать их пока не могу.
На картинках цикл считывания ID в разных временных масштабах.
Желтая линий - клоки TCK, голубая - TDI, красная - TDO

На последней картинке самое начало цикла обмена. Видно, что TDO до некоторого времени в третьем состоянии, потом там появляются данные, потом снова уходит в третье состояние.

Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла



Честно говоря, не очень понимаю, что все это значит. Тем не менее - спасибо - буду разбираться.

Это уже какой-то материал. Правда, без waveform'ы TMS разбираться будет плохо, и останется приличный процент гадания на кофейной гуще, но можно попробовать. Однако, если есть возможность снять то же самое, но с TMS,- было бы очень здорово (можно за счет замены TDI линии наTMS - что выдает на TDI iMPACT, мы уже видим).

Было бы здорово еще поподробнее рассмотреть во времени (растянуть по времени) зависимости между TCK, TDI, TDO, TMS (по фронтам или спадам драйвится - сейчас непонятно).

Кстати, а какой масштаб по оси X (временной)? Интересно в свете проверки рабочих частот TCK.

TMS досниму.

На второй картинке можно разглядеть, что по спадам драйвится.
Насколько я вижу.

На 2-ой и 4-ой картинке 2мкс/дел.

Клок был 3 МГц. Так и получается.

Проверил работу iMPACT'а у себя с моделированием неисправностей типа "нет соединения". Для отладки продуктивнее оказалось использовать функционал <iMPACT Menu> :: Debug -> Chain Integrity Test (что неудивительно, в общем-то, :-) для такой ситуации). Разобрался, что iMPACT тут делает (ничего хитрого, могу изложить подробнее, если надо).

В общем, итог такой. Если все JTAG сигналы от кабеля к разъему на плате, кроме TDI, имеют хороший контакт (TDI - no connect), то наблюдается поведение, аналогичное вашему случаю:


И это хорошо объясняет, почему цепочка в самом начале энумерируется, а при попытке выполнить иную задачу все накрывается. Поскольку TCK,TDO и TMS сигналы подключены хорошо, то : 1) переключения в машине состояний TAP'а проходят корректно (TCK, TMS); 2) соответственно, перевод TAP FSM в состояние Test-Logic-Reset и загрузка "инструкции по умолчанию" - IDCODE - тоже проходит нормально; 3) выдвигание содержимого всех IDCODE регистров JTAG-цепочки тоже идет хорошо (TDO предполагаем работающим). А вот биты, которые вдвигаются через TDI и потом ожидаются, в конце концов, на выходе из TDO,- вот они теряются. Вместо них вдвигаются 1-цы. Что мы и видим в логе, и что служит причиной ругани iMPACT'а. Зеленым цветом я подкрасил выдвигаемое в ходе Integrity Test'а защелкнутое содержимое IR'а, а красным - то, что вдвигалось по TDI со стороны кабеля и отвечающие им реальные биты на TDO. И понятно, почему невозможно вдвинуть какую-нибудь JTAG инструкцию со стороны кабеля, даже ту же IDCODE для выполнения IDCODE looping'а (TDI не работает, как положено).

Браво! В точку.
Виноватым оказался переходник, который раньше никогда не использовался. Не был должным образом пропаен контакт TDI (третий контакт слева на фото).
Теперь все работает. Осциллографом смотрел до этого переходника.

Нажмите для просмотра прикрепленного файла

Рад, что помогло.

Кстати, китайцы, похоже, еще кое на чем сэкономили. Судя по осциллограмме, на TDO отчетливо видно z-state, а хорошие люди делают pull-up на TDO (4.7 - 10 кОм), поскольку чей-то выход - он же ведь еще и чей-то вход .... и негоже, чтобы он болтался в воздухе.