Перейти к содержанию
    

gagel

Участник
  • Постов

    13
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный
  1. Всё, заработало! ... --> 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, т.е. содержимое интерпретируется одинаково, а не как пока получается: по-разному.
  2. 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";
  3. Из официальной документации: 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 они до сих пор место занимают. Вам доводилось их использовать? Интересно, можно ли их воскресить? Хотя, скорее всего, чисто теоретически.
  4. Ну, я не совсем электронщик - так что друг он не старый. Но проводки есть. Разве что с платой ezdsp5502 они бесполезны, т.к. в отличие от STM Техас не предусмотрели возможность подключения внешнего отладчика, только впаянный. А с платой 5509a я не могу так свободно экспериментировать: только с имеющимся xds100v2-кабелем. Хочется верить, что факты, а не ещё не исправленные баги, как: И, кстати, не смотря на 38 бит, всё равно Edmundo обнаружил, что слать надо 54, а, значит, и устанавливать irlen в 54. Как-то я этим номерам не очень доверяю, кто из них древнее. Хотя IDCODE и опциональна, но всё равно не верится, чтобы она была не реализована. Это же просто беспрецедентно за всю историю развития UrJTAG и OpenOCD! Так для отладки и для boundary scan разные условия для этих пинов? И т.к. xds100v2 предназначен в первую очередь для отладки, не окажется, что там пины намертво так притянуты, что нельзя выбрать нужный для скана режим? Вот проверить все эти соответствия на схеме с описаниями и таймингами и не запутаться для меня сложновато. Надеюсь, к ним есть программный доступ через libftdi. 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 Так, глянул на ezdsp5502_Schematics_RevC.pdf. EMU0 и EMU1 пулапнуты. Значит, TAP и для дебага, и для boundary scan - один и тот же. И значит, нет доступа только к factory test, что и не нужно. Да и с libftdi, значит, меньше ошибок будет. А вот для 5509a - требования с точностью до наоборот: пины должны быть заземлены для boundary scan. Чтобы не запутаться: Интересно, там ещё и прерывания есть. Кстати, для сборки UrJTAG нужно иметь (среди прочих зависимостей) libusb-1.0 и libftdi (или 0.20 или 1.x). Я пока пробую с 0.20.
  5. Вообще, xds100v2 и стандартная платка с ft2232h - это как найдите 7 отличий. Или там есть всё же какое-то принципиальное отличие? Да, вот тут интересно. Кроме xds100v2 есть стандартная платка ft2232h и STM Discovery-F4 (паяльника нет). Я читал, что IDCODE - это сходу где угодно. Благодаря этому вообще находят нужные JTAG-пины. Так что очень странно, что оно пока не получается с C55x, когда пины известны. Разве что инициализация этого xds100v2 может быть причиной? Вот тут они в свободном доступе: 5502 и 5509a. Я пользуюсь ezdsp5502, там xds100v2 встроенный. Иногда есть доступ к 5509a (с xds100v2-кабелем). Кстати, BSDL у 5509a выглядит более подробным. Проблем со сборкой не было. Патч брал здесь: XDS100 для UrJTAG. Собирал под Debian testing последнюю svn-ревизию 2052 из git'а: git clone git://git.code.sf.net/p/urjtag/git urjtag-git Интересно, есть ли они вообще ещё у кого-то или C55x - уже совсем антиквариат?
  6. Так, 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 или аналогами было бы вообще прелесть! Эх, вот тогда была бы полная независимость. Да, для вашего подхода, кажется, нужен как раз минимум действий. И раз не заглядывали в это SEPK, то претензий от TI к открытому эмулятору быть не должно?.. Ясно. А второй части статьи не было? Может, в черновиках на старом диске? Спасибо за совет. С boundary scan, вроде, всё должно быть просто, если бы не обнаруженная вами особенность TI DSP обмениваться информацией исключительно через IR, а не, как полагается(?) через IR/DR. Кардинально (не электроника/программирование)? В любом случае заранее спасибо!
  7. Да, работает ;) А то как бы я вообще этим вопросом заинтересовался: есть ещё какие-то IDE для c55x? Точно. Мне показалось, что как раз у Техаса отклонение от нормы: ведь они не используют DR. Или для чего DR придумали? Самописную мини-программку для демонстрации, что результаты реверса в принципе работают через libftdi и xds100 на c55x. Проприетарные не интересуют в принципе. А есть примеры скриптов для OpenOCD? В UrJTAG последний значимый коммит был почти 2 года назад. Им ещё пользуются? И я так понимаю, что если мне нужно всего один пин дёргать, то всё равно нужно доставать BSDL-файлы? И не может так оказаться, что аналогично с IR/DR Техас по-другому реализовали доступ для boundary scan и OpenOCD снова не в состоянии помочь? Эх, мне бы просто информацию, какую команду в IR послать, какой формат для выбора пина и данных, и всё.
  8. Идеальную картину я себе обрисовал некоторое время назад. Поддержка c55x не только в openocd, но и в gdb (иначе что толку от openocd?) и binutils(?). С одной стороны gcc умеет c6x и gdb тоже, но вот с c55x не сложилось. На этом идеал закончился, потому что реализовать поддержку в gdb хоть и можно (13 лет назад кто-то интересовался этим вопросом в списке рассылок gdb), но точно не в одиночку как хобби. Кстати, openocd пришлось бы перерабатывать: ведь здесь вместо нормального разделения команда по irscan, данные по drscan применяют исключительно irscan. Запустить в обособленном режиме через libftdi могу попробовать. Но это даст слишком мало: только читать/писать память и, может, старт/стоп (уже загруженной) программы. Без возможности загрузки программы, без точек останова, CIO printf, Log.printf DSPBIOS,.. Кстати, что ещё было бы интересно (и просто?) - это попробовать с помощью самописной маленькой программки через boundary scan подёргать пин, на котором висит светодиодик. Но вот куда копать?
  9. Вот это было бы здорово! Т.к. понимаю, что у вас интереса, наверняка, уже нет, может, поможете советом и информацией, как бы это реализовать? Я сейчас пробую (под Линуксом) заменить libtixds55x.so, в которой сидят GTI_*, TRG_*, PTI_*. Для платки с tms320c5502. Т.к. загрузка программки длится просто нереально долго, а также printf (CIO) слишком медленный. И это, учитывая, что xds100 реализован на ftdi 2232h, который может прокачать и 400 Мбит/с (8 бит параллельно). Спасибо! Надеюсь, оно подходит для c55x?.. Кстати, есть ещё люди, интересующиеся open source реализацией? (Преимущественно под Линукс, но портабельно, чтобы и под винду собиралось.)
  10. STM32 USB Vendor ID Product ID

    Не слышал, но интересно: есть линки?
  11. STM32 USB Vendor ID Product ID

    Эта задача была "раз сделал и забыл", так что деталей точно не помню. Конфигурируешь, получаешь .exe (даже два: для x86 и "x64"), так что пользователю нужно просто нажать на Ok. Недостатки? Смотря с чем сравнивать.
  12. STM32 USB Vendor ID Product ID

    Лично я пишу драйвер, использующий libusb. А под виндой можно подготовить установщик libusb-драйвера с помощью libwdi / Zadig. И подписывать не приходится, т.к., если не ошибаюсь, libusb.sys один раз уже подписан и для всех. Не путать с libusb.dll, который можно и самому перекомпилировать (gcc / MSVC без всяких DDK).
  13. Например, в случае с st-link это может зависеть и от прошивки отладчика: ST-LINK/V2 firmware upgrade (DM00067813.pdf):
×
×
  • Создать...