| |
|
  |
 Проблема с JTAG, Вместо цепочки в iMPACT unknow bypass |
|
|
|
|
 Dec 13 2013, 05:02
|
Участник
Группа: Участник
Сообщений: 41
Регистрация: 13-06-12
Из: Москва
Пользователь №: 72 296
|
Цитата(o_khavin @ Dec 13 2013, 00:52)  Ну извините. Ok  Попробовал добавить устройства вручную, при помощи bsdl файлов. Вот что получил при запуске Chain Integrity Test: INFO:iMPACT - Current time: 13.12.2013 8:59:20
// *** BATCH CMD : CheckIntegrity
Maximum TCK operating frequency for this device chain: 10000000.
Validating chain...
INFO:iMPACT:1209 - Testing for '0' at position 94.The Instruction capture of the device 3 does not match expected capture.
INFO:iMPACT:1206 - Instruction Capture = '1111111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111101'
INFO:iMPACT:1207 - Expected Capture = '10101010101010101010101010101010101010101010101010XXXXXXXXXXXXXX01XXXXXXXXXX
XXXX01XXXXXXXXXXXX011101'
INFO:iMPACT:2130 - Boundary-scan chain test failed . Please check tdi->tdo connection between device:'3' ( 'XC4VFX140') and device:'4' ( 'IDT72T18125').
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.Если запускать тест с одним только неизвестным устройством - импакт вылетает)) При попытке чтения DeviceID любого из добавленных вручную устройств получаю следующее: INFO:iMPACT - Current time: 13.12.2013 9:02:34
// *** BATCH CMD : ReadIdcode -p 3
INFO:iMPACT:583 - '3': The idcode read from the device does not match the idcode in the bsdl File.
INFO:iMPACT:1578 - '3': Device IDCODE : 00001111111111111111111111111111
INFO:iMPACT:1579 - '3': Expected IDCODE: 00000001111100010100000010010011Похоже, что физически цепочка жива, но какое-то из устройств явно валяет дурака.
Сообщение отредактировал proton17 - Dec 13 2013, 05:03
|
|
|
|
|
|
|
|
Dec 13 2013, 09:36
|
Местный
Группа: Свой
Сообщений: 491
Регистрация: 16-01-05
Из: Санкт-Петербург
Пользователь №: 1 987
|
Давайте разбираться. ?? Цепочка у вас такая (проверьте!): JTAG_CONNECTOR.TDI => DEV1 (XCF32) => DEV2 (Virtex-4 FX140) => DEV3 (IDT72T18125 (FIFO)) => JTAG_CONNECTOR.TDO ?? Смотрим лог. Немного смущает вот это: Цитата(proton17 @ Dec 13 2013, 09:02) Maximum TCK operating frequency for this device chain: 10000000. Если он здесь показывает реальную частоту, то надо бы понизить до предела вниз (50-100 кГц). Идем дальше. Цитата(proton17 @ Dec 13 2013, 09:02) INFO:iMPACT:1206 - Instruction Capture = '1111111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111101'
INFO:iMPACT:1207 - Expected Capture = '10101010101010101010101010101010101010101010101010XXXXXXXXXXXXXX01XXXXXXXXXX
XXXX01XXXXXXXXXXXX011101' 1) iMPACT считает, что у вас 4 устройства в цепочке, а не 3. Вернее, в цепочке 4 TAP'а. Нет ли устройств с 2 TAPами? Или вы что-то упустили? Цветовой код такой: CONN.TDI -> TAP1 -> TAP2 -> TAP3 -> TAP4 -> CONN.TDO, коричневым я выделил последовательность ( хвост), которую софт вдвигает. 2) Ближайшее к выходу устройство честно выдает содержимое своего 4-битового IR, зафиксированного при прохождении Capture-IR. От остальных, дальше по цепочке, отклика нет. В связи с чем iMPACT и предлагает проверить соединение TAP3 -> TAP4 Цитата(proton17 @ Dec 13 2013, 09:02) INFO:iMPACT:2130 - Boundary-scan chain test failed . Please check tdi->tdo connection between device:'3' ( 'XC4VFX140') and device:'4' ( 'IDT72T18125'). 3) После этого вполне закономерно, что IDCODE от TAP3 не будет получен: Цитата(proton17 @ Dec 13 2013, 09:02) INFO:iMPACT - Current time: 13.12.2013 9:02:34
// *** BATCH CMD : ReadIdcode -p 3
INFO:iMPACT:583 - '3': The idcode read from the device does not match the idcode in the bsdl File.
INFO:iMPACT:1578 - '3': Device IDCODE : 00001111111111111111111111111111
INFO:iMPACT:1579 - '3': Expected IDCODE: 00000001111100010100000010010011 Так что с выводом Цитата(proton17 @ Dec 13 2013, 09:02) Похоже, что физически цепочка жива, но какое-то из устройств явно валяет дурака. согласится не могу - явно есть проблема неконтакта (как минимум, одного).
|
|
|
|
|
|
|
|
Dec 13 2013, 10:21
|
Участник
Группа: Участник
Сообщений: 41
Регистрация: 13-06-12
Из: Москва
Пользователь №: 72 296
|
Устройства в цепочке 4 (два xcf32p). Цепочку я задавал вручную так как автоматом она не определялась. Частота пробника 750 кГц. Проблему локализовал путем сдирания маски с переходных отверстий под BGA ПЛИС и ФИФО: с ПЛИС не идет TDO, а висит на 3 вольтах, TCK, TMS, TDI до переходных отверстий ПЛИС доходят. Пока предполагаю отсутствие контакта одного из этих 3 сигналов и самой ИС. Думаю как найти еще какое-ть косвенное подтверждение этой теории перед тем как связываться с рентгеном. Закоротки между шариками нет - смотрели в микроскоп. Цитата(Raven @ Dec 13 2013, 13:36) ?? Цепочка у вас такая (проверьте!): JTAG_CONNECTOR.TDI => DEV1 (XCF32) => DEV2 (Virtex-4 FX140) => DEV3 (IDT72T18125 (FIFO)) => JTAG_CONNECTOR.TDO ?? Только XCF32P - 2 шт.
|
|
|
|
|
|
|
|
Dec 13 2013, 12:55
|
Участник
Группа: Участник
Сообщений: 41
Регистрация: 13-06-12
Из: Москва
Пользователь №: 72 296
|
Цитата(Raven @ Dec 13 2013, 16:48) С 4 TAPами разъяснилось.
Правильно ли я понял, что к переходным отверстиям с JTAG сигналами на FPGA вы доступ имеете? У каждой контактной площадке под BGA корпусом есть переходное отверстие, оно закрыто паяльной маской, но счистить ее не проблема...
|
|
|
|
|
|
|
|
Dec 13 2013, 14:45
|
Участник
Группа: Участник
Сообщений: 41
Регистрация: 13-06-12
Из: Москва
Пользователь №: 72 296
|
Цитата(Raven @ Dec 13 2013, 18:10) Тогда можно попробовать пролить больше света на то, что из TCK, TMS, TDI, TDO имеет контакт с чипом, а что - нет. До определенного предела, возможно. TDO точно имеет, на нем 3 вольта висит, а с остальными не понятно. На TMS/TCK вообще странные 0.8-1 вольта висят...
|
|
|
|
|
|
|
|
Dec 13 2013, 16:11
|
Местный
Группа: Свой
Сообщений: 491
Регистрация: 16-01-05
Из: Санкт-Петербург
Пользователь №: 1 987
|
Цитата(proton17 @ Dec 13 2013, 18:45) TDO точно имеет, на нем 3 вольта висит Пока непонятно. Без схемы не скажешь точно, но скорее всего, это говорит лишь о том, что у данной точки хорошая связь с дальнейшей цепью, к которой подключен pull-up. А есть ли контакт с пином - ? Цитата(proton17 @ Dec 13 2013, 18:45) На TMS/TCK вообще странные 0.8-1 вольта висят... Очень похоже на неподключенный, плавающий вход. Что, кстати, может добавить неопределенности поведения. Но вообще-то неплохо бы осциллоскопом взглянуть, чтобы убедится, что сигналы при IDCODE энумерации, например, не доходят сюда. Если подтвердится отсутствие контакта - можно проводочками пробросить TCK, TMS (т.к. они все равно в параллель разводятся по всем участникам цепочки). И проверить. Останутся TDI и TDO, но при рабочих TCK/TMS работоспособность TDO легко проверяется (должен выдать IDCODE после выхода из ресета и прохождения через DR-петлю). Останется только TDI. Такой вот маршрут локализации возможен.
|
|
|
|
|
|
|
|
Dec 13 2013, 19:38
|
Участник
Группа: Участник
Сообщений: 41
Регистрация: 13-06-12
Из: Москва
Пользователь №: 72 296
|
Цитата(Raven @ Dec 13 2013, 20:11) Пока непонятно. Без схемы не скажешь точно, но скорее всего, это говорит лишь о том, что у данной точки хорошая связь с дальнейшей цепью, к которой подключен pull-up. А есть ли контакт с пином - ?
Очень похоже на неподключенный, плавающий вход. Что, кстати, может добавить неопределенности поведения. Но вообще-то неплохо бы осциллоскопом взглянуть, чтобы убедится, что сигналы при IDCODE энумерации, например, не доходят сюда.
Если подтвердится отсутствие контакта - можно проводочками пробросить TCK, TMS (т.к. они все равно в параллель разводятся по всем участникам цепочки). И проверить. Останутся TDI и TDO, но при рабочих TCK/TMS работоспособность TDO легко проверяется (должен выдать IDCODE после выхода из ресета и прохождения через DR-петлю). Останется только TDI. Такой вот маршрут локализации возможен. Спасибо за советы  Я еще раз попробую более подробно описать схему и обобщить то, что сейчас удалось обнаружить: Xilinx JTAG connector (TDI) -> (TDI) XCF32P (TDO) -> (TDI) XCF32P (TDO) -> (TDI) VIRETX-4 FX140 (TDO) -> (TDI) IDT FIFO (TDO) -> (TDO) Xilinx JTAG connector TMS и TCK от разъема расходятся звездой. Утяжек ни на одном из сигналов нет. Суть проблемы состоит в том, что при инициализации цепочки при помощи Xilinx iMPACT обнаруживается только одно unknow device. Создание цепочки вручную не помогает. Логи при инициализации и тестах цепочки есть выше. Методом осцилотыка удалось обнаружить, что TCK и TMS приходят на все ИС (для ПЛИС и ФИФО это не совсем точно, так как в силу БГА-корпуса доступа к выводам нет, а только к переходным отверстиям рядом с площадками) и при отсутствии опроса имеют уровни ~0.8-1В (питание 3.3В) А вот TDI от разъема доходит только до ПЛИС, а на ее TDO в независимости от информации на входе стабильно висит 3.3В На выходе TDO ФИФО при опросе появляется некоторая ответная активность, как я понимаю это следствие появления TCK и TMS Из выше сказанного мне наиболее вероятным кажется вариант отсутствия контакта между какими-то сигналами JTAG-а и выводами ПЛИС в следствии непропайки. Имеется еще одна идентичная плата, но она вообще не запускалась в виду наличия КЗ между питанием ПЛИС (1.2В) и землей (( В понедельник буду искать причину кз и возможно удастся ее запустить и проверить JTAG там.
Сообщение отредактировал proton17 - Dec 13 2013, 19:42
|
|
|
|
|
|
|
|
Dec 13 2013, 20:26
|
Узкополосный широкополосник
Группа: Свой
Сообщений: 2 316
Регистрация: 13-12-04
Из: Moscow
Пользователь №: 1 462
|
Цитата(proton17 @ Dec 13 2013, 23:38) TMS и TCK от разъема расходятся звездой. Одна из стандартных ошибок при разводке JTAG. Многие думают, раз частоты низкие, можно разводить как угодно. А на практике, фронты сигналов остаются одинаково быстрыми при любой частоте, что приводит к отражениям, точнее к влиянию отражений. К этому следует добавить высокую чувствительность современных микросхем к пикосекундным импульсам. В итоге - на осциллографе все красиво, а цепочка не работает. На практике встречал ситуации, когда родным программатором Xilinx шьется без проблем, а через Digilent уже не видно, и дело, поверьте мне, совсем не в разном качестве программаторов. На будущее - сигналы TMS и TCK желательно разветвлять через буфера "один вход - несколько выходов", а сейчас остается только экспериментировать с навешиванием емкостей.
|
|
|
|
|
|
|
|
Dec 16 2013, 07:59
|
Узкополосный широкополосник
Группа: Свой
Сообщений: 2 316
Регистрация: 13-12-04
Из: Moscow
Пользователь №: 1 462
|
Цитата(proton17 @ Dec 16 2013, 11:36) Буфер убрали - все сходу заработало. Поздравляю. Добавлю краткую ремарку. Цитата(proton17 @ Dec 16 2013, 08:49) Дистанции не более 5 см Есть у меня модуль, состоящий из двух плат, стыкующихся между собой через один большой разъем. Общая структура такая: JTAG1->Плата1->Разъем->JTAG2->Плата2->ПЛИС->ПЗУ Вся цепочка идет строго последовательно, в рабочем режиме - через JTAG1, в режиме отладки - Плата2 отдельно через JTAG2. Плата1 только транслирует соответствующие линии. Общая длина линий по Плата1 составляет ~3 см, по Плата2 - ~5 см, Разъем и JTAG2 расположены вплотную друг к другу. Как уже догадываетесь, ПЛИС и ПЗУ не программируются только в одном случае - через JTAG2, когда две платы состыкованы между собой. Т.е. длины линий в 3 см вполне достаточно, чтобы сделать цепочку не работающей.
|
|
|
|
|
|
|
|
Dec 16 2013, 14:57
|
Местный
Группа: Свой
Сообщений: 491
Регистрация: 16-01-05
Из: Санкт-Петербург
Пользователь №: 1 987
|
Цитата(rloc @ Dec 14 2013, 00:26) ...Многие думают, раз частоты низкие, можно разводить как угодно. А на практике, фронты сигналов остаются одинаково быстрыми при любой частоте, что приводит к отражениям, точнее к влиянию отражений. К этому следует добавить высокую чувствительность современных микросхем к пикосекундным импульсам. В итоге - на осциллографе все красиво, а цепочка не работает. С этим полностью согласен. Однако с отражениями, по идее, должны успешно справляться резисторы последовательного согласования, устанавливаемые у выходов-источников сигнала. И снижать уровень переотражений в нагрузку до приемлемого уровня (чтобы не было значимых 'сёдел' на фронтах, во всяком случае). Другое дело, что они не всегда имеют подходящее сопротивление. Цитата(rloc @ Dec 14 2013, 00:26) На будущее - сигналы TMS и TCK желательно разветвлять через буфера "один вход - несколько выходов", а сейчас остается только экспериментировать с навешиванием емкостей. Такой подход (с буферизацией 1:N) - это, конечно, правильно, и точно должно убивать проблему на корню, но и дороговато. С другой стороны, почти вся схемотехника evaluation boards, с которыми имел дело, не имеет подобного. Причем, во всех этих случаях соображения экономии совершенно разработчиков не обременяли (учитывая цену плат и их основную задачу).
|
|
|
|
|
|
|
|
Dec 17 2013, 08:26
|
Участник
Группа: Участник
Сообщений: 21
Регистрация: 19-11-05
Пользователь №: 11 087
|
Здравствуйте. В продолжении темы не работы JTAGa. Принесли родной Platform Cable USB. Решил подключить его к плате. До этого работа с платой происходила через Parallel Cable III. Все нормально работало. С Platform Cable USB выдает вот такой лог: Код GUI --- Auto connect to cable...
// *** BATCH CMD : setCable -port auto
INFO:iMPACT - Digilent Plugin: Plugin Version: 2.4.4
INFO:iMPACT - Digilent Plugin: no JTAG device was found.
AutoDetecting cable. Please wait.
*** WARNING ***: When port is set to auto detect mode, cable speed is set to default 6 MHz regardless of explicit arguments supplied for setting the baud rates
PROGRESS_START - Starting Operation.
Connecting to cable (Usb Port - USB21).
Checking cable driver.
Driver file xusb_xlp.sys found.
Driver version: src=1029, dest=1029.
Driver windrvr6.sys version = 10.2.1.0. WinDriver v10.21 Jungo (c) 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 74 mA.
Type = 0x0004.
Cable Type = 3, Revision = 0.
Setting cable speed to 6 MHz.
Cable connection established.
Firmware version = 1303.
File version of C:/Xilinx/14.7/ISE_DS/ISE/data/xusb_xlp.hex = 1303.
Firmware hex file version = 1303.
PLD file version = 0012h.
PLD version = 0012h.
PROGRESS_END - End Operation.
Elapsed time = 0 sec.
Type = 0x0004.
ESN option: 000011775B2701.
Attempting to identify devices in the boundary-scan chain configuration...
INFO:iMPACT - Current time: 17.12.2013 12:15:49
// *** BATCH CMD : Identify -inferir
PROGRESS_START - Starting Operation.
Identifying chain contents...done.
ERROR:iMPACT - 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.
PROGRESS_END - End Operation.
Elapsed time = 0 sec.
// *** BATCH CMD : identifyMPM Я тут для себя наметил несколько причин: 1. JTAG попросту подгорел но выходам-входам. 2. Не совместимость старого Platform Cable USB с Windows 7 64. 3. Не совместимость старого Platform Cable USB с последними версиями Xilinx ISE Design Suite.
Сообщение отредактировал Suho - Dec 17 2013, 08:27
|
|
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
