Как определяется количество микросхем, объединенных в JTAG цепочку? Как я понял, заранее этого неизвестно, и это нужно как то определять. Какой либо командой сделать это не получится, ибо не известно кол-во микросхем в цепи и кол-во граничных ячеек в каждой их них, для того чтобы команды были направлены по адресу.
Надо ли для этого знать тип микросхем? Для того чтобы узнать тип микросхемы достаточно ли её маркировки или необходим идентификационный номер (IDCODE)?
Ломаю голову...
Заранее признателен за помощь.

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

Могу предложить мои статьи и открытый проект.
Удачи!

1)Документации чего? Стандарта 1149?
2) если вы имели ввиду тему "Отладочные средства на основе ARM.", то ваших постов со ссылками там нет, тем более месячной давности.



статьи бы почитал...

Учимся пользоваться поиском по форуму. Запускаем поиск JTAG и автора zltigo
И... первая ссылка.

Не надо считать меня за идиота, чтобы учить юзать поиск. Вместо этого лучше бы ссылку кинули. А первым постом, и даже вторым, на запрос "Jtag zltigo" сообщение со ссылкой не выдает.

Поверьте, я проверил. Поиск по форуму Вам еще пригодиться, посему учитесь. Удачи!

soply? ok

Итак начинаем учиться поиску на форуме:
1) Жмем поиск, вводим данные:

2)Поиск завершен, смотрим:

wtf? oO

Разговор шел о теме и наводка давалась на ТЕМУ, посему и искать надо в темах, а не сообщениях:
'результаты в виде тем'. В теме по первой (теперь, уже после появления этой темы, естественно второй)
ссылке есть пост с документом.

http://electronix.ru/forum/index.php?act=S...p;highlite=Jtag

Извините меня, но искать иголку в стоге сена, тобишь какой то пост со ссылкой в здоровой теме занятие не для человека, первый раз залезшего на этот форум. И если уж грешить на ПОИСК, то придя на этот форум с назначением "найти чё нить по JTAG", ты в поиск вводишь, естесственно, "JTAG". Далее смотришь темы по нему, именно по житагу, а не по настройке блаблабла. Далее, не удовлетворившись этим, ищешь сообщения по житагу. В Вашем сообщении со ссылкой ни слова по Житагу нет. Поэтому она мимоходом пролетает сквозь массовый поток необходимой информации. А просматривать ВСЕ сообщения и темы, где только что либо упоминается о житаге - это ерунда.
Гораздо более проще и эффективнее зарегаться на форуме, запостить сообщение, и уже знающие люди, которые как рыба в воде здесь, уж если не ткнут пальцем куда залезть на форуме, то хотя бы дадут кучу ссылок на интересующую тему.

По сабжу : данный документ мною был принят к ознакомлению уже давно, поэтому новым это для меня не стало. Ответа на мой вопрос в нем нету, хотя есть куча другой полезной информации об интерфейсе. Кстати, 150 пдфник тоже по джитагу.

Вопрос остаётся открытым, хотя статьи iosifk, я думаю, дадут мне ответ.

Искренне желаю Вам скорейшего достижения состояния 'рыбы в воде' и главное пути к этому состоянию не растерять желания многократно и подробно отвечать каждому, который дал себе труд только зарегистрироваться на форуме.

Увы, есть - описан интерфейс и базовые команды. Осталось чуть-чуть подумать и ... послать команду.

ок


К устройству из Х микросхем У,Z,C... маркировок послать команду неизвестной длины и содержания.
Тему клоуз.
...Ушел доводиться до состояния рыбы в воде.

Вроде как шаманство это - из известных способов считается, что длина data register обычно 32 бита, т.е. для неизвестного chain'a можно вычислить кол. микросхем в цепи и их _общую_ длину IR, но не зная длины конкретного IR конкретной микросхемы ничего реального с данной цепью сделать нельзя.

По аналогии с шуткой 90-60-90 это не размеры, а номер телефона, могу сказать, что 32 бита это не длина регистра данных (она у каждого чипа своя и может быть извлечена из файла BSDL), а фиксированная длина поля ID регистра. Такие программы как XILINX iMPACT, ALTERA QUARTUS, LATTICE ispVM умеют определять длину и количество элементов в цепочке а также вычитывать ID CODES.

С каких это пор инструкция IDCODE стала одинаковая для всех чипов ?

Посмотрите внимательнее на состотяние Test-Logic-Reset

Сэр, читайте внимательней посты. Не инструкция одинаковая, а длина поля.

Оно-то верно, в случае если этот регистр ID есть Кусочек из стандарта :
...
Test-Logic-Reset

The test logic is disabled so that normal operation of the on-chip system logic (i.e., in response to stimuli
received through the system pins only) can continue unhindered. This is achieved by initializing the instruc-
tion register to contain the IDCODE instruction or, if the optional device identification register is not pro-
vided, the BYPASS instruction (see 7.2). No matter what the original state of the controller, it will enter Test-
Logic-Reset when TMS is held high for at least five rising edges of TCK. The controller remains in this state
while TMS is high.
...

Совершенно верно. Но, редкий чип с JTAG не содержит этого регистра.

Я буквально на днях закончил прочтение IEEE 1149.1, и не возьму в толк, отчего возник спор вокруг того, что достаточно ясно описано в стандарте. Чипы, поддерживающие JTAG, обязаны, как минимум, иметь на борту BYPASS register. Они также могут иметь опциональный ID регистр. При переходе в состояние Test-Logic-Reset (тем или иным способом) таковой чип обязан подключить между TDI и TDO либо BYPASS (если нету IDCODE), либо ID (если таковой есть, то именно его). BYPASS всегда инициализируется 0, а ID в 2-х младших битах обязан иметь pattern "01". Длина ID регистра известна (32 бита) и зафиксирована стандартом. Если добавить сюда еще необходимость начинать ВДВИГАЕМУЮ битовую последовательность зарезервированным fake-ID кодом ("xxxxx000011111111" <- lsb), то мы получаем все возможности для того, чтобы:
1) определять начало и конец "отклика" JTAG-цепочки;
2) отделять друг от друга последовательности, соответствующие BYPASS и ID регистрам;
3) соотвтественно, определять место в цепочке соответствующих чипов с BYPASS/ID и вести их учет.

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

Не совсем так - мне буквально недавно приходилось решать подобную задачу - имелся чип-микросборка с неизвестным числом последовательно "оцепоченных" TAP-ов , один из которых был достоверно ARM7TDMI-S. По ID-регистру выяснить ничего не получится - код команды IDCODE не стандартизован, и длина IR у всех девайсов разная. Но - BYPASS вроде определен в стандарте как все единицы. Вот на это и следует опереться:
1) грузим в цепочку IR-ов единички в избыточном количестве
2) определяем количество регистров BYPASS и соответственно количество TAP-ов
3) далее следует разбить цепочку IR на отдельные элементы - тут в помощь тот факт, что при записи IR он инициализируется в b'01. Ищем единички в отклике после загрузки BYPASS и выясняем границы IR-отдельных TAP-ов. Ну а потом уже выцепляем нужный TAP.

Вот вы говорите: "1) грузим в цепочку IR-ов единички в избыточном количестве". Описанная мной метода (на авторство, ессно, не претендую - уши растут из стандарта :-)), как раз и позволяет не гадать, не загружать единички в избыточном кол-ве (а кстати, сколько это - избыточное количество для конкретно взятой серьезной цепочки?), а точно определить кол-во TAP'ов в цепи. Прочитайте внимательнее.

В результате описанной процедуры мы имеем пока описание JTAG-chain'а в виде последовательности TAP'ов, каждый из которых представлен либо 1) BYPASS rg (в свою очередь, представлен одиночным "0" в выходной последовательности), либо 2) ID rg (представлен 32-битовым кодом, младшие 2 бита которого по стандарту д.б. "01"). Теперь для тех TAP'ов, для которых известен ID, можно определить производителя и модель чипа. Для тех же, которые ID не имеют - придется все же провести небольшой reverse engineering для сопоставления конкретного чипа (с конкретной маркировкой ;-)) конкретному TAP'у в цепочке. Но, сдается мне, что все более-менее современные чипы ID-регистр содержат, так что к последнему варианту вряд ли придется прибегать.

Ну, а коль скоро мы сопоставили каждому TAP'у производителя и модель чипа, можно доставать из Web'а соответствующие bsd-файлы, в которых описана масса другого интересного: и длина регистра команд, и коды команд (по крайней мере, public-команд), и полное описание всего boundary scan регистра, и многое другое. А дальше - все зависит от конечной цели...

Да, согласен, я упустил из вида что при Test-Logic-Reset идет инициализация на такую цепочку регистров. (При попытке самостоятельно настроить такую цепочку моим методом я наткнулся на проблему "неизвестен код команды IDCODE", пришлось решать задачу перебором). Любопытный факт, попробую такой автоопределитель добавить в свои JTAG-утилиты.

Как говорится - случай классический - RTFM Рад, если смог чем-то помочь.