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

Условия эксперимента:
- MT-Link с фирмварью 1.5
- Платы от Olimex LPC-E2294 и LPC-E2124
- IAR EWARM-3.40
- RDI от Seggler 2.74A
- Скорость Auto (Adaptive по информации автора на данный момент не поддерживается, что
правда не мешает штатным утилитам (только им!) от Seggler работать и при задании такого режима)
- DCC отключен (не поддерживается, хотя выбор вроде ни к чему плохому не приводит).

В процессе экспериментов произведена замена фирмвари с 1.4 (исчезли с непрогнозируемые вылеты)
и опробован рекомендованный автором откат на RDI 2.62С (сколь-нибудь заметных отличий не обнаружено, остался на 2.74A)

На автомате выбиралась скорость 1000kHz. Не было проблем и при ручном задании 1333kHz,
но при 1600kHz уже неработоспособен.

Теперь о менее приятном:

1. Со встроенной в IAR поддержкой J-Link, MT-Link можно считать неработоспособен :-(
Загрузка Flash идет нормально, можно после запуска пошагово походить, но при попытке
дойти до поставленного брейпойнта гарантированная потеря/блокировка прерываний и
как следствие зацикливание на вечном ожидании.

2. C Seggler-овским RDI картина стала нормальной - грузится, шьтеся (и встроенными в IAR и Seggler),
шагает, отрабатывает брейкпойнты. Все это, правда, при одном условии - используются софтовые брейпойнты. C железными есть проблема - не может при пошаговом исполнении отловить выход по
двум веткам. Ругается на невозможность поставить брейкпойнт (второй). При этом при работе со
штатной поддержкой IAR такие места трассируются без всяких проблем.

3. При выключении питания объекта изредка наблюдается зависание MT-Link требующее
и его выключения / включения (автор обещал помудрить с Watchdog).

4. MT-Link не работает (выкинуть стабилизатор 3.3V была не хорошая идея) на длинных USB кабелях и через пассивные хабы. Уже при дополнительном удлиннителе в 3m появляется сообщение о повышенном до 3.6V уровне питанияи опорное для ADC тоже прямо от 3.3) обьекта, а при более длинном начинаются сбои.

5.Может я чего не понимаю, и все "так и должно быть", но при нажатии "reset" на объекте не происходит отлавливание сего факта (catch exceptions reset активирован), зато для начала
вызывает вопль "Bad JTAG communications" после чего следует еще масса messagebox
WinRDI read {r0..r14} failed. Искусственно созданный факт data exception тоже отловить не удалось.


Вроде пока все.

Спасибо за критику, тем не менее по пунктам..
1. Задание скорости - на филипсовских процах у меня тоже до 1600, на атмеле 2000 без вопросов (комментарии излишни). При работе со встроенной поддержкой - сильно подозреваю что дело не в коробочке, а в софте со стороны компа. Проверю позднее.
2."Все это, правда, при одном условии - используются софтовые брейпойнты. C железными есть проблема - не может при пошаговом исполнении отловить выход по
двум веткам. Ругается на невозможность поставить брейкпойнт (второй). При этом при работе со
штатной поддержкой IAR такие места трассируются без всяких проблем" - Тут вопрос такой. У ARM два hardware breakpoint. Одна автоматом уходит на "С-SPY Terminal I/O & libsupport module". При встрече условного ветвления cpy должен поставить еще ДВА breakpoint - на команду КУДА прыгать при соблюдении условии и на следущую в противном случае. Понятно, что сделать он это не может - их всего ДВЕ. Отключите DEBUG информацию из проекта - и увидите что все станет на свои места (правда работать без нее сложновато :-) ). Штатная же поддержка видимо работает несколько иначе. Возможно временно снимает Terminal breakpoint, может предсказывает ветвление (элементарно ведь) - точного ответа не скажу пока. Но уверен в оригинале устройства тоже самое.
3, 4. По поводу помехоустойчивости - честно скажу - не предполагал отладку кабелем длиной 3 метра. И дело вряд ли в стабилизаторе. Но буду иметь ввиду.
5. Никогда этим не пользовался - ответить смогу сравнив с оригинальным.

1. По скорости это не жалоба а просто констатация факта, для выбирающих, возможно
облизывающихся на чумовые скорости указанные в меню.
1.1. Ну не работает со штатной IARовской это точно :-( в бубен стучал :-(.
Если лицензию на Seggler не покупать, то и ничего вроде. А если еще и п.2 объехать,
то хрен с ней.
2. Про только два аппаратных я в курсе - начитан. Почему два нужны в описанном случае, тем более
ясно. Зачем захапывает одно IAR - прояснили. Вопрос был а как-же встроенная поддержка работает?
И как там с "родной коробочкой" в этом случае все выглядит? Если "плохо" буду с Seggler-овцами
общаться :-).
3. Это и на штатном кабеле.
4. Ну три метра я попробовал после того, как наступил на HUB (что вполне реальный вариант) и увидел
вопль о 3.6V. Дуууумал. На единственный приложенный документ (схему) смотрел.
Потом раскрутил и увидел наличие отсутствия стабилизатора. Все стало на свои места.
Отсутствие стабилизатора - это оно :-(. Опорное для ADC упало вместе с питанием, вот и померещились 3.6V.
5. Интересно будет узнать результат на оригинальном.

P.S.
О просьбе ближайшее время не беспокоить - помню и понимаю. Цель данного поста была другая, и я,
надеюсь ее внятно объяснил.

Для начала вопрос: а где взять версию firmware 1.5 для MT-Link

С скорости и LPC ест проблем и в мой Raven. И я с IAR работаю. На АТ91 все в порядке,работает на максималнои скорости а с LPC скорост 4 нада установит чтоб работало стабилно.

IAR ARM 4.30a все работает

Есть такое

У меня удлиннитель 2 м + кабель который был в комплекте - проблем нет.

есть такое

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



1. А у меня в 4.30A 'почти все', но это единственное сводит все на нет. Отлаживемая Вами программа зависит от прерываний? У меня зависит и система навсегда остается в IDLE Task.
C RDI этого нет. Там проблема (неприятность)? мельче.

2. А MT-Link односветодиодный может быть? - там стабилизатор. У меня двух. Да и кабели разные,
у меня среднекитайсий - не самый толстый.
Сейчас поставил первый попавшийся ADP3338, получил нормальные 3.3 (3.298V вместо 2.987V после светодиода) и нормально заработал на длинном кабеле. Подергал десять раз питание объекта (он тоже от USB питается) - MT-Link не завис, хотя ранее примерно один раз их трех приходилось и его передергивать.

Жить стало лучше.

Естественно.

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

Может быть и с одним светодиодом (это из первых версий).
Мне достался именно такой (собран на Atmel SAM7)

1. Значит это еще требует исследования. Контроллер какой? У меня LPC2124 и LPC2294.
Постараюсь после нового года попробовать на атмеле.
2. Десяток-другой милливольт больше/меньше и в результате работает/не работает. Данный факт выявлен, объяснен,измерен и последствия успешно исправлены. Дальше каждый решает за себя.

Да я абсолютно не против, только удивляет отсутствие хоть какой-нибудь сводной странички в инете о MT-Link USB - устал уже искать прошивки в форумах

Подводя итоги и заглядывая в недалекое светлое будущеее. Переведем сабж на LPC2142 - за счет двух SPI думаем поднять скорость. Стабилизатор вернем. Страничка будет на Сахаре в проектах. Еще есть какие-то пожелания ?

Посравнивать с "родным" не только в условиях персональной эксплуатации, ну и приблизить, по возможности.
Успехов!

Здесь было много обсуждений по работе с AT91RM9200,
судя по ним есть проблемы,
если можно в следующей версии сделайте необходимые доработки.

подскажите пожалуйста, какие именно проблемы ? Те, с кем я общаюсь по ICQ и использующие RM9200 - нареканий не было. Другое дело что процессор значительно сложнее, и там возможны проблемы совсем другого плана. А новичку иногда сложно отличить - где вина чипа, а где отладчика

Я читал что была проблема связанная с тем что
AT91RM9200 стартует на низкой частоте,
сейчас искал эту тему и не нашел.

Я сам собираюсь купить MT-link и рад вашим
заявляениям об отсутствии проблем.

Это действительно так?
Кто работает с MT и AT91RM9200 откликнитесь.

да, тоже хотел бы послушать отзывы, так как я сам работаю только с SAM серией и LPC2XXX

LPC2148, LPC2103/02, LPC2124, LPC2129

Соответствует (не знаю, печалится или радоваться) может какие нюансы установок вспомните?
Хотя я вроде все разумные и плоу-безумные пробовал. Может можно обменяться какими-нибудь
лабораторными проектами (например, для 2124) для локализации проблемы?

Исправилось! К сожалению 'само':-(
Сегодня в процессе экспериментов с отладчиком рухнул отладчик в IAR. При попытке
запуска отладки exception в модуле iardepm.exe. Восстановление проекта из backup,
переустановка IAR поверх, отключение RDI и прочие пляски не помогли - эффект был стабильный.
Снос из реестра веток IAR c последующей переусановкой из-за пропадания лицензий востановили
работоспособность. ПРИ ЭТОМ ПРОПАЛ И ВЫШЕУПОМЯНУТЫЙ ЭФФЕКТ. Вот такой бред :-(

Вообще IDE IAR малофункциональна и глюковата :-( я ей и не пользовался - только отладчик.
Теперь после этого случая и отладчиком чего-то не хочется. Может кто-то порекомендовать
альтернативный вариант отладчика?

Из приятных вещей - целенаправленным отключением в опциях _линкера_!!! опции 'with runtime control modules' позволило убрать эффект невозможности трассировать ветвления при работе _отладчика_ через RDI при использовании железных брейпойнтов.

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

P.S.
Но времени потрачено :-(. Почему-то установленный вчера IAR for AVR c отладчиком JTAGICE
заработал сразу без всяких мук.

ммммм. даже не знаю что и ответить. Из под дивана вылезти можно ? :-) Мне очень понравился отладчик в RVDS - но он не хранит точки остнова и watch между сессиями. Или я чего-то не понял. IAR все таки не так и плох имхо

пользую evm9200 + CW 1.5b2. И виглер и МТ не входят в отладку.
Перелопачиваю загрузчик от CSB637 по подобию подсматривая у Черкашина.
НО.
При запуске загрузчика под дебугером на виглере - без проблем доходит до сишного кода инициализации, а МТ под выдает "memory access timed out ... . JTAG speed to high?"

Можно вылезти! Тут вроде никто тапками не кидается :-)
Более того некоторые мечтают увидеть 1.5 фирмварь (а я, как экстремист уже 1.6 :-)
IAR вполне хорош (тем более для меня, который отладчикаи не пользовался особо никогда и
впредь не особо собирается) - претензии к:
- падение на ровном месте с последующей чисткой и переустановкой
- упорная потеря прерываний в штатной поддержке J-Link, которая вдруг вылечилась
- ну и до кучи - измеренные хоткеи работают, но отображаются в меню в произвольном виде.
- тому, что я пока занимаюсь отладкой "отладчика".

RVDS - это что-то типа RealView? Он там интегрированный или пользовать отдельно можно?
Если интегрирован, то пожалуй я пока с IAR повожусь....

Попробуйте JTAG speed поставить fixed. Начните с малого. Потом увеличивайте. Как J-Link работает со скоростями мне тоже не нравится



так это все не мое =( у меня же просто устройство, функционально похожее, то есть совместим на уровне протокола. А приколы с реестром и тп, ну не могу ничего тут поделать, это виндовая часть

RVDS это и есть RealView. Работает с сабжем. Через RDI. Новичкам и слабонервным не рекомендую - сам пару дней просидел, пока понял что к чему, хотя опыт с другими средами небольшой был

Так я что? Я ведь про альтернативный отладчик и спрашивал, а не про альтернативную
фирмварь для MT-Link :-). Правда, вопрос, как иаровский отладчик доходит до такой жизни не
совсем для меня закрыт, особенно в свете пока безукоризненной работы связки AVR+JTAGICE.

Так что имелось ввиду под RVDS и насколько там отладчик автономен?

Дык. У CW в настройках тока можно скорость фиксированную установить! Ставил 1000 и 2000

И вообше я не жалуюсь, а копаю. Просто был вопрос я и поделился ....
А вот прошивочку бы 1.5? Если не в облом подскажите, где достать можно?

да, и CW не дает полноценно настраивать скорости., но медленность загрузки не из-за скорости уже самом JTAG ? а из-за мелкости пакетов - по шине USB если их туда сюда гонять скорость катастрофически падает. Все таки думаю тут что-то с загрузчиком они намудрили, что шлют такие маленькие пакеты. После загрузки просмотрм памяти и прочие операции мне показались довольно шустрыми. Будем ждать от них подддержки RDI наверное.

Вот у меня полный снос всего иаровского, очистка реестра от всех следов, переустановка ev 4.30A, доставка на него апдейта компилятора от полного, вылизывание всего что можно - не вылечили эту беду.

Дело похоже не в железе, а в самом отладчике. Но на него апдейтов пока не видать...

Зато MISRA с радостью вывалила почти 55 тысяч ошибок на проект...

1. А с RDI все в порядке? У меня на самом деле вылечилось не до конца - таймер работает почти всегда, а вот уже UART - реже. Дальше - хуже...
Дело достаточно темное и комплексное - больше всего похоже на какие-нибудь временные
нестыковки в которых виноваты оба :-(. Я питаю надежды посмотреть на поведение с
адаптивной тактировкой.
Надо-бы попробовать на какой-нибудь машине типа P3-700, что-то мне моя интуиция подсказывает
попробовать. На днях поставалю. А Вы на какой пользуете?
Причем я очень сильно сомневаюсь, что с родным J-Link имеется такй-же эффект - уж больно вопиющий факт.
2. MISRA это... хотя 55тысяч наводят на размышления :-)
Я лично попробовал избавится от тысченки-другой, но довольно быстро дошел до рекомендации
не использовать функции с переменным числом аргуменотов и решил завязать с этим делом.
В любом языке диалекты придают особую прелесть языку......

Проблема RM9200 & JTAG во многом зависит от правильной настройки системы тактирования процессора, которая невнятно описана, да и глючная в настройке. Если не принимать никаких специальных мер, то отлаживаться через JTAG весьма проблематично. Тактика примерно такова: не давать управления внутреннему загрузчику, включить как мастер клок второй кварцевый генератор (10-20мгц)(вот эта часть делается весьма витиеватым способом), потом из cstartup-а вызвать low_lewel_init а в нем вызвать AT91F_init_clock c нужными значениями PLLAR & PLLBR а потом уже отдаваться в руки ИАРу. Вот при такой последовательности действий никаких проблем с зависаниями по JTAGу я не ощущаю. При этом способе действий спокойно проходит как холодный так и горячий рестарт системы...

C RDI тоже самое наблюдал , но вот что любопытно - прерывание таймера действительно иногда пропадает, а вот EINT - никогда. Вобщем вопрос еще нуждается в изучении.

Ага, вот и DASM заговорил :-) по данному вопросу. Главное не забрасывать вопрос!
Еще правильно будет попробовать с адаптивной тактировкой поработать.
С EINT недели через три будет на чем пробовать в полный рост на реальной железке - все четыре задействованы будут, в том числе (при наличии внешней синхронизации) и вместо таймерного.

а я завтра получу jlink и все сравню

Ну и надеюсь на объективное и публичное сравнение :-)
А что, раньше не был доступен? По складу MT-Link вроде когда-то существовал
в наличии... А где доставали? А то у всех известных мне дилеров в наличии только в составе китов
из борды и компилятора, что является некоторым "перебором".

Безусловно все отличия отмечу и исправлю в новом апдейте. Где что и как доставал - написал в private

RDI лучше и шустрее грузит и верифицирует, но траблы те же.



Ну этого пока нет, бм надеяться что появится когда нибудь.



Два Xeon (3.06 GHz, 533 MHz FSB) на матери Asus PCH-DL, гиг оперативки.



Ну там 70% на один макрос ввода-вывода ругается. Оно работает, но не нравится ей отсутствие скобок. Может позже поразбираюсь чего оно хочет...

У меня нет паралельной памяти, я работаю с загрузкой из IIC или SPI.
Что получается я не смогу JTAG использовать?

Какой JTAG Вы используете и в какой среде разработки?

В CrossWorks + Wiggler нет никаких проблем даже без специальных мер. В скрипте сброса установил регистры клока в нужные значения и работаешь... Клок при этом настраивается любой, без ущерба для JTAG-отладки.

Укрепили в желании попробовать на чем-нибудь стареньком.

Я пользуюсь МТ-Линк-ом и вигглером через XJTAG.
Дело в том, что когда запускается внутренний загрузчик, он включает систему прерываний и когда происходит попытка захвата управления через JTAG, система прерываний не глушится и при первом же прерывании JTAG теряет уравление и оно снова оказывается в руках у загрузчика с самыми разнообразными полетами впоть до такого зависания, когда помогает только отключение питания...
Работаю в основнои в ИАРе и ADS12. Ну у меня как раз и этот случай, у меня из ЕЕПРОМа стартует небольшая программка, инициализирует необходимую периферию(SMC,SDRAM и проч.) и попадает в бесконечный цикл, ожидая команду, при это система прерываний заглушена. Вот тут как раз и начинаются операции с JTAGом..

Потратил несколько часов, порылся в хламовнике, нашел материнку SuperMicro P6SBA, проц под нее P3-450, памяти 256 мегов, какое то видео... Собрал машинку, воткнул 2000-е винды, 4.30А со всеми апдейтами... Ситуация один в один.





А можно чуть поподробнее?

Ну что конкретно хотите поподробнее?

Тоесть Вы всетаки позволяете работать внутреннему загрузчику?
В MT или в Wglr. пришлось что нибудь дорабатывать?

Когда загрузчик грузит программку из еепрома то проверяет контрольную сумму программы, убеждаясь что все нормально, потом обнуляет всю периферию в тот вид как она находилась после ресета и только потом передает управление загруженной программе... В мт не трогал ничего, а вигглер у меня вообще на одной микросхемке кр561пу4 по совершенно стандартной схеме включения, никакой отсебятины.

Вобщем проверил на оригинальном. Таже бодяга. Поскольку симпотмы у вас немного разные - опишу простейший, наиболее легко повторяемый. Драйвер родной - Jlink. Ставим hardware breakpoint в какой нибудь функции прерывания (например timer, перенаправленный через VIC). Грузим прогу - прерывания эти срабатывают. Жмем кнопку reset в отладчике (большая такая стрелка влево) и все - прерывание таймера не наступает. От галочек hardware reset и прочее это не зависит. J-Link оригинальный. Чип LPC248 - максимальная скорость на RDI - 1333, выше не хочет. Adaptive clocking на этих версиях их железа работать не будет по определению - "This pin is not connected in J-Link." (про RTCK , это кажется только в v5 изменилось)

Мда... Похоже нам бы не помешал счастливый владелец "законного" иара с j-link'ом оригинальным.

Кстати, погуглил по ключевым словам.....

Может кого на мысль наведет...

http://www.embeddedrelated.com/groups/lpc2000/show/3465.php

http://www.embeddedrelated.com/groups/lpc2000/show/7889.php
"Using the LPC2131 AND LPC2138:
I have been experiencing a problem when running in RAM or ROM with the jlink debugger. Sometimes no interrupts will work at all. All I have to do is unplug the debugger and power from my board. PLug them back in and start over.

I am not sure what is the root cause. IAR is looking in to it."

мужики, причем тут законный ИАР ? RDI абсолютно честный на 30 дней. А прикрутить его можно хоть к AXD хоть к RVDS хоть к Keil. Впрочем мою позицию вы понимаете - я хочу, чтобы купившие мтлинк чуствовали себя не хуже, чем обладатели J-link . И сегодня я убедился, что это так.

1. Оп! Значит сравнение производилось с "достаточно старой" версией железа
J-Link.
2. Описанную ситуацию попробую повторить завтра (сегодня уже не в форме), но на первый взгляд
у меня в такой ситуации проблем не было.

3. Кроме потери прерываний (опять завтра подробно опишу ситуацию) меня раздражает
поведение XX-Link (через RDI) при, например, нажатии reset на девайсе - пробиваться через десятки
воплей об ошибках чтения регистров надоедает. Что-то в этом неправильное есть.

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