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

    

Edmundo

Свой
  • Публикаций

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

  • Посещение

Репутация

0 Обычный

Информация о Edmundo

  • Звание
    Мастер

Контакты

  • Сайт
    http://
  • ICQ
    0

Информация

  • Город
    Москва
  1. Возможно, кто-то тоже сталкивался с тем, что Blackhawk USB560v2 переставал загружаться. Здесь статья, как с этим можно бороться: https://habr.com/post/420895/
  2. Извиняюсь, что не ответил сразу, редко здесь бываю. Да, ещё в продаже.
  3. Пересылка в другой город возможна?
  4. Цитата(Ar-han @ Jun 21 2016, 10:55) Отладчик купил за 2000 руб Как-то попытался подключить XDS100 v2 к плате, тест коннект прошел, а отладка не заработала, в причинах не разобрался. Я бы лучше с XDS100v2 экспериментировал, чем с этим вот китайским экземпляром. Тем более, если xdsprobe показывает наличие коннекта, то запустить эмуляцию -- дело техники.
  5. Цитата(gagel @ Jun 12 2016, 21:36) 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, параметры которой доступны для понимания. Цитата(gagel @ Jun 12 2016, 21:36) И ещё появились(?) как минимум несколько функций, которые не только присутствуют в 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. Цитата(gagel @ Jun 12 2016, 21:36) Код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'е? Вполне вероятно. Если инфа в виде структуры, то распарсить её поля -- задача не из лёгких. Цитата(gagel @ Jun 12 2016, 21:36) Код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 в случае успеха). Цитата(gagel @ Jun 12 2016, 21:36) И есть ещё несколько функций, которые есть в бинарнике, но я пока не заметил их вызова из CCS: КодGTI_QUERY_INTERFACE GTI_BLOCK_RESET GTI_GET_WAIT_IN_RESET_MODE GTI_SET_WAIT_IN_RESET GTI_BP_TEST GTI_STAT_EX2 Они не относятся к разряду супер-обязательных, назначение их надо исследовать дополнительно (при необходимости). Цитата(gagel @ Jun 12 2016, 21:36) Ещё, кстати, RTDX уже некоторое время как объявлен устаревшим. Но почему? Я так и не нашёл официального объяснения и предложения по замене. Так вот в 6.1.1 или 6.1.2 RTDX-функции были выброшены из so'шки. А в DSPBIOS они до сих пор место занимают. Вам доводилось их использовать? Интересно, можно ли их воскресить? Хотя, скорее всего, чисто теоретически. Я про такое не слышал. По-моему HSRTDX -- это одна из немногих возможностей неинвазивного обмена потоками информации с процессором. Откуда информация про obsolete?
  6. Цитата(Ar-han @ Apr 21 2016, 18:25) Что-то такое должно получиться? Лучше было бы, если EMU0 и EMU1 были двунаправленными. PD во все времена использовалось для level-shift'инга. Именно по нему нормальные JTAG-эмуляторы определяют нужный уровень и подстраиваются. Если не секрет -- что за JTAG-эмулятор вы используете?
  7. Цитата(gagel @ Jun 8 2016, 16:01) Да, для вашего подхода, кажется, нужен как раз минимум действий. И раз не заглядывали в это SEPK, то претензий от TI к открытому эмулятору быть не должно?.. Нужно перехыватывать все GTI_* функции вместо того, чтобы перехватить парочку низкоуровневых. В этом сложность. Насколько я помню, лицензионное соглашение CCS не очень приветствует реверс-инжиниринг, так что о лицензионной чистоте можно спорить. Но в остальном да, никаких NDA и прочих ограничений нету. Как мне кажется, TI идёт в сторону либерализации, вон даже бесплатная версия CCS есть, когда во времена v2-v3 мы и помыслить о таком не могли. XDS100 опять же -- полный opensource hardware! Так что сомневаюсь, что они будут преследовать таких вот горе-исследователей Цитата(gagel @ Jun 8 2016, 16:01) Ясно. А второй части статьи не было? Может, в черновиках на старом диске? Нет, до второй статьи руки не дошли. Я вообще думал, что с появлением XDS100 эта тема утратила актуальность не только для меня. Видать, ошибался Да и процессоры сейчас пошли сплошь многоядерные, а как там производится эмуляция -- тёмный лес для меня. Цитата(gagel @ Jun 8 2016, 16:01) Спасибо за совет. С boundary scan, вроде, всё должно быть просто, если бы не обнаруженная вами особенность TI DSP обмениваться информацией исключительно через IR, а не, как полагается(?) через IR/DR. Как мне кажется, в режиме boundary scan используются как IR, так и DR. Это в режиме эмуляции задействован только IR. Тут надо анализировать BDSL-описание на конкретный камень. Но возможно, что ошибаюсь, ибо не вникал глубоко. CCS действительно определяет тип процессора по информации в статусном регистре который считывает в узле IR автомата состояний JTAG. Но так же ли это делается в режиме boundary scan -- не ведаю. Цитата(gagel @ Jun 8 2016, 16:01) Кардинально (не электроника/программирование)? Не сильно кардинально, но электроника и программирование свелись к минимуму, однако в рамках хобби остались по-любому
  8. Прошу прощения за такое безответственное поведение с исходниками, надо сделать над собой волевое усилие, и выложить все, что есть, на github, хотя бы свалку для начала, а потом уже разобрать. Надо пошуршать по старым жёстким дискам. Вообще заточить все это под GDB -- была у меня такая лихая идея. Но сложность её я не оценивал. А так да, можно было бы тогда отлаживать в прочих IDE, например в Qt Creator. По драйверам. PTI_*, TRG_* -- это более низкий уровень взаимодествия с железом, и моему разуму он оказался не подвластен. Когда в своё время я обменивался своими мыслями с Сергеем Марковым aka SM, он как раз рекомендовал ломать протокол на более низком уровне, что бы не переписывать высокоуровневые драйвера под каждую платформу. В то время он уже перешёл на светлую сторону Силы под крыло Sauris, поэтому эта тема для него актуальность потеряла, у него уже был доступ к SEPK (или как он там называется). Я пошел-таки своим путем, что позволило мне добиться неплохих результатов по скорости обмена данными (на мой субъективный взгляд). По эмуляции. Я экспериментировал с тремя семействами: C64хх (не плюс), C55xx, C28xx. Для них удалось реверсить содержание JTAG-цепочек таких распространённых операций как чтение/запись в память/регистры ядра, установка/снятие точек останова, запуск/останов программы и т.п. Не удалось до конца познать суть инициализационных цепочек, а также назначение всех разрядов регистра статуса (я о нем упоминал в статье). По поводу "подёргать ножкой". Я в boundary scan не силён, для этого действительно есть специальные инструменты, BSDL-описания, в общем с эмуляцией граничное сканирование объединяет лишь одно -- физический интерфейс JTAG. В остальном это весьма разные вещи. По граничному сканированию рекомендую обратиться к знаниям ув. iosifk: http://iosifk.narod.ru/ Вы даже можете пообщаться с ним лично, ранее он бывал на этом форуме. Ну а в остальном я готов проконсультировать в любых вопросах, на которые знаю/помню ответы. Правда род моей деятельности сменился, поэтому я сейчас от этого несколько далёк
  9. Цитата(DSIoffe @ May 25 2015, 16:25) Здравствуйте все! Я выбираю видеопроцессор. Кстати если есть интерес "поиграться", где-то у меня валялась LeopardBoard (http://designsomething.org/leopardboard/default.aspx/) и несколько модулей-камер. Завтра постараюсь уточнить, какой именно там стоит процессор. Могу одолжить, так как все равно без дела лежит. [attachment=92807:IMG_0296.JPG] Цитата(Edmundo @ May 28 2015, 11:59) Завтра постараюсь уточнить, какой именно там стоит процессор. DM355, к сожалению...
  10. Цитата(QuadMan @ May 21 2015, 14:56) Модель SMJ320F2812HFGM150 - это керамический F2812. Адреса бывают разные, то 0x8000, то другой (уже не помню) Сейчас откатился на CCS 5.5 (и TI Emulation Package 5.1.232) все работает отлично... вот и думаю.. Мне кажется, что дело в версии компилятора, а не среды. Вы бы все-таки посравнивали map-файлы. Возможно, у Вас настройки линкера какие-то пограничные, тогда это может всплыть в будущем.
  11. Цитата(QuadMan @ Apr 30 2015, 16:37) Обновился на новый Code Composer Studio (6.1.0.00104) и перестал работать программатор SAU XDS510-USB Lite (и SAU 510-USB Iso Plus) при работе с TSM320 (использую Compiler Tools 6.4.4). Теперь при попытке отладки пишет С28xx: File Loader: Verification failed: Values at address XXXX do not match. Please verify taget memory and memory map. У меня одного так? Скорее всего, так как на проблемы программатора это мало похоже. Смотрите выходной .map-файл и сравнивайте его с memory map процессора. "address XXXX" какой конкретно? Ну и модель камешка не помешала бы (подозреваю, что семейство С28х ).
  12. Цитата(Aleks37 @ May 6 2015, 06:57) в продаже? Прошу прощения, давно не был на форуме. Да, плата в продаже.
  13. Цитата(Bob4ik @ Mar 23 2015, 20:04) Проблема состоит в следующем. Для отладки XDS510 приведенной на рисунке ниже не удается поставить драйвера под Win7. В WinXP все работает норм. Скачивал различные драйвера с сайта BlackHawk, ставил Code Composer 5, который якобы должен содержать дрова. Ничего не помогает. Может кто сталквиался с такой проблемой?? или есть мысли на пути решения проблемы А почему вы качаете с сайта Blackhawk? Мне кажется это клон Seed (http://www.seeddsp.com/eng), по крайней мере раньше китайцы любили клонировать именно его. Посмотрите VID/PID, чтобы это уточнить.
  14. Цитата(sonycman @ Jan 9 2015, 14:52) Покупать 510 или тем более 560 за 50 тысяч рублей почему то желания нет Если бы подешевле найти... Прошу прощения за скрытую рекламу