Доброе время суток. Возникла тупиковая ситуация с загрузкой по JTAG. Свои идеи закончились и без помощи не обойтись.
Использую XILINX Kintex-7 xc7k325t, плата своя. VIVADO 2015.3. Режим конфигурации по SPI FLASH. Подобная тема здесь обсуждалось,
но там JTAG работал. Есть в наличии совершенно другая плата, но с таким же кристаллом и там проблем нет. Правда плата не своя, но
это главное инструментарий рабочий. Сам проект выводит постоянный сигнал на светодиод, фактически пустышка. Питание проверял
осциллографом - претензий нет (пульсации менее 15мВ), выделенные конфигурационные контакты подключены верно, что проверял
ни один раз. В среде Vivado ПЛИС определяется правильно, визуально отображаются все питающие напряжения и температура, и тоже
верно. При включении питания стартует режим загрузки по SPI - сигнал такта из ПЛИС, процесс бесконечный, так как флеш пустая.
Начинаю загружать ПЛИС по JTAG, сам процесс загрузки идет без ошибок и в конце вижу сообщение о непонятной мне ошибке.



Сигнал DONE не поднимается (0,14В) - подтянут к 1,8В резистором 330Ом, до этого был 4,7кОм, но не помогло.
Сигнал INIT по окончании загрузки опускается в ноль.
Переключал скорость загрузки от 750кГц до 6МГц, результат один.

Ниже показаны значения регистров ПЛИС.










Что может быть не так?

Программатор фирменный? Если китайский, там могут быть чудеса...

Программатор родной, рабочий.
Не понимаю, что не так. Сигнал INIT падает в ноль и сигнализирует об ошибки конфигурации,
но знать бы о какой.

1. PROGRAM_B в каком состоянии и как подключен?

2. CFGBVS у вас в нуле. Стало бы VCCO <= 1.8в. Так ли это?

3. Уровни JTAG сигналов тоже должны быть не выше напряжения питания VCCO, т.е. 1.8в, если п.2 - правда.

4. Куда ещё подключается DONE, кроме как к подтяжке?

Неплохо было бы выложить часть схемы связанной с блоком конфигурации.

Включение загрузки ПЛИС

1. Что-то мне подсказывает, что в PROG_B проблема. Стоит проверить то, как ведёт себя супервизор в процессе конфигурации ПЛИС, если по каким-то причинам PROG_B в нуле или дёргается в процессе конфигурации, то битстрим не зальётся нормально.

2. DONE на затвор mosfet-а можно спокойно подключать. Проблемы могли были бы быть с биполярным транзистором.

P.S. Извините, но изображение мелковато. Про питание банков понял, но красный текст на микросхеме прочитать не могу даже с оригинала. Что-то там Flash SPI...

Красным в поле ПЛИС указаны значения М0-М2 - для себя. Линия PROG была первой под подозрением - выпаял супервизор, итог тотже. Смотрел осциллографом при загрузке, единица стоит честная все время загрузки. Дополнительно закарачивал PROG на землю, INIT следом отрабатывает чётко за ним. Мне неясно какую информацию
несёт переход INIT в ноль по окончании загрузки по JTAG. Ведь это что-то да значит.

1. Если INIT_B никто не дёргает (судя по схеме там только подтяжка), то вообще говоря спад указывает на CRC errror:

UG470:
>> A falling INIT_B signal during configuration can indicate a CRC error in the bitstream seen by the FPGA device.

А что, если у вас по JTAG идут некорректные данные? У вас там какой-то хитрый преобразователь уровней стоит D52. Это что за микросхема? До и после неё нет ничего подозрительного? Она вообще штатно работает?

2. Вы говорили, что по JTAG ПЛИС корректно определяется. А, например, тот же XADC открыть в Vivado и почитать температуру ПЛИСины можно?

3. Настройки .bit файла в среде смотрели? Может там что-то не так настроено?

1. Читал. Init показывает ошибку СRC, но бит ошибки в нуле (первый пост). Преобразователь стандартная логика, решение рабочее на более 200 плат, грешить на него не могу.
2. По jtag в XADC читается температура, напряжения, регистры конфигурации. Психанул и подключился jtag ПЛИС напрямую к загрузчику навесным монтажем, все тоже самое.
3. Настройки .bit файла стандартные, не изменял.

..попробуйте посмотреть питание ПЛИС непосредственно при загрузке с jtag-а, где нибудь непосредственно рядом с плисиной на каких-нить блокирующих конденсаторах.

Смотрел осциллографом в режиме ожидания все напряжения непосредственно на емкостях под ПЛИС - проседания напряжения нет ни в процессе загрузки, ни
по ее окончании. Понимаю, что переход INIT в ноль сигнализирует об ошибке CRC, но бит BIT00_CRC_ERROR = 0 (первый пост). Наверняка за поиском глобальной
ошибки стоит какая-нибудь детская. Не нравится мне сигнал TDO - может так и должно быть,но если смотреть в XADC Vivado напряжения и температуру, то внутри пакетов
данных (проскакивает очень редко) не четкий переход нулей и единиц, а какая-то хрень в форме нарастающей экспоненты по длительности в несколько бит, но это НЕ мешает XADC корректно
отображать на экране считанные значения - провалов в данных нет, все ровно. При загрузке потока по JTAG описанной ситуации не вижу.

А вы эту осциллограмму с экспонентой можете показать?

Фото сделаю завтра.

Я бы убрал R146, выпаял и закоротил D51, D52, R147. После чего на Vref программирующего разъема подать 1,8В и пробовать. Если заработает - разбираться с D52.

Именно так и сделал, когда допекло. Резисторную сборку D52 выпаял и напрямую навесным монтажем подключил выводы ПЛИС на разъем программатора, на него же
подал опорные 1,8В и землю. Результат один в один. Вернул все взад. Бред какой-то.

..протрите всё ваткой со спиртом и пока не просохло попробуйте прошить - будет какой-нить эффект?
У меня как-то на спратане 3 глючил jtag из-за остатков флюса .

Проверьте PUDC_B.

Плату мыли в УЗ ванне.
PUDC_B в нуле, подтверждается битиком в регистре- первый пост

https://electronix.ru/forum/lofiversion/ind...hp/t139807.html

..вот эту тему читали? Может что общее.

Прочитал. Надо проверить.

Сделал несколько снимков поведения линии TDO при работе XADC VIVADO, условно считаю что вроде как и нормально.





Однако периодически наблюдаю чешую, которая никак не сигнализируется в XADC, а данные температуры и напряжений отображаются
плавной ровной линией.













Форма нарастания близка к линейной и больше похожа на работу источника тока на емкость. При загрузке битового потока такого срама
не вижу или не замечаю, однако в конце пакетов есть также подозрительное поведение TDO.





Следствием чего может быть такое поведение TDO?

TCK звенит.
Ещё встречаются левые кинтексы, кто знает откуда они, выглядят как из вторсырья, и работают хуже.
Хотя не факт что дело в этом.

Припаял на линии провода длиной сантиметров по 10, меньше физически не могу, для подключения щупа осциллографа. Отсюда и видимый звон на линии TCK. Если извернуться и посмотреть щупом непосредственно на линии TCK, то звона нет, но небольшой конденсатор поставлю для очистки совести. Непонятно причина почему цифровая линия может так себя вести, как будто кто-то с кем-то борется.

Внешний вид корпуса ПЛИС визуально такой же, как и на другой рабочей плате.

Были проблемы с программированием V5 по JTAG. Либо неправильно определялась цепочка, либо в конце программирования происходила ошибка. Причина - звон на TCK, конденсатор в несколько пФ решил проблему. Также, я бы посоветовал попробовать подтянуть TDO к питанию.

А что в окрестностях этих странностей происходит с TMS? Видно, что TDO переходит в Z-состояние, но он может это делать только при покидании состояния Shift-DR - а на это влияет TMS. Если там в этих районах какие-то пички/импульсы/звон, то.... мысль понимаете, да?

Cкорее всего это фаза передачи данных, когда активен TDI, а не TDO. У TDO в этот момент отрабатывает подтягивающий резистор на емкостную нагрузку, отсюда и экспоненты в осциллограмме. Мне кажется, что это нормальное поведение. Посмотрел осциллографом у себя на артиксе. Вижу такие же экспоненты на TDO. Длина проводов JTAG 15-20см (USB HS2).

TDI и TDO "работают" одновременно, в одних и тех же состояниях TAP FSM : Shift-IR, Shift-DR. В остальных состояниях TDO = 'Z".

Поставил на TCK 10пФ, TDO подтянул к питанию - не помогло.



Посмотрел TMS - звона нет, переходы четкие.



Обнадежили. Хочется думать, что это нормальная работа линии TDO. Непонятно несоответствие опускания INIT в конце загрузки (семафор ошибки CRC) и в тоже
бит ошибки CRC регистра статуса в нуле. Логики не вижу.
Мои идеи закончились.

имхо.
для начала, в разрыв этих ваших 10см кабеля по всем сигнальным линиям поставить 10 Ом, с любой стороны, убрав текущие любые навешенные пикофарадные емкости.
если не заработает - пробовать вешать емкости со стороны отлаживаемой платы.

сигнал осциллографа у вас звенит скорее всего по причине плохой земли щупа. усаживайте на щуп земляную "пружинку", как здесь:

Фотку забыл:

Еще раз посмотрел на осциллограммы. Собственно, как я уже и говорил, в подобном поведении TDO нет криминала - как и положено по IEEE 1149.1, TDO находится в Z-состоянии при любых состояниях TAP FSM, кроме соотвествующих сдвигу инструкций/данных. Такое в работе с JTAG-устройствами происходит сплошь и рядом, так что ничего удивительного в картинках нет. Так же объясняется и то, почему при потоковой загрузке FPGA подобного не видно - переходы из указанных состояний сдвига данных здесь должны быть реже, и, что даже более важно - промежутки времени между состояниями Shift-DR очень коротки, и pull-up просто не успевает поднять экспоненту на заметный глазу уровень.

Точнее можно сказать, только рассматривая TCK, TMS и TDI/TDO совместно, да еще на каком-нибудь понятном тестовом прогоне (например, энумерация устройств в цепочке, или считывание IDCODE).

При отсутствии таких данных, я поставил бы пока все же на Signal Integrity проблему. Последовательно согласующие резисторы не хотите все же поставить возле драйверов линий? Да, и какая сейчас у вас частота TCK? Уменьшить радикально не пробовали - до 50-100 кГц? (прошу извинить, если где-то уже писали об этом - я все сообщения тотально не прочитывал).

Тоже склоняюсь к этой версии.


Со стороны ПЛИС стоит резисторная сборка по 10 Ом, ставил и 22 Ом. Вы предлагаете поставить со стороны JTAG загрузчика?



Пробовал на 750кГц и 6МГц. Как уменьшить частоты до 50-100 кГц не знаю, т.к. этим вопросом никогда не задавался.

Типовая проблема Signal Integrity на JTAG - звон TCK. Снижением частоты это не лечится, но щуп осциллографа должен был исправить картину.
Не исключено, что проблема не в JTAG, а глобальнее - например, источники проваливаются при попытке запуска конфигурации.

Я бы предложил вот что:
1. Радикально уменьшить объем битстрима - на проекте-пустышке включить компрессию битстрима. Шанс появления ошибки передачи данных намного снизится.
2. Попытаться поработать с флешкой через Vivado. Хотя бы просто сделать Blank Check - загрузится образ программатора или нет? Пробовать все варианты - Pull Up/Down/None.
3. Если по второму пункту ну никак - зашить флешку внешним программатором и посмотреть, будет ли ПЛИС конфигурироваться из нее. М.б. проблема глобальнее JTAG-а и ПЛИС вообще не конфигурится.

Провал напряжения в момент запуска конфигурации не подтвердился - этот вариант проверил одним из первых.



1. Проверю.
2. Чтобы работать с флеш через Vivsdo, надо сначала самой Vivado загрузить свой поток ПЛИС (образ программатора), что не проходит. Варианты с Pull Up/Down/None
проверял.
3. Загрузить флеш внешним программатором - не, так не получится, она с термападом и снять-установить как-то не радует. При включении питания вижу попытку
ПЛИС загрузиться с флеш - есть такт, сигнал CEn. Попытка продолжается до тех пор, пока не пытаюсь загрузиться по JTAG, при этом линия такта флеш и CEn подтягиваются
к постоянной единицы. ПЛИС верно отрабатывает режимы загрузки.

Попробую снизить максимально частоту TCK с установкой резисторной сборки большего номинала где-то 100-200 Ом - будет функция фильтрации сигналов.
Может кто знает - нет ли в Vivado опции проверки канала JTAG - прогнать данные в канале на предмет сбоев.

1. Резистор последовательного согласования ставится как можно ближе к источнику сигнала в линии. Со стороны внешнего разъема/кабеля для TDO я у вас вижу такой резистор (и надеюсь, он располагается непосредственно у пина, из которого он генерируется на этой стороне от level shifter'а). Номинал - обычно в диапазоне 22 .. 51 Ом, в зависимости от характеристического сопротивления линии. Что касается входов (TCK, TMS, TDI), то у нормальных кабелей-адаптеров согласующие резисторы должны быть внутри на этих линиях. Так ли это в вашем случае? Что за кабель у вас, кстати?

2. Но в вашем случае есть еще и участок от level shifter'а до FPGA, где level shifter является генератором для TCK, TMS, TDI. А резисторная сборка у вас монолитная. Спрашивается, к чему ближе она у вас стоит: к level shifter'у, или к FPGA? Другими словами, на чье последовательное согласование она работает - указанной троицы или TDO? И кстати - велик ли и замысловат ли путь распространения сигналов на этом участке (всех 4-х касается)? Хоть я бы предпочел поставить раздельные резисторы для этих сигналов с индивидуальным оптимальным расположением, в вашем варианте лучше бы им быть согласователями для TCK, TMS, TDI. А на самом деле? И наконец, last but not least, как говорят наши партнеры , что у вас за level shifter стоит?



Если наши проблемы связаны с TCK, а именно,- с его фронтами, их искажениями типа "седло" из-за отражений и т.п., то, как справедливо заметил Flood уменьшение частоты TCK картину не изменит (фронты-то останутся :-) в любом случае, только реже будут идти). Уменьшением частоты мы можем проверить, нет ли проблем типа "не успевает установиться TDI перед фронтом TCK". Пренебрегать этим не стоит, тем более что проверить можно быстро.



Только тогда выставляйте TCK на 750 кГц (или меньше, если разберетесь, как это сделать - я не подсказчик, т.к. с Xilinx давненько не работал). И возможно, достаточно будет ограничиться вариантами 33-51 Ом - т.к. 100-200 - это может оказаться чересчур.


В ISE, я точно помню, был какой-то функционал для отладки JTAG. Был какой-то Application Note на эту тему. С Vivado еще не имел случая познакомиться, но ожидал бы и в нем найти что-то для этого случая.

Есть ли новости?

Жду вторую плату. С этой подозрение на перегрев
при установке по бессвинцовому профилю.

Получил вторую плату. Работает как и задумывалось. По JTAGу загружается, из SPI грузится при включении питания.
На новой плате стоит ПЛИС выпуска конца 16-го года, на нерабочей 13-го, видимо что-то с ней изначально было не так.
К маркировке вопросов нет, смущает залежалость, как-бы ПЛИС ходовая и такой древней на правильных складах не должно
было остаться.
Всем ответившим спасибо.