Spartan-6 и китайский клон загрузочного кабеля Опции

[Pavel_I]

Имеется китайский клон 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

[Raven]

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

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

Вот лог при попытке сделать 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.

И это хорошо объясняет, почему цепочка в самом начале энумерируется, а при попытке выполнить иную задачу все накрывается. Поскольку 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 не работает, как положено).

[Pavel_I]

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

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

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