если в студии Reset Emulator не активен, то надо из консоли "xdsprobe.exe -rv -f ccBoard0.dat", а этот .dat я писал выше где искать. а сам утиль (xdsreset.exe кстати тоже) лежат в ccsv5\ccs_base\common\uscif\ и запускаться должны именно оттуда.

Эмулятор открывается, как я понимаю, при запуске каждой дебаг сесии, и закрывается при ее терминейте. Хотя, по логике, должен бы открываться при connect target и закрываться при disconnect. Возможно, моменты открытия и закрытия могут быть разные для разных таргетов.

Но при этом один и тот же эмулятор могут открыть одновременно несколько дебаг сессий, одновременно дебаг сессия и еще другие процессы, вообще не являющиеся композером (ну например SAUFlash), ну и т.п., так как эмуляционный стек умеет давать доступ разным средствам к разным девайсам, находящимся в одной JTAG-цепочке через один эмулятор, и при этом они типа как корректно расшаривают эмулятор, стек рулит JTAG-маршрутизаторами (icepick и т.п.) на лету. Так что невовремя сделанный резет может убить наповал кого-то другого, кто в это время подключен через этот же эмулятор к чему-то там в цепочке. С этим надо быть осторожным

Докучи после нежданных резетов стек может оказаться рассинхронизированным с состоянием icepick-ов/DAPов... А это вообще дебри, непонятно к чему могущие привести.

--------------------------------------------------------------
Добавлю:

в 5.2 можно выполнить резет проще, не надо самому искать этот .dat и указывать его утилите через ключ -f, как это было во времена 3.3, а можно так:

xdsprobe -rv -f:0

он сам найдет этот ccBoard0.dat (для ccBoard1.dat -f:1)

Хм. Вы меня пугаете.

1) У меня нету навороченной цепочки - ровно 1 таргет.
2) Врут, нифига не работает -f:0 в 5.2. Написать-то можно, но я так и не понял, по каким правилам оно ищет. В итоге просто тупо дал ссылку на -f<path>/ccBoard0.dat, и тут:



В этот момент у меня композер повис на операции fill memory, минут 10 его дожидался, так и не смог... Хотел ресетнуть со стороны и фиг, занято. Я не исключаю, что ваш рецепт выше упрется в ту же проблему.

И еще. Как в этом дурацком CCS5.2 приконнектиться к таргету, не загружая в него никаких программ и не выдвая ему ресет? раньше вон в 3.3 просто до безобразия, жмешь Alt+C и готово. А тут, блин, ничего непонятно. То ли проект пустой ему нужно создать, то ли что. При попытке открыть дебаг сессию у него все чешется что-то загрузить в таргет, иначе он даже коннектиться не хочет к нему. Бред какой-то... Я вот хочу полазать по регистрам, поотлаживать родную загрузку АIS-овских скриптов...

зависон на fill memory это совсем другое. Это понятно, что жтаг-контроллер зашарен в это время, и резетнуть его не удастся. Это часто лечится наглым выдиранием УСБ-шнура, но CCS после этого далеко не всегда реанимировать удается. Ну очень глючный у них там дебаг сервер. А в том случае Вы тормозили дебаг сессию "красным квадратиком", после чего контроллер должен быть свободен.

Приконнектиться к таргету очень просто. Запускаете CCS, проектов не должно быть открыто. Потом View->Target Configurations, выбрать нужную, правая кнопка мыши, и launch ей. Далее после перекура коннект к таргету. (теперь Ctrl-Alt-C). Ну или File->New target configuration, далее ее создать, сохранить, и далее к началу пункта.

Да, про кто что когда открывает. Вот драйвер C55x не открывает железного драйвера, пока коннест не сделаешь, то есть просто запустить дебаг сессию мало, надо еще приконнектиться. Тоже касается драйвера С64 (С6416). Проверил - дебаг сессия стартует вообще без подключенного в УСБ эмулятора, до коннекта железо не нужно. Резеты сделаю в драйвере в течение недели. Потом на бета-тестирование пришлю.

Hoodwin,

просьба протестить... Резеты для Вас сделал. Ну и так, куча доработок в сауфлэш и TCLXDS

В форум дистр не лезет, просьба написать на почту "sauris подчеркивание support собака scanti точка ru" - я скажу где взять

Вот, положили на саурис. (пока сылка только тут, версия еще бета)

http://sauris.de/product_files/sau510usb_I...ll-v1.2.1.0.zip

Что нового:

----- v1.2.1.0. 17-Jul-2012
+ TCLXDS: Added support for:
ARM11
ARM CortexM3
ARM CortexM4
ARM CortexR4
ARM CortexA7
ARM CortexA8
ARM CortexA9
ARM CortexA15
TMS320C54x/xx
CoreSight DAP, DAP_PC
ICEPICK-D
+ TCLXDS: New function: write_mem_coff
* SAUFlash: some changes for compatibility with new TCLXDS ARM7 drivers
+ SAUFlash: new comamnd - "erasesectors". Accepts list of sectors to erase:
Examples:
1,2,3 erase sectors 1,2 and 3.
1,5-7 erase sectors 1, 5,6,7.
-4,8,9 erase sectors 0,1,2,3,4, 8,9
-2, 5- erase sectors 0..2 and from 5 to end of memory
* Windows driver: Added hardware emulator reset when:
- It is first time opened
- It is last time closed
- After bootup of driver

Здравствуйте.

Имеются отладочные комплекты DM37x Evaluation Module (на базе DM3730) и AM3517.
Интересует работа только с ядром Cortex A8 (в случае с DM37x Evaluation Module), т.е. поддержка эмулятором двух ядер не требуется.
На первом этапе нас интересует работа с голым железом, в дальнейшем с Linux.

1) Возможна ли работа с ними из под CCS 5.x (в частности 5.01) с помощью вашего эмулятора SAU100-USB (v.2)?
2) Если "да", то чем вариант SAU100-USB (v.2) хуже варианта SAU510-USB ISO PLUS JTAG Emulator?
(!) Особенно интересует насколько SAU100-USB (v.2) "тормознутее" по сравнению с SAU510-USB ISO PLUS JTAG Emulator. Например, при просмотре дампа памяти, регистров и т.п.


Заранее благодарю за ответы.

1. С ядром Cortex-A8 работать будет, в составе чего бы это ядро не было бы.
2. Ну во первый SAU100 тормознее по определению (это банальная FTDI FT2232H). При просмотре дампов разница в скорости незначительна, там оверхеда больше, чем передачи данных, и 1 МГц на TCK, или 15, особо без разницы. Во вторых SAU100 не имеет гальваноразвязки, то есть с ним надо очень осторожно, втыкание "на горячую" может привести к смерти чего либо, если имеется хорошая разность потенциалов, то есть надежность SAU510 на порядки выше. Ну и в третьих SAU100, как и все XDS100, не поддерживают RTDX вообще. В четвертых, если это важно, XDS100 в принципе не поддерживает чтение EMUх пинов, поэтому часть функций профайлера, использующих EMU0/1 для подсчета событий, не работают. В пятых, тоже если это важно, XDS100 не умеет работает от внешнего клока на TCKR, только от TCK, геренируемого самим эмулятором. Ну вот как-то так.

Очередная бета для виндовс: http://sauris.de/product_files/sau510usb_I...ll-v1.2.1.1.zip
исправили багу в работе с DAP с Cortex-M

И теперь есть SauFlash и TCLXDS для Linux!!! Пока тоже бета. Причем поддерживает все семейства, что и под виндовс (никаких урезаний в поддержке, как в композере)
http://sauris.de/product_files/sau_drv-0.1.0.tar.gz

Большая просьба линуксоразработчикам, обладающим SAU510, протестировать данный комплект драйверов, особенно его инсталляцию в разных дистрибутивах, находит ли композер, правильно ли прописывает себя в udev, ну и т.п.

SAURIS GmbH

Я сейчас в отпуске, доберусь до работы к концу июля, тогда отпишусь и проверим.

Очередная Linux бета.
Оказалось, что в Linux-драйверах забыли поддержать эмулятор, разведенный на борту AM3517/05 SAU-Module development kit.

http://sauris.de/product_files/sau_drv-0.1.1.tar.gz

Еще одна бета. Скорее всего кандидат в релиз.

http://sauris.de/product_files/sau_drv-0.1.2.tar.gz

Была проблема с тем, что если в системе уже есть TCL 8.5, то TCL, который в составе пакета, не видел свою либу TCLXDS, так как лез за расширениями в "системный" TCL.

А вот и кандидаты на релиз.

Подчистили еще некие глюки в резете железа эмулятора, и так, по мелочи.

http://sauris.de/index.php?page=news&id=24&lang=ru

Добрый день!
Помогите разобраться.
При попытке коннекта с C6722 выдает сообщение:
C672X_0: Error connecting to the target: (Error -1063 @ 0x6012E) Device ID is not recognized or is not supported by driver. Confirm device and emulator configuration is correct, or update device driver. (Emulation package 5.0.663.0)
Конфигурация:
Code Composer Studio 5.2.0.00044
Windows XPx32
SAU510-USB JTAG Emulator IsoPlus драйвер sau510usb-v1.2.1.2

В подавляющем большинстве случаев эта ошибка вызвана некачественными сигналами (а именно TCK/TCK_RET). Исправляется включением или выключением терминаторов, либо изменением частоты TCK, все это в настройках эмулятора в target configuration меняется. В более редких случаях это может быть вызвано некорректным напряжением на пине PD эмулятора (например туда заведено 5 вольт, при том, что требуемые уровни JTAG 3.3 вольта), либо могут быть проблемы с RESET процессора (например его кто-то дергает внешним вачдогом).

Есть программатор сау510-юсб исоплюс, есть омап L138. Как воспользоваться sauflash для записи прошивку в память проца? Нигде не нашёл мануала.

Дока на нее лежит в c:\sauris\doc, называется sauflash-ug.pdf

Однако под l-138 нет готового порта, так что в том виде, который в 1.2.1.2 так сразу зашить не получится.

Надо портировать sauflash под него:
1) написать/поправить все необходимые скрипты инициализации.
2) пересобрать target code под проц.

Готов это сделать, если Вы готовы посотрудничать в отладке - у меня нету таргета на L-138, чтобы сделать порт полностью самостоятельно, для этого необходимо наличие ICQ/Mail Agent ну и желание и возможность.

Давайе попробуем. Стукнул в ICQ.

Я отсутствовал с четверга и по вчера. Сорри. Теперь в онлайне

Здравствуйте!

Недавно вышла новая версия CCS - 5.3 - так в ней не подхватывается ваш программатор (SAU510 USB ISO Plus)... посмотрите, пожалуйста.

Спасибо

Сделали.

Пока на сайте нет, вот-вот.... Если надо вчера, пишите на sauris _ support "червяк" scanti . ru, я инсталлятор пришлю.

Да нет, спасибо! Я опять на старую перешел пока.. подожду, когда на сайте выложите.

Как хотите, там исправлен только инсталлятор, сами дрова без изменений остались.

Здравствуйте. Помогите разобраться

Есть следующий конфиг:
Ubuntu 12.10x64
user@user:~$ uname -a
Linux bob 3.5.0-19-generic #30-Ubuntu SMP Tue Nov 13 17:48:01 UTC 2012 x86_64 x86_64 x86_64 GNU/Linu
ccsv5.3.0.00090
Sau510 linux drivers:
rev 0.1.3 27-jul-2012
Программатор SAU510-USB Iso+

Установка драйвера прошла без сообщений о ошибках.
При использовании утилиты xdsprobe получаю следующее:

[user@user:/opt/ti/ccsv5/ccs_base/common/uscif$ sudo ./xdsprobe -rv -f iso.dat
-----[Print the board config pathname(s)]------------------------------------
iso.dat
-----[Print the reset-command software log-file]-----------------------------
This utility has selected a 100- or 510-class product.
This utility will load the adapter 'libsm510usb.so'.
An error occurred while soft opening the controller.
-----[An error has occurred and this utility has aborted]--------------------
This error is generated by TI's USCIF driver or utilities.
The value is '-141' (0xffffff73).
The title is 'SC_ERR_KNL_OPEN'.
The explanation is:
This utility has failed to open its kernel mode driver.
Either it has been disabled or an install/un-install failed.

Соответственно не работает и в композере,
но уже с другим сообщением:

Error connecting to the target:
(Error -600 @ 0x0)
A required dynamic library could not be located.
The library isn't on the search path.
(Emulation package 5.0.872.0)

"Ошибка 600" устранили буквально вчера, ее ноги растут из бывшей несовместимости с новыми дистрибутивами Linux именно из-под ccs 5.3. Ждите обновление драйвера до 0.1.4 - сегодня должны выложить, сюда тоже загружу.


SC_ERR_KNL_OPEN - это хуже.... После втыкания эмулятора в USB udev должен запустить "sau_proxy" (правило в /etc/udev.d/71.sauris-rules) - проверьте, делает ли он это, в списке процессов должен появляться этот процесс. А также посмотрите на реакцию светодиода ACT (если iso - то зеленая его часть) после втыкания он какое -то время должен светиться, потом погаснуть, что свидетельствует о том, что udev увидел эмулятор и загрузил в него софт. Если этого не произошло, надо разбираться, что там у вас с udev

Благодарю за "наводку"

При подключении светодиод ACT (зеленный) активен буквально секунду. С udev разбираюсь, что и почему не запускает.

Это говорит о том, что udev по крайней мере запускает "sau_load", и первый этап подключения эмулятора проходит. Затем (как светодиод погас) эмулятор выполняет переподключение к USB уже с другим VID/PID, после чего udev должен на него повесить "sau_proxy", который, в случае удачи, создает в /dev/shm объекты с "sauris" в имени, по их наличию можно судить, что прокси "села" корректно (через эти объекты с ним и общается CCS и xdsprobe).

еще lsusb Вам в помощь - можно глянуть, что там и как на шине.

Когда разберетесь в истинных причинах, готов поправить инсталляционный комплект, чтобы у других такого больше не было.

День добрый.
под win7x64(этот же ноутбук ) и ubuntu10.04x32 разумеется все работает
Пересобрал libusb-1.0.9 в i386, ситуация не изменилась.

Состояние udev послеподключения прогграмматора
usr@usr:~$ udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[5852.820837] add /devices/pci0000:00/0000:00:14.0/usb3/3-4 (usb)
KERNEL[5852.820900] add /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.0 (usb)
UDEV [5852.845458] add /devices/pci0000:00/0000:00:14.0/usb3/3-4 (usb)
KERNEL[5852.847020] remove /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.0 (usb)
KERNEL[5852.847233] remove /devices/pci0000:00/0000:00:14.0/usb3/3-4 (usb)
UDEV [5852.855467] add /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.0 (usb)
UDEV [5852.856121] remove /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.0 (usb)
UDEV [5852.862346] remove /devices/pci0000:00/0000:00:14.0/usb3/3-4 (usb)
KERNEL[5910.345483] add /devices/pci0000:00/0000:00:14.0/usb3/3-4 (usb)
KERNEL[5910.345655] add /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.0 (usb)
UDEV [5910.368942] add /devices/pci0000:00/0000:00:14.0/usb3/3-4 (usb)
UDEV [5910.378172] add /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.0 (usb)

usr@usr:~$ lsusb
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 003 Device 110: ID 17ba:0511 SAURIS GmbH SAU510-USB Iso Plus JTAG Emulator
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Попробуйте запустить sau_proxy руками. Для этого откройте терминал с правами рута, и там "/opt/sauris/bin/sau_proxy bus/usb/<BUS>/<DEV>"
где <BUS> <DEV> цифры из lsusb - ваш пример "/opt/sauris/bin/sau_proxy bus/usb/3/110"

Ну и гляньте, что скажет. А то это дюже странно, что sau_loader работает (это уже показатель, что с libusb все ОК), а sau_proxy - нет.

И еще гляньте, чтобу в списке у mount (без параметров) числился /dev/shm, из-за этого runproxy может застрять в ожидании, если вдруг он не подмонтирован.

usr@usr:~$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda7 375G 119G 237G 34% /
udev 3.9G 4.0K 3.9G 1% /dev
tmpfs 1.6G 928K 1.6G 1% /run
none 5.0M 8.0K 5.0M 1% /run/lock
tmpfs 1.5G 76K 1.5G 1% /run/shm
none 100M 20K 100M 1% /run/user
/dev/sda5 118G 67G 51G 58% /media/DATA
/dev/sda6 123G 49G 75G 40% /media/DATALIN
/dev/sda2 100M 25M 76M 25% /media/System_Reserved
/dev/sda3 79G 40G 39G 51% /media/sda3
usr@usr:~$ lsusb
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 003 Device 002: ID 17ba:0511 SAURIS GmbH SAU510-USB Iso Plus JTAG Emulator
usr@usr:~$ sudo /opt/sauris/bin/sau_proxy bus/usb/3/2
[sudo] password for usr:
nbus=3, ndev=2
Device found!
Device opened.
Device SN=#002050; configuration=#1
This is first instance of proxy
Initializing proxy, instance #0
Clearing halt/stall
Resetting TBC
INIT successful
Waiting for requests

sau_proxy работает. Запускайте CCS и коннектитесь к таргету, никаких SC_ERR_KNL_OPEN при запущенном sau_proxy быть не должно.

А проблема Вашего дистрибутива в том, что shm с какого-то перепуга находиться в /run/shm вместо /dev/shm. Исправьте /opt/sauris/bin/runproxy под это дело - он безуспешно ждет пока у Вас подмонтируют shm в /dev/shm. В будущем я учту, что shm может быть и не в /dev. (ожидание там обязательно! Иначе без него не будет оживать эмулятор, если он был подключен к УСБ до загрузки ОС)

на xdsprobe
This utility has selected a 100- or 510-class product.
This utility will load the adapter 'libsm510usb.so'.
The library build date was 'Oct 3 2012'.
The library build time was '23:19:44'.
The library package version is '5.0.872.0'.
The library component version is '35.34.40.0'.
The controller does not use a programmable FPGA.
The controller has a version number of '1' (0x00000001).
The controller has an insertion length of '16' (0x00000010).
This utility will attempt to reset the controller.
This utility has successfully reset the controller.
-----[Print the reset-command hardware log-file]-----------------------------
The scan-path will be reset by toggling the JTAG TRST signal.
The software is configured for only TBC features.
The controller is the production TBC (74ACT8990).
The software is configured for only TBC features.
The controller has been hardware reset via its utility logic.
The controller has been software reset via its utility logic.
The controller has been successfully accessed.
The software is configured for slower clock operation.
The controller has a logic ONE on its EMU[0] input pin.
The controller has a logic ONE on its EMU[1] input pin.
The controller will use rising-edge timing on output pins.
The controller cannot control the timing on input pins.
The scan-path link-delay has been set to exactly '3' (0x0003).
The utility logic has detected a previous power-loss.
The utility logic is not currently detecting a power-loss.

студия

Error connecting to the target:
(Error -181 @ 0x0)
The controller has detected a dead JTAG clock.
The user must turn-on or connect the JTAG clock for the target.
(Emulation package 5.0.872.0)

Спасибо, заработало, во всяком случае в таргет образ залить удалось.

Это два варинта - либо организовать подачу клока, по которому работает JTAG таргета, на TCK_RET (RTCK), его там явно нет, например перемычкой на TCK. Либо в настройках таргет конфигурации указать "Target doesn't provide TCK_RET clock" (как-то так, точно не помню), если таргет спроектирован так, что принципиально не выдает TCK_RET, а может работать только по TCK. Тогда в эмуляторе внутри включится "виртуальная петля" TCK-TCK_RET с некоей задержкой, близкой к той, которая в реальной петле при закоротку на разъеме.

Благодарю за своевременную и профессиоанальную консультацию

Прошу прощения, разумеется за Профессиональную консультацию

Добрый день.

Недавно столкнулся со следующей проблемой:

Не шьётся проц (точнее даже два на одинаковых платах) TMX320F28069, пишет ошибку "C28xx: Flash operation timed out waiting for the algorithm to complete. Operation cancelled.
C28xx: GEL: File: D:\..\***.out: Load failed."
Во время прошивания происходят "зависания" в моменты Erase и Loading, то есть полоса не ползёт как обычно, а стоит на месте. После чего и получаем выскакивающее окошко с магической фразой "Load program Error"
Есть подозрения что возможно надо что-то поправить в Target configuration, хотя вариант что я спалил статикой два проца тоже не отметаю пока. До этого шились нормально. Такое началось после обновления композера кажется.
Композер последний, драйвер Сауриса тоже последний. Да, Саурис 510 Iso Plus.

Если ничего не поможет, буду отправлять в помойку процы, благо этих TMX ещё целое ведро новых.

TMS320F28335 шьётся нормально.

Скриншот глюка выглядит так:

Попробуйте предыдущим композером прошить, который шил, если прошьет - все ОК. Если не прошьет, то и микросхемы, и новый композер - в помойку. Таргет конфигурейшн нет смысла менять, если все работало надежно с предыдущим композером - обычно все "слеты", связанные с настройками таргет конфигурации, выливаются в ошибки эмуляционного стека со срывом дебаг-сессии, а тут налицо (если не физическая смерть проца) банальный глюк алгоритма прошивания флеши.

Разобрался с проблемой.
Оказалось что это непонятный глюк файла Target configuration, удалил старый, создал новый, и всё заработало.

Так вот бывает, оказывается.

Вот снова вопрос задам. Давеча имел неосторожность воспользоваться automatic update в CCS 5.1. И он таки задумался, часа на 4, долго качал новую версию 5.3.0.0089, обновлялся, а потом сказал ква и приказал долго жить. Что-то у него внутри в джаве сломалось, и в итоге он не собирает и не запускает отладку. Более подробное описание тут:
http://e2e.ti.com/support/development_tool...1/t/234249.aspx
В общем, если кто будет иметь похожую ситуацию, имейте ввиду.

Продолжение истории было такое. Вчера, по совету из вышеприведенной ссылки снес вообще CCSv5 и установил 5.3 заново. Вроде даже с виду работает, и с MSP430 поработать удалось. А вот с C6000 - пока нет. Оказалось, что драйверы, поставленные в предыдущей версии, он не подхватил.

Тогда я скачал вот этот дистрибутив:
http://sauris.de/software-documentation/sa...ll-v1.2.1.4.zip
и установил его, разумеется уже после CCS 5.3. Но он при установке написал только что он успешно добавил драйверы в Progfram Files\Texas Instruments\..., а там у меня стоит древний CCS 4.2, а CCS 5.3 теперь живет в c:\ti\...

ВОПРОСЫ:
1) А вообще-то последний драйвер должен в 5.3 работать?
2) И как его поставить?
3) Почему он сам не добавился в 5.3, а только в 4.2?
4) Должен ли он сам находить все дистрибутивы CCS, или только первый попавшийся?
5) Почему в руководстве по установке картинки только от CCS 3.3?
6) Существует ли более подробное описание, какие версии драйвера SM510 с какой версией какого CCS должны дружить?

1) Должен. По крайней мере в 5.3.0.00090 встает.
2) Ну надо выяснить, почему он не увидел 5.3
3) Видимо он его не увидел. Чтобы он его увидел, необходимо и достаточно, чтобы в хитром директоррии, %USERPROFILE%\ti\CCSExternalReferences\ находился файл CCS_<version> (например CCS_5_3_0_00090) внутри которого пара строк - product=ccs и path=c:/где/он/с/юниксовыми/слешами (например path=G:/CCS5.3.0.00090/ccsv5 или path=С:/ti/ccsv5). Видимо, этого файла у вас инсталлятор CCS не создал ввиду некорректного его завершения. Можете создать его вручную. Однако, его отсутствие скорее всего приведет и еще к каким нибудь последствиям кроме невидимости дровами саурис - в этой папке не только ccs отмечается ссылкой на себя, а и некоторые другие его запчасти.
4) Должен все, начиная с древнючего CC 4.10 для VC33, и всех 2-х, 3-х, 4-х и 5-х, сколько бы их не стояло вне зависимости от типов лицензий на них.
5) Ну видимо других не было
6) В c:\sauris есть "changelog" - там отмечено, в какой версии что менялось, он ведется со времен начала поддержки 4.2. До этого такой информации не было. Поддержка старых CCS и CC не отменяется, и отменяться не планирует.

1) Я ошибся, композер действительно версии 5.3.0.00090 установлен.
2) Готов выяснять, что нужно для этого делать?
3) Хм. В моем профайле вообще нет директории %USERPROFILE%\ti\CCSExternalReferences\. Такое есть в C:\Documents and Settings\Администратор\ti\, видимо потому, что я ставил композер из-под администратора машины, а использую из-под пользователя. Ну, я всегда так работаю , и оно до сих пор как-то работало, скажем в 5.1. этой проблемы не было. Далее, в профайле администратора есть только такие файлы:
Содержимое папки C:\Documents and Settings\Администратор\ti\CCSExternalReferences

Про некорректное завершение установки он не говорил. Сказал, что установился и все. Пока никаких других артефактов не замечено, с MSP430 он сразу задружил через MSP-FETU430IF, например.
4) А вообще Вы проверяете, что композер работает корректно не из-под админа? Я как-то помню с CCS 3.3 долго воевал, чтобы его научить работать из-под пользователя, пришлось в винде аудит повключать на диски и реестр, чтобы узнать, на что ему реально права нужны. Первые версии CCS 5 вроде бы и так у меня работали, только нужно было workspace и проекты создавать из-под пользователя, чтобы права на эти файлы потом были.
5) Вообще дело конечно не в картинках, а в том, что процедура установки и ее troubleshooting для версий 4 и 5 как-то совсем не прописана. Хотя оно там значительно более заморочено и интуитивно гораздо менее понятно.
6) вижу в changelog, что поддержка 5.3 появилась в ноябре 2012 в версии 1.2.1.3.

3)Ставить дрова саурис надо (наверное) значит тоже из-под администратора, тогда установщик сауриса увидит этот раздел диска. Однако это новое веяние по технологии установки, Вы видимо первый так ставите, а первопроходцам всегда нелегко . Обычно виндовый CCS устанавливается из-под того юзера, кто работает, после чего корректно устанавливаются драйвера сауриса. Если же ставить CCS из-под администратора, а дрова саурис потом из-под юзера, то он сугубо по нехватке прав залезть в раздел данных администратора не найдет данные об инсталляции, даже если попытается их там искать.

В директории должно быть как-то так (у меня три инсталляции 5-х композеров для тестов):

21.11.2011 18:04 36 CCS_5_1_0_09000
27.07.2012 23:25 43 CCS_5_2_0_00069
29.11.2012 11:37 43 CCS_5_3_0_00090
21.11.2011 18:34 114 dmed_00_00_00_01
27.07.2012 23:39 128 dmed_01_00_05_00
29.11.2012 12:28 128 dmed_01_01_00_00
29.11.2012 12:23 76 hercules_5_3_0_1
21.11.2011 18:04 88 msp430ware_0_00_00_10
12.06.2012 16:36 95 msp430ware_1_10_02_21
29.11.2012 11:37 95 msp430ware_1_25_00_30

внутри CCS_xxxxx:
product=ccs
path=C:/ti/ccsv5

если этого файла нет, значит инсталляция CCS не заврешилась, именно отсюда и вывод о некорректной инсталляции - файл ДОЛЖЕН БЫТЬ - другого способа найти где установлен 5-й композер нету.

4) Я как раз ни разу не проверял, работает ли композер при инсталляции из под админа вообще, и не слышал до сих пор про такие прецеденты - никто не просил пока. А они бы были... Эмуляторов то немало по белу свету ходит - теперь вот задача на будущие версии дров, как-то умудриться находить инсталляции композеров, сделанные из-под админа, при запуске дров из-под юзера. И наоборот, при запуски инсталляции дров из-под админа искать все установки композеров из-под юзеров. Впору просмотр диска поиском делать что ли... Или спрашивать юзера, а есть ли у него еще композеры, кроме автообнаруженных... Жесть в общем.

Так я и драйверы Sauris ставил из-под администратора. Вообще не так много программ ставятся нормально из-под юзера с ограниченными правами. А если ставятся, то не работают из-под другого юзера. Если же ставить из-под админа, то, как правило, 1) программы ставятся, а 2) они потом еще и работать могут под любым аккаунтом. Бывают, правда, дурацкие программы, которые вообще без админских прав работать не могут, потому что коряво спроектирвоаны. Раньше, например , композер 3.3 был такой. Он без админских прав не ставился, а из-под пользователя не работал.

Только вот есть небольшая разница. Сам композер я поставил, залогинившись в администратора, а вот драйверы я уже ставил из-под пользователя с помощью runas, указав там аккаунт админа. Правда, мне попадались случаи, когда это не работало правильно. Я досконально не копался в причинах, но, кажется там дело в том, что при работе из админа программа с правами админа запускается с правами админа в консоли админа, а если я пользуюсь runas, то там программа запускается в справами админа в консоли пользователя, и поэтому некоторое окружение она может видеть неправильно, так как реального входа в систему из-под админа не происходит.


Ну, а как я могу проверить, что не завершилась, если она завершилась сама со словами, что все поставилось, нажми кнопку Finish?

4) Ну вот, прецедент. Может реестр поглядим? Куда смотреть?
Ну и потом, есть еще такая тема как "C:\Documents and Settings\All Users\", можно туда ставить все штуки, а не в userprofile, и тогда все юзеры могут пользоваться композером. Или предлагается нынче 7ГБ (sic!) CCS 5.3. ставить копиями для каждого пользователя?

Некуда в реестр смотреть... В реестре он перестал отмечаться начиная с версии 5.0 (UPD: ошибся, с 5.1) Тогда же он стал отмечаться о себе в юзерпрофайле. Могу лишь попросить найти, где он установил это файл "CCS_5_3_0_00090" - может, например, в "All users", или еще где то, мало ли, куда он его пихает при инсталляции из-под админа. Кстати, "msp430ware" тоже нету. Если его нет нигде, то единственным выходом (кроме полного сноса CCS и установки заново, чтобы этот файл появился) будет указание дополнительно установленных CCS, если они не обнаружены автоматически, но это требует времени на правку инсталлятора. А в данном конкретном случае, пожалуй, единственный выход создать этот файл вручную.

Я знаю, про All users, но это не ко мне, это в TI. У меня задача - найти инсталляцию, путь к ней и ее версию. И если сделано в композере "вот так вот", то тут уже ничего не сделать, и они не будут ничего делать такого, чтобы нам, 3-им сторонам, было проще.

Или, возможно, не установлен какой то важный кусок композера, который как раз за собой оставляет этот файл....

П.с. всю жизнь ставлю композеры из-под юзера... и 3.3 в том числе, и 2.х... никогда не замечал, чтобы что то не так работало. Правда я себя уважаю и люблю, поэтому добавляю в группу "Администраторы"

Хм. Нигде его нет. Странно это. Я же его ставил именно после полного сноса V5.1. А Версия 4.2 - осталась стоять, так как на нее раньше была куплена node locked лицензия

Судя по всему не полного, раз "dmed_00_00_00_01" там остался... Это шмоток от 5.1. Хотя, по тому, как у меня - этот файл от сноса не зависит, он параллельно для каждой инсталляции создается.

Как вариант, это какая-то бага инсталлятора TI... При установке из-под администратора не создавать этот файл. Но если так, то все, финиш, потому что это все недокументировано, официального способа найти инсталляции композера нету (даже нам, при том, что у нас есть полная информация о том, как их JTAG работает в самых его недрах вплоть до битов внутренних регистров и исходников драйверов эмуляции *.dvr).

UPD:

а в dmed_xxx у Вас путь внутрь композера есть? Как вариант, в следующий инсталлер я добавлю сканирование всего содержимого этой папки на предмет поиска композеров...

Сейчас снес композер из-под админа. Ну, прямо скажем, в профиле ничего вообще не поменялось: те же три файла, файл dmed_01_00_05_00:

В c:\ti удалился только сам эклипс, а все остальное осталось:


Вопрос такой: ему руками нужно что-нибудь доснести в профиле, чтобы он без глюков поставился? И что именно, чтобы не развалить установку 4.2?
Вот есть такое:


PS: Блин, сколько проблем из-за одного корявого апдейта. Все ж работало в 5.1...

просто поставьте в C:\TI_5.3 например, причем в режиме полной установки, а не прописывания в существующий эклипс себя, а потом C:\ti снесите под ноль (если, как говорите, у Вас 4.2 стоит в program files где то, а не в C:\TI, его это не коснется, если конечно, потом в C:\TI вы не ставили каких нить компилеров или биосов, прописанных в 4.2), а в профиле ничего не надо трогать, они там друг другу не мешают. Проверено уже, установка в отдельную папку, которой не было, обычно помогает от всех болезней.

Кстати, "о птичках". При инсталляции в линукс и 5.1, и 5.2, и 5.3 инсталляторы тоже создают такие же файлы в ${HOME}/ti - видимо в целях кроссплатформенности. Не самая лучшая идея в *nix, хоть бы ".ti" директорий назвали бы, но что есть, то есть. Так что при корректной инсталляции файл появиться все же обязан.

Переустановил снова с нуля в папку C:\TI_5.3. В профайле опять ничего не появилось

Точнее, есть файлик hercules_5_3_0_1:

ну что же. раз так его на Вашей машине заглючило - вот архивчик привешиваю... Его надо раскрыть в соответствующее место коде композера (согласно иерархии директорий внутри архива), и все будет прописано. Ну, разумеется, и сами дрова сауриса должны быть проинсталлированы.

А вот есть еще такая интересная тема:


Сорри, что длинно, но я чтобы было понятно. Интересны файлики c именем key

Вот, например, содержимое C:\Documents and Settings\Администратор\Local Settings\Application Data\.TI\3116678785\0\key:

А вот содержимое C:\Documents and Settings\Администратор\Local Settings\Application Data\.TI\2067366409\0\key


То есть, вот там лежат пути ко всем установкам, которые у меня когда либо были. Из 4 файлов только 2 ныне живут. Но пути верные.

Кстати, еще добавление. После старта CCS 5.3 довольно быстро нашел все тулзы, поставленные в папку C:\Program Files\Texas Instruments\, C:\ti, то есть, у него где-то алгоритм поиска путей старых композеров есть. Причем он не успокоился пока я не дал ему их все добавить в свой список продуктов.