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

Трассировка в самом реалтайме, разумеется, не нужна. Она нужна, если по результатам анализа данных, поступивших в реалтайме, остановили процессор, и хотят узнать, где он был "тогда". Ну и в общем смысле, посмотреть историю за некоторое время до возникновения ошибочной ситуации, приведшей к останову, так как останов может случиться далеко не в том месте, где произошла ошибка. А к отладке ядер оно отношения не имеет никакого. Да и nexus, собственно, не определяет физические провода, он разрешает и JTAG, и другие порты, думаю, и против чего-нить быстрого сериального, например RapidIO-линка - всего два провода, а 3 Гбит/с, иметь не будет...

Доки на RDI только под NDA идут (в бумаге).. закрытый он.

Вот и расказали бы о своей конкретной грусти. Т.е. больше конкретики, Use Case-ов как говорится.
Аргумент что все порты заняты как бы не принимаются. Композитный дивайс на USB это классика, и нас применяется повсеместно.
Вот для подъема USB логично применить JTAG.

Но дальше проблемки есть, среди них:
JTAG не видит состояния памяти так как видит ее процессор через свой кэш. Т.е. на стопе дамп дает неправильный снимок памяти
JTAG не видит буфферизацию записи. Опять же на стопе дамп дает неправильный снимок памяти
Что JTAG видит в SoC-ах с акселераторами доступа FLASH тож тайна покрытая мраком.
Чтение через JTAG в реал-тайме используя семихостинг вносит местный эффект в выполнение кода. Баги могут временно пропадать.
Призводители умеют манипулировать JTAG сигналами когда вы пытаетесь лезть в области содержащие защищенный код или периферию, это еще вносит путаницу.
Наконец цикл отладки под JTAG просто длинее по времени чем отладка средствами встроенными в сам код. Для старта отладки
по JTAG нужен длиный период загрузки символьной отладочной информации, а перед этим скомпилить надо с отладочной информацией, а перед этим оптимизацию снизить до 0.
Вообщем лучше всех бы нам рассказал о всех неудобствах отладки через JTAG это SM поскольку CCS для ARM самый медленный и дубовый компилятор в мире.

Могу сказать совершенно точно, что драйвера отладки обеспечивают видимость всего через кеши и прочие буфера и акселераторы именно так, как это видит процессор. И, при надобности, сливают или инвалидатят кеши, обеспечивая когерентность. Это совершенно надуманная проблема. Кеши не мешают отладке ни на каком из семейств процессоров, поддерживаемых CCS. Гораздо больше неприятностей от MMU, если его задействовать, так как ни драйвера, ни среда о нем без понятия, и "куда уехал цирк", а именно адреса внешних устройств, оно не догадывается.


Ясно, спасибо, работаем . По ходу он уже и устарел, нынче RDDI заменил RDI. И он, все же, не в бумаге, но под лицензией.

Вам не кажется что консоль на композитном USB девайсе выводящая дамп при попадании в дата аборт
это несколько оригинальное решение ?
то есть JTAG таки бывает нужен...
иногда длиннее иногда короче, сильно зависит от ошибки.
А кто мешает компилить всегда с отладочной инфой а шить из параллельно создаваемого BIN ?
Для вменяемой отладки мне хватает снижения до 1
иначе во флеш уже не лезет...

И с таким уровнем считаем, что система "рабочая" .

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

Не понял???? Поясните! Я что-то никакого длинного периода никогда не видел. Куда загрузки? Она и так уже в самой среде куда-то видимо сразу загружена, и символьная, и номера строк исходников. Еще думать об этом. А в таргет ее грузить, разумеется, не нужно. Когда делается "Load Program" из дебаггера нет никакой разницы по времени, есть там в загружаемом модуле отладочная информация, или нет.

уровень снижаеться только на время отладки,
после нахождения бага он опять меняеться на -O2 или -Os
кстати разница в размере кода между -Os и -O1 в моем случае всего ~10%
Дык так и используеться, сбросил уровень оптимизазии, нашел багу, поднял уровень,
смотрим через "консоль".

Кстати, "для посмотреть" буфера уровень оптимизации вобще не нужно сбрасывать,
это нужно только для чуть-чуть походить по коду.

Так это уже бага, которую надо ловить и лечить - если от уровня оптимизации что-то куда-то уплывает. А если невозможно лечить - то оформить такой жестокий по времени кусок на ассемблере. Чтобы от компиляторозависимости уйти.

Долго смеялся

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

Простите, а кто "ставил условия" - для консолей интерфейсов нет и не будет? Отлаживаться будем через JTAG причем стоя в гамаке через Wiggler.

Кстати, я об этом и писал

Т.е. Вы считаете программу, которая на разных уровнях оптимизации ведет себя по-разному НОРМАЛЬНОЙ? Я бы программиста с таким мнением уволил бы неглядя...

то есть все Ваши проги умирают от снижения производительности на 10% ?
огласите пожалуйста список того что Вы делали и что не нужно покупать (шутю)

Вы не внимательны, условие не жесткое, если заработал модбас по уарту то "консоль"(вывод отладочной инфы)
уже туда.

Ой Ой Ой, меня скоро уволят)))).....а вообще интересная тема, у меня прога хуже работает после того как я ставлю все галочки в разделе оптимизация, хотя по размеру становится меньше в 2 раза(оптимизация то с приоритетом на скорость). Где можно что то почитать типа IAR C++ Compiler Efficient coding? а то вы еще будете долго спорить))

Не вижу для отладчика возможности заинвалидить кэш иным способом чем выполнить тем же процом принудительно несколько команд с через ICE
http://infocenter.arm.com/help/index.jsp?t...222b/index.html

Тут уж местный эффект будет по полной. А драйвера в ССS если позволяют себе инвалидить кэш делают медвежью услугу.

Но это не все, есть еще буфера на запись и не только встроенные в ядро, но и прилепленные на AHB производителями непосредственно чипов.

Ага, значит CCS не поддерживает MMU... Оч забавно. А ведь базовый адрес таблицы трансляции лехко читаеться, не сложнее чем кэш заинвалидить.
Кстати RealView поддерживает компиляцию для DSP от TI в платформе OMAP совместно с кодом для ARM.
А б рекомендовал бросать этот CCS и переходить на RealView.
И как там, ССS поддерживает ARM Cortex-A8 для BeagleBoard на OMAP-е?





Вам вооще совет такой:
Включаете JTAG в режим мониторинга, ставите брекпойнты.
Перехватываете аборт вызванный брекпойнтом, и пишите интераптами в скоростную консоль хоть по USB, хоть UDP, хоть по SSI..
Прога останавливаться на брекпойтнах не будет и накладные будут меньше чем насиловать JTAG цепочку ICE, особливо если они там реально кэш и буфера инвалидят на каждом чихе.