MT-Link. Первый опыт использования. Опции

[zltigo]

Первое, что следует отметить - 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 тоже отловить не удалось.


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

[Velund]

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

[Velund]

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

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

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."

[DASM]

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

[zltigo]

Вобщем проверил на оригинальном.
....
Adaptive clocking на этих версиях их железа работать не будет по определению - "This pin is not connected in J-Link." (про RTCK , это кажется только в v5 изменилось)

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

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

[Velund]

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

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

[DASM]

Вобщем проверил на оригинальном.
....
Adaptive clocking на этих версиях их железа работать не будет по определению - "This pin is not connected in J-Link." (про RTCK , это кажется только в v5 изменилось)

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

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

Да, только вот новую где взять - неизвестно. Думаю в России их вообще раз два и обсчелся. Кстати если кто с китами будет брать - например такая штука как 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
---------------------------
ОК
---------------------------
"
Тоже самое вижу, смею уверить

Сообщение отредактировал DASM - Dec 29 2005, 06:26

[zltigo]

Да, только вот новую где взять - неизвестно. Думаю в России их вообще раз два и обсчелся.
...

Ну насчет 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 + еще десяток воплей :-( )

[DASM]

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

[DASM]

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

[zltigo]

опишу простейший, наиболее легко повторяемый. Драйвер родной - Jlink. Ставим hardware breakpoint в какой нибудь функции прерывания (например timer, перенаправленный через VIC). Грузим прогу - прерывания эти срабатывают. Жмем кнопку reset в отладчике (большая такая стрелка влево) и все - прерывание таймера не наступает.

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

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.

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

[DASM]

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

[zltigo]

Набрел на новый эффект. 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 и тупое долбление

[DASM]

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

[zltigo]

Предлагю начать топик "Глюки segger-вского JTAG " а не отличия от мтлинка.

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

[DASM]

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