Да, только вот новую где взять - неизвестно. Думаю в России их вообще раз два и обсчелся. Кстати если кто с китами будет брать - например такая штука как SAM-ICE (то же самое на вид) , но залочена только на атмельские ID чипа :-D . Ну насчет reset на device ситуация аналогична. Я бы не стал его жать =) Если речь конечно о ненавистном "---------------------------
RDI Driver
---------------------------
USER ERROR

WinRDI CPUread R0-R14 failed

[RDI Error: 9] Error message should have been found on target
---------------------------
ОК
---------------------------
"
Тоже самое вижу, смею уверить

1. А как при заказе отличить???

2. О нем. Нет, если один раз - то можно и пережить, но ведь от десятков раз, до бесконечности
(передергивания питания MT-Link + еще десяток воплей :-( )

при заказе - понятия не имею. Спрашивать наверное. Сдается мне что совместимый с новой версией сделаю быстрее ;-)

Мужики, я временно в аут. Вы тут обсуждайте если чего, временная срочная работа есть, потом вернусь

Повторяем в меру понимания вышеописанное:

1. Работаем через RDI.
Запускаем, стоит брейпойнт на прерывании UART, выходим на прерывание, много много
раз выходим. Debug->Break. Подсвечивается выбор Debug->Reset. Жмем его - выпадаем на main()
Debug->Go - все заработало до срабатывания брейкпойнта. Так проделал 12 раз. Без проблем.

2. Теперь штатная поддержка J-Link.
Исходные условия и поект аналогичны.
Результат - тоже без проблем.

3. Потри прерываний наблюдаются только после Debug->Stop_debugging, Project->Debug,
Debug->Go.
Причем сейчас, когда брейпойнт СТОИТ - повесить не удалось (12 попыток).

3a. При запуске БЕЗ брейкпойнта (просто загрузка и в работу) - с третьего запуска поймал нерабочее прерывание UART.

Вот такой не добавивший ясности (мне) эксперимент......

вобщем явленеи еще и плохоповторяемое

Набрел на новый эффект. 100% повторяемость в моих :-((( условиях.

1. Стоит брекпойнт на UART. Но терминальная программа НЕ запущена.
2. Запускаем отлаживаемое устройство, получаем пачку брейков (передача), это все нормально
отрабатываем.
3. Запускаем терминальную программу - в момент запуска
сообщение:
Bad JTAG communication: Write to IR:Expected 0x01, Got 0x00 (Tap Command: 15)
Я полагаю, что какой-то мусор влетает в UART, но в данном случае расстраивает поведение
отладчика. Вне зависимости от выбранной реакции на данное сообщение устройсво продолжает работать а отладчик считает, что стоит на 0 адресе.
Сообщение не зависит от RDI или нет. Но при RDI - дополнительно бесконечные вопли о [RDI error: 9] c выходом через отключение MT-Link и тупое долбление

продолжаю повторять - в оригинале так же. Именно такого эффекта не ловил - хватило тех что увидел. Предлагю начать топик "Глюки segger-вского JTAG " а не отличия от мтлинка. По-крайней мере уверенно сейчас об этом только я могу говорить, как проверивший оба.

Топик не коим образом не указывает на отличия обеих Link, а говорит о проблемах с которыми
сталкиваешся при использовании MT-Link, как представителя одного из них.
Заявление о идентичности глюков прозвучало и принято к сведению.
Начать такой топик не могу, в виду отсутствия J-Link. Думаю, что можно продолжать......

потенциальный недостаток такого спора вижу в том, что начинающих может отпугнуть от использования МТлинка. В то время как пока единственный могу сравнить, вы же ведете нападение именно на мтлинк, хотя в оригинале присутвуют теже грабли

????
Я НЕ спорю и тем более НЕ веду нападение на MT-Link. Я описываю проблемы, зачастую неприятные, присущие MT-Link. Наличие аналогичных проблем у J-Link в некоей мере не отменяет их наличия в MT-Link. Нигде, никогда ни словом ни полсловом я не подвергал (и не собираюсь) сомнению Вашу информацию об аналогичном проблемном поведении двух линков. Едиственно, что мне можно "поставить в вину" это желание купить оригинальный J-Link. Обещаю, более не афишировать данные намерения на данном форуме. Если какая-то из замеченных проблем является грязной инсинуацией,
просьба указать мне на нее и давайте _вместе_ отделим мои проблемы от проблем MT-Link. На данный
момент я не получал от Вас такого рода замечаний и только вдруг это неожиданное для меня заявление о "нападении на MT-Link", которое я не могу воспринять иначе, чем обидное для меня прямое указание на лживость изложенных мною фактов.

ни в коем случае не хотел Вас обидеть. Извините если что не так. Просто пока что спор ни о чем, только константация фактов, причем нечетких. Никаких обид нанести не хочу и чуствую сам. Чтобы разрядить обстановку замечу что это наверное самый большой топик в электрониксе ?

1. C обидами - проехали.

2. Констатация фактов, причем _личных_ (читай возможно субъективных) с просьбой подправить и направить и являлась целью данного топика. Просьба перечитать первый пост, топик действительно разросся и может начало позабыто :-(. Все перечисленные факты (пусть и не четкие), на мой взгляд получили подтверждение от других участников, в том числе и от Вас. Для парочки найдены четкие и не
очень :-( решения.

3. На счет "самого большого топика" - не понял :-(

4. С своей стороны, дабы "разрядить обстановку" - НИЧЕГО СМЕРТЕЛЬНОГО препятствующего использованию MT-Link в МОИХ (описаны в первом посте)условиях на данный момент НЕ ВЫЯВЛЕНО.

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

Я эту позицию понял и не оспариваю.
Тем не менее глюки безотносительно к MT-Link есть :-( и помощь в их обходе (не обязательно от Автора MT-Link) при возможности получить или найти общими усилиями, что пойдет и на пользу MT-Link.

Вроде здесь мы уже по третьему разу начали повторяться при этом расписываясь в совершеннейшем
почтении (что есть совершеннейшая правда).

Все описанные глюки я буду пробовать продолжать локализовывать при выходе на реальную
железку.

Вот это, кстати, лучшее, что можно сделать.

А еще лучше - минималистический проект под стандартную распространенную EVB и метод, который на 100% позволяет воспроизвести глюк. Думаю что после его публикации где нибудь в листе lpc2000 на yahoo сеггер и без нас нагнут...

Не считаю возможным катить бочку на segger не имея оного :-(. Такими вещами на _данный_ момент может DASM заниматься (причем много более квалифицированно), но не я. Если представится повод -
общаться с segger несомненно буду. За мной не заржавеет. Если кому-то нужен языковой посредник
для общения с segger - могу выступить.

Поздравляю всех с Новым Годом.
А сейчас буду ругаться. Сильно.

Я понимаю, что это не в жилу, но, так как...
[zltigo]
Все нижеописанное изложено с целью:
1. Оградить только-только начинающих пользователей от неyжных стрессов и чрезмерных надежд.
2. самому получить совет от более опытных (в любой форме, например, дурак - поставь галочку и
больше никогда не жми эту кнопку).

.. то и я внесу свой рупь.

Короче, прошу прощения, но сильно хочется выругаться матом, - ЗАИБ.... меня такая ситуация.
Заказал я две штуки МТ-линков в конце октября (http://www.caxapa.ru/echo/arm.html?id=41956&todo=full&hilite=iit).
Контора у нас большая, поэтому пока раскачали начальство, то да се, в общем деньги нашим поставшикам ("Элко-ПРО" г. Томск) перечислили 20 ноября. Нам пообещали, что 30 ноября, гребанная (прошу прощения) МТ-СИСТЕМС вышлет что требуется.
Через неделю звоню в Элко-про - ответ: "Да, мля, выслали все в пути". Съездил я на Байкал (туда и обратно от Томска столько же, сколько от Томска до Москвы), вернулся, звоню - опять та же петрушка, типа, мля, все выслали скоро приедет. На чем едет-то? На собаках дохлых? Или на оленях? Еще через неделю звоню (заметьте, прошло уже три недели) менеджер поставшика извиняется, говорит что сам звонил в МТ-Системс, и там какой-то тип дал ЧЕСТНОЕ МУЖСКОЕ СЛОВО, что на следующей неделе все будет. Ну и кто он после этого, ну минимум не мужчина. А, блин...... Сегодня вот уже тридцатое декабря, до 15 января можно даже и не ждать.
Так что, начинающие (и не очень начинающие) пользователи,
не испытывайте ненужных стрессов и не питайте черезмерных надежд, улыбайтесь и будте счастливы в новм году

ну мужики, не ругайтесь сильно. Иногда я тоже МТ подвожу. То одного заказать не удалось, то шнуры USB кончились, тоже сроки динамлю. Правда не более недели. Вобщем будем терпимее, с Наступающим. Правда у Вас через посредика - кто его знает. Сама Мт при наличии на складе довольно шустро по России работает

Я тут закупил для своих нужд несколько JLINKов: с SAM-ICE, и с TMS470.
Прочитав вышеуказанное, на всякий случай попробовал под IAR:
1. JLINK от комплекта TMS470 работает с AT91SAM7S64
2. JLINK от комплекта SAM-ICE работает с LPC2138
могу попробовать с ADuC7020

странно, у меня не получилось, ну да не суть. Так упомянутые проблемы есть или нет ?

Вы именно SAM-ICE купили ? Синего цвета, при запуске JLink exe кроме серийника пишет OEM- SAM-ICE , Строка из dll которая у меня выдавалась "'SAM-ICE can only be used with ATMEL devices'"

Отменяется! Проблемы НЕТ - просто в попыхах оставил возможность сброса контроллера
от DTR :-( ну а дальше все свелось к неприятному поведению при аппаратном сбросе.....




Тем не менее.. Утром первого дня нового года решил начать новую жизнь и тоже повторить:
- Машина P3-733, WIN2000(со всеми заплатками), 512 RAM. Просто рабочая машинка достаточно
забитая всяким мусором за годы эксплуатации, но ничего от IAR ранее не стояло.
В домашних условиях запасе осталось еще два неопробованных компьютера с Windows :-).

- Добавлен USB 2.0 контроллер от VIA (дабы не заниматься исследованиями USB 1.x);
- Установлен EWARM 3.20A с генерацией лицензии;
- Установлен upgrade ewarm-430a-P051128.zip (без J-link DLL) c иаровского сайта;
- Установлен upgrade jlinkarmdll_v274c.zip c иаровского сайта;
- Установлены остальные (к делу отношения полагаю не имеющие ) upgrade:
iccarm-430a-P050906.zip
Xlink459T.zip
- Ничего от Segger пока _специально_ не ставилось.

Проект (чисто IARовский IDE ) просто взят с ноутбука (Centrino 1.8GHz), на котором ранее в основном все эксперименты и проводились.
- Опция "With runtime control modules" (перехват вывода на терминал и прочее) - ОТКЛЮЧЕНА.
- Опция "Run to main()" - ВКЛЮЧЕНА!

Результаты:
1. Компилится медленнее :-).
2. Добитьсяо сновного неприятного эффекта - потери прерываний на данный момент не удалось.
Все источники прерываний (Timer, UART, SPI, ADC, I2C, и внешние от двух кнопочек) отрабатывают нормально.
4. Ближайшие пару дней буду спокойно работать на данной системе в данной конфигурации.




Теперь ищем и находим грабли (я намеренно описываю последовательность ВСЕХ действий.
минимизация осуществлена позже):
- ВКЛЮЧАЕМ Опцию "With runtime control modules"
- при установленном брейкпойнте на 'main()' и где-нибудь на прерывании (например UART)
получаем вопль по поводу "Run to main()", жалобу на недостаток брейкпойнтов и предложение
либо долго пошагово топать, либо отменить "first instruction" (я понимаю это, как наплевать
на брейпойнт на main())
Рассмотрим оба варианта:
1. Пошли пошагово - виден обмен с MT-Link (мигает зеленый светодиодик) и спустя пару минут,
как и обещано, выходим на main(). При попытке продолжить Debug->Go, продолжаем, но
прерываний уже нет ни одного. Эффект абсолютно стабильный.
2. Выбираем "Stop" - предсказуемо выходим на 0 адрес. При попытке продолжить Debug->Go, продолжаем, но прерываний, как и в предыдущем случае, уже нет ни одного. Эффект абсолютно стабильный.

Продолжаем эксперимент:
- ВЫКЛЮЧАЕМ Опции "With runtime control modules" и "Run to main()" - получаем обратно два брейпойнта.
- Ставим оба - один на main(), второй на прерывание UART. Далее опять 'Debug-Go' ...
и.... все :-( прерывания отсутствуют, на брейкпойнт естественно на выходим, система привычно
циклится в IDDLE Task. Эффект абсолютно стабильный.

Совсем все упрощаем:
- НЕ ставим НИ ОДНОГО бейкпойнта. Предсказуемо выходим на 0 адрес. Далее 'Debug-Go' ...
и.... все...... Стабильная безвариантная, 100% повторяемая у меня ситуация :-( отсутствия прерываний.

Идем дальше:
- возвращаем "Run to main()" - все равно НЕ работает! При всех предыдущих манипуляцих
производилась перезагрузка IDE, тем не менее пререзагружаем IDE еще раз - не работают
прерывания. Выходим из IDE, передергиваем питание MT-Link, загружаемся..
РАБОТАЕТ! Ранее, при всех экспериментах, питание MT-Link не передергивалось,
ибо повода не было (Flash грузил без проблем).


Начинаем все с начала:
- отключаем "Run to main()" - прерывания пропали...
- перезагружаем IDE - прерываний нет
- выгружаем IDE, передргиваем питание MT-Link (при отключении питания MT-Link отлаживаемый
девайс перезапустился и заработал), загружаемся - НЕТ прерываний...
- включаем "Run to main()" - прерываний НЕТ;
- перезагружаем IDE - прерываний НЕТ;
- перезагружаем IDE с передергиваем питания MT-Link - ЗАРАБОТАЛИ!

Последний шанс - попробовать поиграться опциями J-Link 'Hardware Reset', 'Reset Asserts..', 'JTAG Speed', которые при предыдущих попытках ситуации не изменили, но следует попробовать еще раз
в случае более локализованом.

JTAG Speed = Auto, Inital - 10KHz
Hardware Reset = disabled
Reset Asserts = disabled

Неизменно плохой результат.

JTAG Speed = 400KHz
Hardware Reset = disabled
Reset Asserts = disabled

Неизменно плохой результат.


JTAG Speed = 1000KHz
Hardware Reset = disabled
Reset Asserts = disabled

Неизменно плохой результат.


JTAG Speed = 1000KHz
Hardware Reset = enabled, delay=500ms
Reset Asserts = disabled

Неизменно плохой результат.



JTAG Speed = 1000KHz
Hardware Reset = enabled, delay=50ms
Reset Asserts = disabled

OДНАКО! Заработало таймерное прерывание! И одно внешнее на FIQ. Остальные - НЕТ.

JTAG Speed = 1000KHz
Hardware Reset = enabled, delay=0ms
Reset Asserts = disabled

Таймерное и FIQ есть. Остальных - НЕТ.

JTAG Speed = Auto, Inital - 10KHz
Hardware Reset = enabled, delay=0ms
Reset Asserts = disabled

ПРОПАЛИ все прерывания...

JTAG Speed = Auto, Inital - 10KHz
Hardware Reset = enabled, delay=50ms
Reset Asserts = disabled

Опять появилось таймерное и FIQ!


Хаотически подергал Speed/Delay - максимум удалось добиться работы таймерного+FIQ
или полного отсутствия....



Результаты коротко:

1. В моих условиях достаточно при использовании штатной поддержки J-Link IARом отключить опцию
"Run to main()" в 'Debugger->Setup' и, как следствие, начинать жизнь с 0 адреса для получения стабильного эффекта пропадания прерываний. Данный эффект завязан на MT-Link (to: DASM -
я НЕ утверждаю, что J-Link ведет себя иначе :-) и пропадает только после передергивания питания
MT-Link. При этом загрузка во Flash работает и останов на main() отрабатывает.

2. При некоторых установках, например:
JTAG Speed = 1000KHz
Hardware Reset = enabled, delay=0ms
Reset Asserts = disabled
Начинает работать таймерное и внешнее на FIQ. Большей работоспособности добится не удалось.
Если у кого есть идеи - добро пожаловать!

3. При выбранной опции "Run to main()" и описанной выше конфигурации железа и софта
прерывания работают пока без глюков.

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

Никаких окон (в том числе и никаких регистровых) кроме исходника и
дизассемблера открытых нет.
Эффект без усилий :-( повторился на другой машине.

Какие еще вопросы?

пока вопрос больше не имею =) а проектик нельзя глянуть ? Так, чтобы говорить об одном и том же

Без проблем - как раз занимаюсь обкарныванием результатов экспериментов для выхода
на начало рабочего проекта. Будет под LPC2124-2114-2214-2294
Через пару часов борошу в почту.

ок, жду, dasm@nm.ru
Правда у меня 2148 чип но не думаю о большой разнице

Ушло. Разницы не будет - это учебный проектик задуманый под любой
2xxx.

Не знаю,может быть эта информация Вам пригодится...

Я работал с J-Link компании Segger и в IAR 4.20 ( 4.30)
имел проблемы при работе с AT91SAM7S128.
Когда Flash программировалась непосредственно перед
стартом С-SPY IARовским Flash Loader, С-SPY не останавливался
в прерываниях, неправильно читал memory etc. Когда Flash программировалась
утилитой J-Flash (через тот же J-Link), а потом запускался С-SPY,все работало
без вопросов. Причем эта проблема наблюдалась только с с AT91SAM7S128,
c LPC21xx и STR711 этой проблемы не было.По-видимому,это проблема не
J-Link,a IAR (IAR's AT91SAM7 Flash Loader ???).

CrossWorks работает с J-Link не так устойчиво,как с Wiggler,
независимо от типа процессора.

Не знаю:
они у меня все черного цвета:
при запуске jlink.exe указанной строки нет:

SEGGER J-Link Commander V2.60.01. '?' for help.
Compiled 08:40:14 on Jun 21 2005.
DLL version V2.60c, compiled Jun 21 2005 08:40:05
Firmware: J-Link compiled May 17 2005 10:04:24 -- Update --
S/N : 83485984
VTarget = 0.0V
Speed set to 30 kHz
J-Link>

не, это полноценный =) А Вы случайно этих приколов с пропаданием прерываний не наблюдали ? А то мой отобрали пока

SEGGER выдал на гора версию 3.00С.
Работает.

1. При работе через штатную поддержку IAR ситуация похоже не изменилась.

2. При работе через RDI стало несколько лучше - при условии загрузки Flash средствами SEGGER старт с main() проходит без проблем. При загрузке IAR средствами - часть прерываний не работает.

Все это пока поверхностные впечатления.

Прерывания вроде не пропадали, но не уверен.
Сегодня обнаружил следующее:
JLINK от AT91 (yf нем написано 2198000) отказался работать с TMS470, обновил драйвер до 3.00 - не помогло: "unknown device".
с LPC работает нормально.
т.е. картина такая:
JLINK 2198000 работает с AT91 и LPC
JLINK 2197000 работает с TMS470? AT91 и LPC.
как говорится: "что я делаю не так?"
Хотелось бы, чтобы со всем работало, т.к. 2197000 у меня только один

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

а у меня не работют =( вообще.

Обнаружил такую ерунду

BP ldr r11,=Comm_TrBuffer
str r11,[r12,#Comm_PtrTrBuf_Ofs]
add r9,r1,#0x03
str r9,[r12,#Comm_TrQuant_Ofs]
str r9,[r12,#Comm_TrCount_Ofs]
Error mov r10,#0x00

кусок кода из процедуры в режиме SYS/USR. BP - точка останова. Далее выполняем пошаговую отладку. До точки Error все ОК. При выполнении команды mov r10,#0x00 - r10 - оставется неизменным, зато 0 записывается в r11.
Похоже отладчик путает r10 и r11. Где-то еще встречал что-то подобное.
Если остановиться на BP и следующую точку поставить дальше и запустить выполнение - то все хорошо.
Пробовал и в Keil и в RVDS.

Еще момент. Если я остановил выполнение программы и пишу в pc ручками какое либо значение - перехода не происходит.

http://www.caxapa.ru/echo/arm.html?id=49027

Помогло!
Благодарю.

хотел MT-link купить (я частное лицо) но меня так жестоко обламали -" Платежи через банк мы не принимаем. Только как юридическое лицо.".
Им что деньги не нужны?

Моя цель добиться чтобы не говорили "купить хотя бы мтлинк"

DASM - КАК купить MT-LINK для себя любимого ? Для дома, для семьи ?

Если это камешек в мой огород, то контекст был несколько другой -
подразумевалась цена при абсолютной конкурентоспособности с псевдо-Wiggler-ом
сделанным на коленке.

Свершилось! C новой (хотя может и более ранней - давно не пробовал отладчик) версией Segger 3.20e драйвера перестали падать при аппаратном сбросе отлаживаемого устройства. Теперь все продолжает работать как ни в чем ни бывало. Reset правда по прежднему не перехватывает, но главное не падает!
Был один из самых неприятных эффектов.
Прерывания правда периодически пропадают.
Жду доставки MT-Link5. Посмотрим :-), как с ним....

Итак, MT-Link5 дошел и время на опробывание тоже выкроил.
1. Пришлось сменить USB кабель - со штатным обильные глюки уже начиная с инсталляции :-(
2. MT-Link5 Попался из первой партии, посему заменен C9 на рекомендованный, ибо 3.3V LDO возбуждался конкретно.
3. Светодиода Ready/Busy менять местами и цветами не стал :-)
4. Пoтавлен свежайший Segger софт.
5. Взята плата с LPC2148.

Первые эксперименты оказались обескураживающими - в проектах ранее работавших со старым
MT-Link через RDI начисто исчезла возможность поставить брейкпойнт по загрузке-старту.
Проскакивал всегда. При этом прорисовка интерфейса IAR замирала на многие секунды.
Ручной останов отрабатывал безукоризненно, после чего брекпойнты, трассировка и прочее работали
безукоризненно. Стуки в бубен включая попытки писать даже дополнительную инициализацию в скриптах IAR ни к чему не привели. Резко все изменилось при установке вместо "Auto Selection" - "Adaptive clocking" - все стало просто изумительно - ПЕРЕСТАЛИ даже периодически отваливаться прерывания при запуске. Работоспособность (кроме отвала прерываний) восстановилась и при фиксированных клоках на уровне до 2000KHz. При больших - повторился эффект "Auto selection".

При работе через "родную" IARовскую поддержку, отличий от MT-Link1 особых не заметил.
Однако выбор "Adaptve clocking" и здесь с MT-Link5 привел к излечению достающего бага с
пропаданием прерываний.

При этом скорость закачки при "Adaptive" вполне хороша - где-то под 300K/s.
Недостаток выбора "Adaptive" только ОДИН - категорически отваливается при аппаратном сбросе отлаживаемого девайса.

Я тоже прикупил намедни MT-Link. Не представляю как я раньше без этой коробочки обходился .Правда он не 5. С ходу отловил и исправил ряд неприятных багов в проекте. Единственное - если отключить питание таргета, дебагер гарантированно зависает. Из этого состояние его выводит выдергивание и втыкание кабеля USB. Может стоит в последующих версиях завести кнопку подачи питания или ресет? А так работает - сказка. И по цене хорош. Позже куплю еще 5 версии. Работаю в Кейле с LPC2214.

тоже прикупил MT-link - и вопрос про волшебные пузырьки с какой версией драйверов KEIL работает с mt-link 5 версии

просто начал вчера пробовать (с тем что было на компе без обновлений)
с версией драйверов сеггер 3.0 не работало и фирменное обеспечение
поставил из того что было под рукой 3.14 - фирменное обеспечение сеггер работает на ура но кейл с RDI не работает
сейчас вот скачал 3.30 пойду пробовать
хотелось бы избежать прохождение пути пройденного другими
поэтому не могбы просто сказать с какой версией все должно работать под кейл чтобы не изобретать велосипед
под кейл работаем сейчас с Ulink - решили поддержать отечсетвенных разработчиков

Я работаю в кейле через RDI 3.20. С теми, что в кейле дровами плохо работало. Сейчас уже научился обращаться с мтлинком. Поставил задержку на старт 200 млс. Без нее бывает долго не соединялся. Возможно это из-за супервизора, который на 100 млс после подачи питания держит сброс. Остальное - по умолчанию. Чтоб брэкпоинт поставить сначала надо стопорнуть процесс, поставить, пройтись по шагам и уж потом запускать. Еще - виснет сабж, если с таргета сбросить питание. После этого надо выдернуть юсб кабель, затем снова вставить. Короче немного в бубен надо постучать. Но в общем - замечательная штука. Возможно, что в 5 версии по другому.

не могли бы вы детально сказать как и что делать чтобы кейл заработал с mt-link
вот поставил 330 но стало еще странне с кейлом - но не работает - фирменные утилиты сеггера с процессором общаются на ура - пишут читают - так что все дела в волшебных пузырьках если есть инструкция чтобы запустилсоь и работало было бы замечательно
надо сказать что с ulink кейл работает очень хорошо никаких зависаний или танцев с бубном не нужно включил и поехало
хорошо бы такую же инструкцию на мтлинк поиметь чтобы не думать над этим

Как делал я: Сначала поставить соответствующий юсб драйвер и в устройствах должен появиться наш JLINK при подключенном мтлинке. Светодиод у последнего при этом мигать не должен. В опциях проекта дебуг выбрал юзе RDI интерфейс драйвер. Жмем сеттингс и указываем путь к длл установленых дров. В моем случае это JLINKRDI в вашем JLINKARM если я не ошибаюсь. Потом если все ок, можно из кела войти в настройки драйвера. Я ни чего не менял, только задержку при старте поставил. Вы можете поковыряться со скоростью. Вот собственно и все. Надо сказать, что как-то у меня жтаг отбросил копыта - поковырял я в нем. Чего я только не делал. Фирменная утилита - командер тоже кстати отлично видела девайс. Помог только снос и переустановка оси. Ось у меня XP SP2. Вообще конечно производителю не помешало бы накатать инструкцию по инсталяции и фак.