[Raven 11]

Идеальную картину я себе обрисовал некоторое время назад. Поддержка c55x не только в openocd, но и в gdb (иначе что толку от openocd?) и binutils(?). С одной стороны gcc умеет c6x и gdb тоже, но вот с c55x не сложилось. На этом идеал закончился, потому что реализовать поддержку в gdb хоть и можно (13 лет назад кто-то интересовался этим вопросом в списке рассылок gdb), но точно не в одиночку как хобби.

Поддержать новый CPU в GDB - это да, дело непростое... Но для обозримых времен, похоже, актуальнее будет обеспечить работу с CodeComposer'ом (если он работает с c55x).

 

Вообще, самым, наверное, ценным в этом проекте является reverse engineering API драйвера - можно просто другие готовые кабели приспосабливать для работы с TI DSP через JTAG.

 

Кстати, openocd пришлось бы перерабатывать: ведь здесь вместо нормального разделения команда по irscan, данные по drscan применяют исключительно irscan.

Тут нужно доисследовать. Разницу в подходе к использованию IR у Техаса я заметил (и тут не OOCD "виноват", а ARM и подавляющее большинство других чипмейкеров), но объем сложности в модификации OOCD -- для меня пока вопрос открытый.

 

Запустить в обособленном режиме через libftdi могу попробовать. Но это даст слишком мало: только читать/писать память и, может, старт/стоп (уже загруженной) программы. Без возможности загрузки программы, без точек останова, CIO printf, Log.printf DSPBIOS,..

Запустить что?

 

Кстати, что ещё было бы интересно (и просто?) - это попробовать с помощью самописной маленькой программки через boundary scan подёргать пин, на котором висит светодиодик. Но вот куда копать?

А вот для этого уже много сделано до нас ;-) Во-первых, есть удобные проприетарные программы с GUI, во-вторых, OpenOCD через самописные скрипты может это делать, и в-третьих, существует проект UrJTAG.

 

[gagel 0]

Поддержать новый CPU в GDB - это да, дело непростое... Но для обозримых времен, похоже, актуальнее будет обеспечить работу с CodeComposer'ом (если он работает с c55x).

Да, работает ;) А то как бы я вообще этим вопросом заинтересовался: есть ещё какие-то IDE для c55x?

 

Вообще, самым, наверное, ценным в этом проекте является reverse engineering API драйвера - можно просто другие готовые кабели приспосабливать для работы с TI DSP через JTAG.

Точно.

 

Тут нужно доисследовать. Разницу в подходе к использованию IR у Техаса я заметил (и тут не OOCD "виноват", а ARM и подавляющее большинство других чипмейкеров), но объем сложности в модификации OOCD -- для меня пока вопрос открытый.

Мне показалось, что как раз у Техаса отклонение от нормы: ведь они не используют DR. Или для чего DR придумали?

 

Запустить что?

Самописную мини-программку для демонстрации, что результаты реверса в принципе работают через libftdi и xds100 на c55x.

 

А вот для этого уже много сделано до нас ;-) Во-первых, есть удобные проприетарные программы с GUI, во-вторых, OpenOCD через самописные скрипты может это делать, и в-третьих, существует проект UrJTAG.

Проприетарные не интересуют в принципе. А есть примеры скриптов для OpenOCD? В UrJTAG последний значимый коммит был почти 2 года назад. Им ещё пользуются? И я так понимаю, что если мне нужно всего один пин дёргать, то всё равно нужно доставать BSDL-файлы? И не может так оказаться, что аналогично с IR/DR Техас по-другому реализовали доступ для boundary scan и OpenOCD снова не в состоянии помочь? Эх, мне бы просто информацию, какую команду в IR послать, какой формат для выбора пина и данных, и всё.

[Edmundo 0]

Прошу прощения за такое безответственное поведение с исходниками, надо сделать над собой волевое усилие, и выложить все, что есть, на github, хотя бы свалку для начала, а потом уже разобрать. Надо пошуршать по старым жёстким дискам.

 

Вообще заточить все это под GDB -- была у меня такая лихая идея. Но сложность её я не оценивал. А так да, можно было бы тогда отлаживать в прочих IDE, например в Qt Creator.

 

По драйверам. PTI_*, TRG_* -- это более низкий уровень взаимодествия с железом, и моему разуму он оказался не подвластен. Когда в своё время я обменивался своими мыслями с Сергеем Марковым aka SM, он как раз рекомендовал ломать протокол на более низком уровне, что бы не переписывать высокоуровневые драйвера под каждую платформу. В то время он уже перешёл на светлую сторону Силы под крыло Sauris, поэтому эта тема для него актуальность потеряла, у него уже был доступ к SEPK (или как он там называется). Я пошел-таки своим путем, что позволило мне добиться неплохих результатов по скорости обмена данными (на мой субъективный взгляд).

 

По эмуляции. Я экспериментировал с тремя семействами: C64хх (не плюс), C55xx, C28xx. Для них удалось реверсить содержание JTAG-цепочек таких распространённых операций как чтение/запись в память/регистры ядра, установка/снятие точек останова, запуск/останов программы и т.п. Не удалось до конца познать суть инициализационных цепочек, а также назначение всех разрядов регистра статуса (я о нем упоминал в статье).

 

По поводу "подёргать ножкой". Я в boundary scan не силён, для этого действительно есть специальные инструменты, BSDL-описания, в общем с эмуляцией граничное сканирование объединяет лишь одно -- физический интерфейс JTAG. В остальном это весьма разные вещи. По граничному сканированию рекомендую обратиться к знаниям ув. iosifk: http://iosifk.narod.ru/

Вы даже можете пообщаться с ним лично, ранее он бывал на этом форуме.

 

Ну а в остальном я готов проконсультировать в любых вопросах, на которые знаю/помню ответы. Правда род моей деятельности сменился, поэтому я сейчас от этого несколько далёк :laughing:

[gagel 0]

Так, BSDL-файлы есть. UrJTAG не знает XDS100v2. Нашёл патч, собрал UrJTAG. Но и он тоже не хочет работать с Техасом. Наверняка, пытается детектить чип по DR, а там - тишина. А как без успешного detect подсунуть ему инфу про чип и затем послать что-то вроде

instruction EXTEST
shift IR
set signal GPIO(6) out 1
shift DR
set signal GPIO(6) out 0
shift DR

?

 

Кстати, выходит, всё должно быть очень просто с boundary scan. Если бы тольке не этот IR<->DR.

 

О, здОрово, что вы зашли!

 

Прошу прощения за такое безответственное поведение с исходниками, надо сделать над собой волевое усилие, и выложить все, что есть, на github, хотя бы свалку для начала, а потом уже разобрать. Надо пошуршать по старым жёстким дискам.

Да это было давно, так что и обижаться нельзя. С github или аналогами было бы вообще прелесть!

 

Вообще заточить все это под GDB -- была у меня такая лихая идея. Но сложность её я не оценивал. А так да, можно было бы тогда отлаживать в прочих IDE, например в Qt Creator.

Эх, вот тогда была бы полная независимость.

 

По драйверам. PTI_*, TRG_* -- это более низкий уровень взаимодествия с железом, и моему разуму он оказался не подвластен. Когда в своё время я обменивался своими мыслями с Сергеем Марковым aka SM, он как раз рекомендовал ломать протокол на более низком уровне, что бы не переписывать высокоуровневые драйвера под каждую платформу. В то время он уже перешёл на светлую сторону Силы под крыло Sauris, поэтому эта тема для него актуальность потеряла, у него уже был доступ к SEPK (или как он там называется). Я пошел-таки своим путем, что позволило мне добиться неплохих результатов по скорости обмена данными (на мой субъективный взгляд).

Да, для вашего подхода, кажется, нужен как раз минимум действий. И раз не заглядывали в это SEPK, то претензий от TI к открытому эмулятору быть не должно?..

 

По эмуляции. Я экспериментировал с тремя семействами: C64хх (не плюс), C55xx, C28xx. Для них удалось реверсить содержание JTAG-цепочек таких распространённых операций как чтение/запись в память/регистры ядра, установка/снятие точек останова, запуск/останов программы и т.п. Не удалось до конца познать суть инициализационных цепочек, а также назначение всех разрядов регистра статуса (я о нем упоминал в статье).

Ясно. А второй части статьи не было? Может, в черновиках на старом диске?

 

По поводу "подёргать ножкой". Я в boundary scan не силён, для этого действительно есть специальные инструменты, BSDL-описания, в общем с эмуляцией граничное сканирование объединяет лишь одно -- физический интерфейс JTAG. В остальном это весьма разные вещи. По граничному сканированию рекомендую обратиться к знаниям ув. iosifk: http://iosifk.narod.ru/

Вы даже можете пообщаться с ним лично, ранее он бывал на этом форуме.

Спасибо за совет. С boundary scan, вроде, всё должно быть просто, если бы не обнаруженная вами особенность TI DSP обмениваться информацией исключительно через IR, а не, как полагается(?) через IR/DR.

 

Ну а в остальном я готов проконсультировать в любых вопросах, на которые знаю/помню ответы. Правда род моей деятельности сменился, поэтому я сейчас от этого несколько далёк :laughing:

Кардинально (не электроника/программирование)? В любом случае заранее спасибо!

[Edmundo 0]

Да, для вашего подхода, кажется, нужен как раз минимум действий. И раз не заглядывали в это SEPK, то претензий от TI к открытому эмулятору быть не должно?..

Нужно перехыватывать все GTI_* функции вместо того, чтобы перехватить парочку низкоуровневых. В этом сложность.

Насколько я помню, лицензионное соглашение CCS не очень приветствует реверс-инжиниринг, так что о лицензионной чистоте можно спорить. Но в остальном да, никаких NDA и прочих ограничений нету. Как мне кажется, TI идёт в сторону либерализации, вон даже бесплатная версия CCS есть, когда во времена v2-v3 мы и помыслить о таком не могли. XDS100 опять же -- полный opensource hardware! Так что сомневаюсь, что они будут преследовать таких вот горе-исследователей ;)

 

Ясно. А второй части статьи не было? Может, в черновиках на старом диске?

Нет, до второй статьи руки не дошли. Я вообще думал, что с появлением XDS100 эта тема утратила актуальность не только для меня. Видать, ошибался :rolleyes: Да и процессоры сейчас пошли сплошь многоядерные, а как там производится эмуляция -- тёмный лес для меня.

 

Спасибо за совет. С boundary scan, вроде, всё должно быть просто, если бы не обнаруженная вами особенность TI DSP обмениваться информацией исключительно через IR, а не, как полагается(?) через IR/DR.

Как мне кажется, в режиме boundary scan используются как IR, так и DR. Это в режиме эмуляции задействован только IR. Тут надо анализировать BDSL-описание на конкретный камень. Но возможно, что ошибаюсь, ибо не вникал глубоко.

CCS действительно определяет тип процессора по информации в статусном регистре который считывает в узле IR автомата состояний JTAG. Но так же ли это делается в режиме boundary scan -- не ведаю.

 

Кардинально (не электроника/программирование)?

Не сильно кардинально, но электроника и программирование свелись к минимуму, однако в рамках хобби остались по-любому

[Raven 11]

Да, страничка по XDS100 действительно дает много новой интересной информации. Но, если я правильно понял из беглого ознакомления, раскрывается только HW JTAG-кабеля (притом, имеющего целый ряд ограничений по функционалу), а протокол общения с ним (самое вкусное :-)) - это пока Техас оберегает от "грязных хакерских ручек".

 

Так что ценность RE интерфейса драйвера только подтверждается. Нужно будет просто еще дальше пройти, до полной победы ;-)

 

По Boundary Scan. Это стандартная вещь JTAG'а, и если уж она поддерживается данным TAP'ом, то можно брать BSDL, анализировать его и дрыгать ножкой. Другое дело, что в чипе может быть и несколько TAP'ов (например, 1 для BSCAN, другой - для OCD). Но об этом тоже можно разузнать и работать с нужным.

 

Так, BSDL-файлы есть. UrJTAG не знает XDS100v2. Нашёл патч, собрал UrJTAG. Но и он тоже не хочет работать с Техасом. Наверняка, пытается детектить чип по DR, а там - тишина. А как без успешного detect подсунуть ему инфу про чип и затем послать что-то вроде

Да нет, особенность работы Техасовского OCD здесь ни при чем - идентификация должна поддерживаться стандартно, путем вычитывания IDCODE. Это любой, кто назвался IEEE 1149.1 TAP'ом, должен делать единообразно. Просто UrJTAG, конечно же, не знает про XDS100 - во времена последнего обновления UrJTAG еще, поди, и XDS100 не было :). Но для BSCAN он нам и не нужен. А нужен любой другой кабель, знакомый UrJTAG'у. У вас что есть, помимо XDS100? Вот здесь список поддерживаемых кабелей: список.

 

Можете выложить BSDL-файлы чипа, о котором идет речь? Надо взглянуть.

 

И еще. Если мы начинаем совместно что-то исследовать, то неплохо бы хотя бы в какой-то степени синхронизировать программно-аппаратный инструментарий. Конкретно на данный момент - надо бы и мне собрать UrJTAG. Если не сложно, не поделитесь описанием проблем при сборке, патчем и т.п. ? Чтобы быстрей дело пошло...

 

Полной синхронизации в ближайшее время пока не будет, конечно (например, TMS'ов у меня ни в каком виде под руками пока нет), но для первых шагов оно и необязательно. Зато есть некоторое знание JTAG'остроения и RTL-design'а (включая FPGA), что сейчас важнее.

[gagel 0]

Да, страничка по XDS100 действительно дает много новой интересной информации. Но, если я правильно понял из беглого ознакомления, раскрывается только HW JTAG-кабеля (притом, имеющего целый ряд ограничений по функционалу), а протокол общения с ним (самое вкусное :-)) - это пока Техас оберегает от "грязных хакерских ручек".

Вообще, xds100v2 и стандартная платка с ft2232h - это как найдите 7 отличий. Или там есть всё же какое-то принципиальное отличие?

 

Так что ценность RE интерфейса драйвера только подтверждается. Нужно будет просто еще дальше пройти, до полной победы ;-)

 

По Boundary Scan. Это стандартная вещь JTAG'а, и если уж она поддерживается данным TAP'ом, то можно брать BSDL, анализировать его и дрыгать ножкой. Другое дело, что в чипе может быть и несколько TAP'ов (например, 1 для BSCAN, другой - для OCD). Но об этом тоже можно разузнать и работать с нужным.

Да, вот тут интересно.

 

Да нет, особенность работы Техасовского OCD здесь ни при чем - идентификация должна поддерживаться стандартно, путем вычитывания IDCODE. Это любой, кто назвался IEEE 1149.1 TAP'ом, должен делать единообразно. Просто UrJTAG, конечно же, не знает про XDS100 - во времена последнего обновления UrJTAG еще, поди, и XDS100 не было :). Но для BSCAN он нам и не нужен. А нужен любой другой кабель, знакомый UrJTAG'у. У вас что есть, помимо XDS100? Вот здесь список поддерживаемых кабелей: список.

Кроме xds100v2 есть стандартная платка ft2232h и STM Discovery-F4 (паяльника нет). Я читал, что IDCODE - это сходу где угодно. Благодаря этому вообще находят нужные JTAG-пины. Так что очень странно, что оно пока не получается с C55x, когда пины известны. Разве что инициализация этого xds100v2 может быть причиной?

 

Можете выложить BSDL-файлы чипа, о котором идет речь? Надо взглянуть.

Вот тут они в свободном доступе: 5502 и 5509a. Я пользуюсь ezdsp5502, там xds100v2 встроенный. Иногда есть доступ к 5509a (с xds100v2-кабелем). Кстати, BSDL у 5509a выглядит более подробным.

 

И еще. Если мы начинаем совместно что-то исследовать, то неплохо бы хотя бы в какой-то степени синхронизировать программно-аппаратный инструментарий. Конкретно на данный момент - надо бы и мне собрать UrJTAG. Если не сложно, не поделитесь описанием проблем при сборке, патчем и т.п. ? Чтобы быстрей дело пошло...

Проблем со сборкой не было. Патч брал здесь: XDS100 для UrJTAG. Собирал под Debian testing последнюю svn-ревизию 2052 из git'а:

git clone git://git.code.sf.net/p/urjtag/git urjtag-git

 

Полной синхронизации в ближайшее время пока не будет, конечно (например, TMS'ов у меня ни в каком виде под руками пока нет), но для первых шагов оно и необязательно. Зато есть некоторое знание JTAG'остроения и RTL-design'а (включая FPGA), что сейчас важнее.

Интересно, есть ли они вообще ещё у кого-то или C55x - уже совсем антиквариат?

[Raven 11]

Вообще, xds100v2 и стандартная платка с ft2232h - это как найдите 7 отличий. Или там есть всё же какое-то принципиальное отличие?

Я, признаться, пока на внутренности XDS100 не смотрел. Если они на FT2232H - тем лучше.

 

Кроме xds100v2 есть стандартная платка ft2232h и STM Discovery-F4 (паяльника нет).

Стандартная плата ft2232h - тоже хорошо, будет дублером для перепроверок. Если на ней есть header'ные контакты - то соединения можно будет делать и без паяльника, с помощью готовых оконцованных проводочков. С STM Discovery я пока, как ни странно, дела не имел, и поэтому для меня он в качестве инструмента пока отодвигается в конец списка. А вот если для вас он - старый добрый друг, то вполне может сгодится на каком-то этапе (с микроконтроллером какие-то итерации исследований/тестов могут быть быстрее).

 

Я читал, что IDCODE - это сходу где угодно. Благодаря этому вообще находят нужные JTAG-пины. Так что очень странно, что оно пока не получается с C55x, когда пины известны. Разве что инициализация этого xds100v2 может быть причиной?

Взглянул на оба BSDL-файла. Очень интересно. Факты таковы:

1) У 5502 и 5509, похоже, принципиально разный интерфейс к OCD-функционалу. 5502 предполагает работу с использованием "длинного" 38-битового IR, а 5509 выглядит в этой части более похожим на нынешний OCD-мейнстрим со сравнительно "коротким" IR (у 5509 - 6 бит).

 

2) 5502, как можно догадаться по номеру, древнее 5509, и НЕ ПОДДЕРЖИВАЕТ IDCODE инструкцию (это из BSDL видно). Давненько такое в мои руки не попадало :) Соответственно, автоматические процедуры распознавания устройств в JTAG-цепочке будут упираться лбом в 5502. Что потребует какого-то ручного разъяснения для них, кто есть кто. 5509 поддерживает IDCODE (0x0805002F).

 

3) Чтобы их JTAG-пины подключились к TAP'у и заработали именно в качестве JTAG-интерфейса (а не обслуживали factory test mode), нужно, чтобы в момент положительного фронта TRSTn (т.е., в момент выхода из Test Reset) на пинах EMU0 и EMU1 были определенные уровни: 0b11 для 5502, и 0b00 для 5509. Возможно, на плате все уже для этого сделано и намертво притянуто к нужным уровням, но проверить не помешает (если будут проблемы).

 

Проблем со сборкой не было. Патч брал здесь: XDS100 для UrJTAG. Собирал под Debian testing последнюю svn-ревизию 2052 из git'а:

git clone git://git.code.sf.net/p/urjtag/git urjtag-git

Понял. Я буду начинать с CygWin'а. Кстати, вы собирали HEAD или TAG_0-10-0?

 

Интересно, есть ли они вообще ещё у кого-то или C55x - уже совсем антиквариат?

Настолько древние? Ладно, лишь бы платы были исправными, процы поддерживались CCS и была документация :).

 

[gagel 0]

Я, признаться, пока на внутренности XDS100 не смотрел. Если они на FT2232H - тем лучше.

 

Стандартная плата ft2232h - тоже хорошо, будет дублером для перепроверок. Если на ней есть header'ные контакты - то соединения можно будет делать и без паяльника, с помощью готовых оконцованных проводочков. С STM Discovery я пока, как ни странно, дела не имел, и поэтому для меня он в качестве инструмента пока отодвигается в конец списка. А вот если для вас он - старый добрый друг, то вполне может сгодится на каком-то этапе (с микроконтроллером какие-то итерации исследований/тестов могут быть быстрее).

Ну, я не совсем электронщик - так что друг он не старый. Но проводки есть. Разве что с платой ezdsp5502 они бесполезны, т.к. в отличие от STM Техас не предусмотрели возможность подключения внешнего отладчика, только впаянный. А с платой 5509a я не могу так свободно экспериментировать: только с имеющимся xds100v2-кабелем.

 

Взглянул на оба BSDL-файла. Очень интересно. Факты таковы:

1) У 5502 и 5509, похоже, принципиально разный интерфейс к OCD-функционалу. 5502 предполагает работу с использованием "длинного" 38-битового IR, а 5509 выглядит в этой части более похожим на нынешний OCD-мейнстрим со сравнительно "коротким" IR (у 5509 - 6 бит).

Хочется верить, что факты, а не ещё не исправленные баги, как:

5502:

BSDL Revision : 1.1 - Changed Inst length from 6 to 38 bits.

И, кстати, не смотря на 38 бит, всё равно Edmundo обнаружил, что слать надо 54, а, значит, и устанавливать irlen в 54.

 

2) 5502, как можно догадаться по номеру, древнее 5509, и НЕ ПОДДЕРЖИВАЕТ IDCODE инструкцию (это из BSDL видно). Давненько такое в мои руки не попадало :) Соответственно, автоматические процедуры распознавания устройств в JTAG-цепочке будут упираться лбом в 5502. Что потребует какого-то ручного разъяснения для них, кто есть кто. 5509 поддерживает IDCODE (0x0805002F).

Как-то я этим номерам не очень доверяю, кто из них древнее. Хотя IDCODE и опциональна, но всё равно не верится, чтобы она была не реализована. Это же просто беспрецедентно за всю историю развития UrJTAG и OpenOCD!

 

3) Чтобы их JTAG-пины подключились к TAP'у и заработали именно в качестве JTAG-интерфейса (а не обслуживали factory test mode), нужно, чтобы в момент положительного фронта TRSTn (т.е., в момент выхода из Test Reset) на пинах EMU0 и EMU1 были определенные уровни: 0b11 для 5502, и 0b00 для 5509. Возможно, на плате все уже для этого сделано и намертво притянуто к нужным уровням, но проверить не помешает (если будут проблемы).

Так для отладки и для boundary scan разные условия для этих пинов? И т.к. xds100v2 предназначен в первую очередь для отладки, не окажется, что там пины намертво так притянуты, что нельзя выбрать нужный для скана режим? Вот проверить все эти соответствия на схеме с описаниями и таймингами и не запутаться для меня сложновато. Надеюсь, к ним есть программный доступ через libftdi.

 

Понял. Я буду начинать с CygWin'а. Кстати, вы собирали HEAD или TAG_0-10-0?

TAG_0-10-0 - это, наверное, релиз 0.10, вышедший 7 лет назад. А HEAD - это только указатель. Собирал я git master (основная ветка, где, как правило, ведётся разработка). Сам UrJTAG разрабатывается в svn, а git - это только зеркало. Поэтому в логе можно видеть текущую svn-ревизию (git-svn-id: ... trunk@2052 ...):

$ git log -1
commit bac6b34d8e278df25b178ea929d2c41ba6a146e5
Author: Mike Frysinger <[email protected]>
Date:   Sun Oct 11 04:57:45 2015 +0000

    ignore .dirstamp files
    
    git-svn-id: svn://svn.code.sf.net/p/urjtag/svn/trunk@2052 b68d4a1b-bc3d-0410-92ed-d4ac073336b7

 

 

Надеюсь, к ним есть программный доступ через libftdi.

Так, глянул на ezdsp5502_Schematics_RevC.pdf. EMU0 и EMU1 пулапнуты. Значит, TAP и для дебага, и для boundary scan - один и тот же. И значит, нет доступа только к factory test, что и не нужно. Да и с libftdi, значит, меньше ошибок будет.

 

А вот для 5509a - требования с точностью до наоборот: пины должны быть заземлены для boundary scan.

 

Чтобы не запутаться:

5502

============

EMU0 (I/O/Z)

-----

Emulator 0 pin. When nTRST is driven low, EMU0 must be high for activation of the

nOFF condition. When nTRST is driven high, EMU0 is used as an interrupt to or from

the emulator system and is defined as I/O by way of the IEEE standard 1149.1 scan

system.

The EMU0 and EMU1/nOFF pins must be pulled up when an emulator is not

connected. Internal pullups have been included for the purpose. If the user chooses

to disable these pullups through the XBCR, external pullup resistors must be added

to these two pins.

 

EMU1/nOFF (I/O/Z)

-----

Emulator 1 pin/disable all outputs. When nTRST is driven high, EMU1/nOFF is used

as an interrupt to or from the emulator system and is defined as I/O by way of IEEE

standard 1149.1 scan system. When nTRST is driven low, EMU1/nOFF is configured

as nOFF. The EMU1/nOFF signal, when active (low), puts all output drivers into the

high-impedance state. Note that nOFF is used exclusively for testing and emulation

purposes (not for multiprocessing applications). Therefore, for the nOFF condition, the

following apply:

• nTRST = low,

• EMU0 = high,

• EMU1/nOFF = low

The EMU0 and EMU1/nOFF pins must be pulled up when an emulator is not

connected. Internal pullups have been included for the purpose. If the user chooses

to disable these pullups through the XBCR, external pullup resistors must be added

to these two pins.

 

5509a

===========

 

EMU0 (I/O/Z)

-----

Emulator 0 pin. When nTRST is driven low, EMU0 must be high for

activation of the nOFF condition. When nTRST is driven high, EMU0 is used

as an interrupt to or from the emulator system and is defined as I/O by way

of the IEEE standard 1149.1 scan system.

 

EMU1/nOFF (I/O/Z)

-----

Emulator 1 pin/disable all outputs. When nTRST is driven high, EMU1/nOFF

is used as an interrupt to or from the emulator system and is defined as I/O

by way of IEEE standard 1149.1 scan system. When nTRST is driven low,

EMU1/nOFF is configured as nOFF. The EMU1/nOFF signal, when

active-low, puts all output drivers into the high-impedance state. Note that

nOFF is used exclusively for testing and emulation purposes (not for

multiprocessing applications). Therefore, for the nOFF condition, the

following apply: nTRST = low, EMU0 = high, EMU1/nOFF = low

Интересно, там ещё и прерывания есть.

 

Кстати, для сборки UrJTAG нужно иметь (среди прочих зависимостей) libusb-1.0 и libftdi (или 0.20 или 1.x). Я пока пробую с 0.20.

Изменено 10 июня, 2016 пользователем gagel

[Raven 11]

Хочется верить, что факты, а не ещё не исправленные баги, как:

Будем надеяться. Но в отношении 5509 сомневаюсь - слишком много в его BSDL других зявязок на IR-Length=6 (например, собственно коды инструкций). К тому же файл для 5502 все же содержит уже устоявшуюся информацию (за столько-то лет) - errata в нем уже учтена.

 

И, кстати, не смотря на 38 бит, всё равно Edmundo обнаружил, что слать надо 54, а, значит, и устанавливать irlen в 54.

А вот с этим будем разбираться - кто чего куда там добавляет в цепочку тихой сапой :).

 

Как-то я этим номерам не очень доверяю, кто из них древнее. Хотя IDCODE и опциональна, но всё равно не верится, чтобы она была не реализована. Это же просто беспрецедентно за всю историю развития UrJTAG и OpenOCD!

Да нет, это вполне по стандарту (он такое допускает), но совсем не комильфо для сегодняшнего дня.

 

А вот для 5509a - требования с точностью до наоборот: пины должны быть заземлены для boundary scan.

 

Чтобы не запутаться:

Это откуда цитаты?

 

Интересно, там ещё и прерывания есть.

Насколько я понимаю, это способ дернуть кабель-адаптер, чтобы сообщить ему о произошедших debug-событиях. Довольно обычная вещь в OCD системах.

 

Кстати, для сборки UrJTAG нужно иметь (среди прочих зависимостей) libusb-1.0 и libftdi (или 0.20 или 1.x). Я пока пробую с 0.20.

Я недавно проходил подобным путем при сборке OOCD, так что многое уже на месте. Но с наскока под CygWin не собралось. Еще немного помучаю его, и если за выходные не заведется - попробую под Linux.

[gagel 0]

Это откуда цитаты?

Из официальной документации: 5502, 5509a.

 

Edmundo,

я закончил черновик so-прокси (so - это shared object типа вин-DLL): т.е. используя найденные вами заголовки функций я набросал прокси, подменил оригинальную so'шку, а в прокси дёргаю функции из оригинальной so'шки один в один. Первое, что сделала CCS 6.1.3 - упала. Вылечить удалось быстро:

- char *GTI_GETERRSTR_EX3(void)
+ char* GTI_GETERRSTR_EX3(void *pHandle, unsigned long *pParam1, unsigned long *pParam2, unsigned long *pParam3, unsigned long *pParam4, unsigned long *pParam5, unsigned long *pParam6, unsigned long *pParam7, char *str1, int unkn1, char* str2, int unkn2)

Для прокси это подошло, но как разобраться, что это за параметры для собственной реализации? Вот так это выглядит в логе:

0xC9A5DB40 5855241 3 C55xx GTI C: GTI_GETERRSTR_EX3( 0x0xca953838, *0x0xc9a5c640 = 0x00000000, *0x0xc9a5c638 = 0x00000000, *0x0xc9a5c644 = 0x00000000, *0x0xc9a5c648 = 0x00000000, *0x0xc9a5c64c = 0x00000000, *0x0xc9a5c650 = 0x00000000, *0x0xc9a5c654 = 0x00000000, "", 0x00000040, "", 0x00000400 )
0xC9A5DB40 5855241 3 C55xx GTI R: GTI_GETERRSTR_EX3( 0x0xca953838, *0x0xc9a5c640 = 0x00000000, *0x0xc9a5c638 = 0x00000000, *0x0xc9a5c644 = 0x00000000, *0x0xc9a5c648 = 0x00000002, *0x0xc9a5c64c = 0x00000000, *0x0xc9a5c650 = 0x00000008, *0x0xc9a5c654 = 0x00000000, "", 0x00000040, "", 0x00000400 ) = 0x00000000

 

И ещё появились(?) как минимум несколько функций, которые не только присутствуют в libtixds55x.so, но и вызываются CCS: GTI_GET_NUM_RESETS, GTI_GET_RESET_INFO, GTI_RESET_EX:

0xC9A5DB40 5851429 3 C55xx GTI C: GTI_GET_NUM_RESETS( 0x0xca953838 )
0xC9A5DB40 5851430 3 C55xx GTI R: GTI_GET_NUM_RESETS( 0x0xca953838 ) = 0x00000001

Тут можно предположить, что просто есть один вид RESET'а, значит возвращается 1 (но int или unsigned int)?

 

0xC9A5DB40 5851430 3 C55xx GTI C: GTI_GET_RESET_INFO( 0x0xca953838, 0x00000000, *0x0xc9a5c4fc = ??? )
0xC9A5DB40 5851430 3 C55xx GTI R: GTI_GET_RESET_INFO( 0x0xca953838, 0x00000000, *0x0xc9a5c4fc = ??? ) = 0x00000000

Тут выбирается RESET номер 1 (т.е. 0) и получается указатель на инфу о RESET'е?

 

0xC9A5DB40 5855123 3 C55xx GTI C: GTI_RESET_EX( 0x0xca953838, 0x00000000 )
0xC9A5DB40 5855140 3 C55xx GTI R: GTI_RESET_EX( 0x0xca953838, 0x00000000 ) = 0x00000000

Тут вызывается RESET номер 1 (т.е. 0) и статус 0 (нет ошибки)?

 

И есть ещё несколько функций, которые есть в бинарнике, но я пока не заметил их вызова из CCS:

GTI_QUERY_INTERFACE
GTI_BLOCK_RESET
GTI_GET_WAIT_IN_RESET_MODE
GTI_SET_WAIT_IN_RESET
GTI_BP_TEST
GTI_STAT_EX2

 

Ещё, кстати, RTDX уже некоторое время как объявлен устаревшим. Но почему? Я так и не нашёл официального объяснения и предложения по замене. Так вот в 6.1.1 или 6.1.2 RTDX-функции были выброшены из so'шки. А в DSPBIOS они до сих пор место занимают. Вам доводилось их использовать? Интересно, можно ли их воскресить? Хотя, скорее всего, чисто теоретически.

Изменено 12 июня, 2016 пользователем gagel

[Raven 11]

В продолжение линии BSCAN для 5502, 5509а:

- нельзя ли выложить логи подключения UrJTAG для того и другого? В частности, хочется увидеть, как воспринимается отсутствие IDCODE в 5502 и (надеюсь) его присутствие в 5509а.

[gagel 0]

Raven,

да urjtag (как и oocd) не справляется даже с самым первым шагом: определение IRLEN:

jtag> debug all
debug: src/global/parse.c:167 urj_parse_line(): Return in urj_parse_line r=0 line={debug all}
jtag> cable JTAGv5
src/tap/usbconn/libftdi.c:336 usbconn_ftdi_connect(): Connected to libftdi driver.
src/tap/cable/ft2232.c:1203 ft2232_jtagv5_init(): JTAGv5: JTAG Mode Initialization OK!
debug: src/tap/state.c:59 urj_tap_state_dump(): tap_state: UNKNOWN_STATE
debug: src/tap/state.c:59 urj_tap_state_dump(): tap_state: TEST_LOGIC_RESET
debug: src/tap/state.c:59 urj_tap_state_dump(): tap_state: TEST_LOGIC_RESET
debug: src/tap/state.c:66 urj_tap_state_dump_2(): tap_state: TEST_LOGIC_RESET =(tms:1)=> TEST_LOGIC_RESET
debug: src/tap/state.c:66 urj_tap_state_dump_2(): tap_state: TEST_LOGIC_RESET =(tms:1)=> TEST_LOGIC_RESET
debug: src/tap/state.c:66 urj_tap_state_dump_2(): tap_state: TEST_LOGIC_RESET =(tms:1)=> TEST_LOGIC_RESET
debug: src/tap/state.c:66 urj_tap_state_dump_2(): tap_state: TEST_LOGIC_RESET =(tms:1)=> TEST_LOGIC_RESET
debug: src/tap/state.c:66 urj_tap_state_dump_2(): tap_state: TEST_LOGIC_RESET =(tms:1)=> TEST_LOGIC_RESET
debug: src/tap/state.c:66 urj_tap_state_dump_2(): tap_state: TEST_LOGIC_RESET =(tms:0)=> RUN_TEST_IDLE
debug: src/global/parse.c:167 urj_parse_line(): Return in urj_parse_line r=0 line={cable JTAGv5}
jtag> detect
debug: src/tap/state.c:59 urj_tap_state_dump(): tap_state: TEST_LOGIC_RESET
debug: src/tap/state.c:66 urj_tap_state_dump_2(): tap_state: TEST_LOGIC_RESET =(tms:1)=> TEST_LOGIC_RESET
debug: src/tap/state.c:66 urj_tap_state_dump_2(): tap_state: TEST_LOGIC_RESET =(tms:1)=> TEST_LOGIC_RESET
debug: src/tap/state.c:66 urj_tap_state_dump_2(): tap_state: TEST_LOGIC_RESET =(tms:1)=> TEST_LOGIC_RESET
debug: src/tap/state.c:66 urj_tap_state_dump_2(): tap_state: TEST_LOGIC_RESET =(tms:1)=> TEST_LOGIC_RESET
debug: src/tap/state.c:66 urj_tap_state_dump_2(): tap_state: TEST_LOGIC_RESET =(tms:1)=> TEST_LOGIC_RESET
debug: src/tap/state.c:66 urj_tap_state_dump_2(): tap_state: TEST_LOGIC_RESET =(tms:0)=> RUN_TEST_IDLE
debug: src/tap/state.c:66 urj_tap_state_dump_2(): tap_state:    RUN_TEST_IDLE =(tms:1)=> SELECT_DR_SCAN
debug: src/tap/state.c:66 urj_tap_state_dump_2(): tap_state:   SELECT_DR_SCAN =(tms:1)=> SELECT_IR_SCAN
debug: src/tap/state.c:66 urj_tap_state_dump_2(): tap_state:   SELECT_IR_SCAN =(tms:0)=> CAPTURE_IR
debug: src/tap/state.c:66 urj_tap_state_dump_2(): tap_state:       CAPTURE_IR =(tms:0)=> SHIFT_IR
warning: src/tap/discovery.c:120 urj_tap_detect_register_size(): TDO seems to be stuck at 1
debug: src/global/parse.c:167 urj_parse_line(): Return in urj_parse_line r=1 line={detect}
jtag>

С 5509a ситуация та же. Я уже начал копаться в исходниках, чтобы помочь ему. Посмотрим, что выйдет.

 

А тем временем после написания декодера ftdi jtag, анализа его логов я написал минимальную программку - и ура! я могу считывать состояния всех пинов! Но не дёргать эти пины. Тут есть пара вопросов: инструкции PRELOAD нет, есть только SAMPLE. Остаётся пробовать её. Итак, делаю:

... --> SHIFT-IR --> (SAMPLE) --> ... --> SHIFT-DR --> (все нули) --> ... --> SHIFT-IR --> (EXTEST) --> ... --> SHIFT-DR (set control=1, value=0) --> ... --> SHIFT-IR (EXTEST) --> ... --> RUN-TEST-IDLE.

 

Реакция есть: выполнение загруженной программы останавливается. Но светодиодик не загорается (value = 0). Я правильно понял, что для установки значения нужно установить соответствующий ему control bit в 1? Для 5502:

   "214  (bc_1,                   *,   control,  1)," &
   "215  (bc_1,                  XF,   output3,  X,     214,   1,  Z)," &

И ещё я не понял, для чего это в 5502:

    attribute INSTRUCTION_CAPTURE of TMX320VC5502 : entity is  "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX01";

Изменено 19 июня, 2016 пользователем gagel

[gagel 0]

Всё, заработало!

... --> SHIFT-IR --> (SAMPLE) --> ... --> SHIFT-DR --> (все нули) --> ... --> SHIFT-IR --> (EXTEST) --> ... --> SHIFT-DR (set control=0, value=1) --> ... --> RUN-TEST-IDLE.

Нужно было только установить value (output3), а не и control тоже. Теперь только вопрос: а зачем этот control?

И ещё не ожидал, что при SAMPLE value=0 светодиодик горит, а при EXTEST для этого нужно писать 1. Я думал, что значение всего BSR можно один к одному использовать и для SAMPLE, и для EXTEST, т.е. содержимое интерпретируется одинаково, а не как пока получается: по-разному.

Изменено 19 июня, 2016 пользователем gagel

[Edmundo 0]

Edmundo,

я закончил черновик so-прокси (so - это shared object типа вин-DLL): т.е. используя найденные вами заголовки функций я набросал прокси, подменил оригинальную so'шку, а в прокси дёргаю функции из оригинальной so'шки один в один. Первое, что сделала CCS 6.1.3 - упала. Вылечить удалось быстро:

- char *GTI_GETERRSTR_EX3(void)
+ char* GTI_GETERRSTR_EX3(void *pHandle, unsigned long *pParam1, unsigned long *pParam2, unsigned long *pParam3, unsigned long *pParam4, unsigned long *pParam5, unsigned long *pParam6, unsigned long *pParam7, char *str1, int unkn1, char* str2, int unkn2)

Для прокси это подошло, но как разобраться, что это за параметры для собственной реализации? Вот так это выглядит в логе:

0xC9A5DB40 5855241 3 C55xx GTI C: GTI_GETERRSTR_EX3( 0x0xca953838, *0x0xc9a5c640 = 0x00000000, *0x0xc9a5c638 = 0x00000000, *0x0xc9a5c644 = 0x00000000, *0x0xc9a5c648 = 0x00000000, *0x0xc9a5c64c = 0x00000000, *0x0xc9a5c650 = 0x00000000, *0x0xc9a5c654 = 0x00000000, "", 0x00000040, "", 0x00000400 )
0xC9A5DB40 5855241 3 C55xx GTI R: GTI_GETERRSTR_EX3( 0x0xca953838, *0x0xc9a5c640 = 0x00000000, *0x0xc9a5c638 = 0x00000000, *0x0xc9a5c644 = 0x00000000, *0x0xc9a5c648 = 0x00000002, *0x0xc9a5c64c = 0x00000000, *0x0xc9a5c650 = 0x00000008, *0x0xc9a5c654 = 0x00000000, "", 0x00000040, "", 0x00000400 ) = 0x00000000

Понять суть параметров этих *_EX, *_EX2, *_EX3 и с каждой новой версией CCS все новых *_EX* -- сам чёрт ногу сломит. Но раньше было так, что если CCS не находил в драйвере GTI_GETERRSTR_EX*, то он обращался к GTI_GETERRSTR, параметры которой доступны для понимания.

 

И ещё появились(?) как минимум несколько функций, которые не только присутствуют в libtixds55x.so, но и вызываются CCS: GTI_GET_NUM_RESETS, GTI_GET_RESET_INFO, GTI_RESET_EX:

0xC9A5DB40 5851429 3 C55xx GTI C: GTI_GET_NUM_RESETS( 0x0xca953838 )
0xC9A5DB40 5851430 3 C55xx GTI R: GTI_GET_NUM_RESETS( 0x0xca953838 ) = 0x00000001

Тут можно предположить, что просто есть один вид RESET'а, значит возвращается 1 (но int или unsigned int)?

Наверное имеются в виду hardware reset, software reset и т.п. (то есть те варианты сброса, что есть в меню Debug)

Тип возвращаемого значения можно посмотреть дизассемблером. В общем случае int.

 

0xC9A5DB40 5851430 3 C55xx GTI C: GTI_GET_RESET_INFO( 0x0xca953838, 0x00000000, *0x0xc9a5c4fc = ??? )
0xC9A5DB40 5851430 3 C55xx GTI R: GTI_GET_RESET_INFO( 0x0xca953838, 0x00000000, *0x0xc9a5c4fc = ??? ) = 0x00000000

Тут выбирается RESET номер 1 (т.е. 0) и получается указатель на инфу о RESET'е?

Вполне вероятно. Если инфа в виде структуры, то распарсить её поля -- задача не из лёгких.

 

0xC9A5DB40 5855123 3 C55xx GTI C: GTI_RESET_EX( 0x0xca953838, 0x00000000 )
0xC9A5DB40 5855140 3 C55xx GTI R: GTI_RESET_EX( 0x0xca953838, 0x00000000 ) = 0x00000000

Тут вызывается RESET номер 1 (т.е. 0) и статус 0 (нет ошибки)?

Верно, GTI_RESET_EX, как мне помнится, шлет результат (0 в случае успеха).

 

И есть ещё несколько функций, которые есть в бинарнике, но я пока не заметил их вызова из CCS:

GTI_QUERY_INTERFACE
GTI_BLOCK_RESET
GTI_GET_WAIT_IN_RESET_MODE
GTI_SET_WAIT_IN_RESET
GTI_BP_TEST
GTI_STAT_EX2

Они не относятся к разряду супер-обязательных, назначение их надо исследовать дополнительно (при необходимости).

 

Ещё, кстати, RTDX уже некоторое время как объявлен устаревшим. Но почему? Я так и не нашёл официального объяснения и предложения по замене. Так вот в 6.1.1 или 6.1.2 RTDX-функции были выброшены из so'шки. А в DSPBIOS они до сих пор место занимают. Вам доводилось их использовать? Интересно, можно ли их воскресить? Хотя, скорее всего, чисто теоретически.

Я про такое не слышал. По-моему HSRTDX -- это одна из немногих возможностей неинвазивного обмена потоками информации с процессором. Откуда информация про obsolete?