Значи аз досега си карах на конвенционален JTAG дебъг. Ама реших да видя фрии решенията за трейс докъде са стигнали.

И се оплетох.

1. Каква е разликата между ЕТМ и SWO трейса?
2. SWO и SWV едно и също нещо ли обслужват?
3. Какво трябва да монтирам на еклипса та да ползвам трейс?
4. Какво аджеба мога да измъкна по тоя трейс?

ETM май значеше embedded trace macrocell и е общо понятие. Както UART е общо понятие.
При АРМ обикновено като се каже че има изведен ЕТМ аз разбирам че има изведен специален трейс порт с много жици. АРМ имат ЕТМ1, ЕТМ2, ЕТМ3... много варианти, много различни конектори...

SWO се казва пина. При CortexM3 се ползва SWD (serial wire debug) за дебъгване и за това се ползват 3 от 4-те жици на JTAG-a. Та след като превключиш от JTAG ->SWD едната жица повече не е нужна за дебъг и може да се ползва от SWV (което си е ЕТМ-а на куртекса). А по SWV може да се изкарва юзерски трейс (32-канала) или информация за работата на ядрото - има си филтри, с които задаваш какво да излиза...
Естествено по една жица трудно ще изкараш всичко. Но ако проца има ЕТМ порт с повечко пинове, може да се изкара достатъчно информация, така че да можеш да възстановиш 100% от това какво е правил процесора. Тогава може да "дебъгваш" лога. Както greenhills му викат "time machine" - демек най-големият келепир е, че може да дебъгваш назад във времето.
Примерно някой ти омазва паметта и след това ти гърмиш. Може да сложиш там където ще гръмне, но тогава не ти помага щото като спре вече е омазано, т.е. твърде късно е... Но ако имаш тайм машина - слагаш брекпоинт и пускаш. Като спре почваш да дебъгваш в обратна посока да видиш как се е стигнало дотук...

При куртекс М3 само с един пин SWO трудно ще логнеш цялата работа на ядрото (не е невъзможно, но ще го забавиш яко). Но благодарение на филтрите може да логваш частично, примерно логваш само кога прави преход jump/call/return... И долу-горе хващаш откъде минава и вече съответния софтуер може да ти направи статистика (profiling) къде циклиш най-много време, коя функция колко често се вика, колко време отнема средно и т.н. Тая статистика може да я направиш, без това по никакъв начин да се отрази на работата на ядрото. Нито го бавиш нито нищо.


Да


Зависи - ако искаш да гледаш юзерския трейс т.е. от типа TRACE("hello world"); - изобщо не ти е нужен Еклипс. Може и външна конзола. Не че няма плъгин за терминална конзола в Еклипс де...

Ако искаш да гледаш статистики. Те тогава ти трябва нещо от сорта на CodeRed....
А ако искаш time machine не само плъгините ами и дебъгера трябва да е пипнат. По принцип в GDB 7 добавиха някаква поддръжка за "step backward"... но тя е за линукс приложения, компилирани със специални монитори и т.н. За ембедед доколкото знам все още не е много стандартизирано кое как...


ами казах 3-те неща - юзерски логове, тайм машинка и статистика. На тоя етап аз ползвам само първото, но и то не е малко.... особено при по-голям проект, повече хора... Дебъгването става кошмар, примерно ако има течове на памет няма как да дебъгваш. Пускаш да работи и да логва всяко заделяне/освобождаване и после един макро да оцветява в червено неосвободените. И вече като знаеш коя функция неосвобождава може да я дебъгнеш....

Мда, поизясни ми се .... малко

Хубаво, а това за което ти ползвш SWO-то с какво е по различно от един тривиален UART канал на който да блъскам трасиращи съобщения? Изключае хардерните предимства (че не заемам UART-а).

Принципно с нищо... конзолата си е конзола, независимо откъде минава хардуерно....


Но все пак SWO-то е супер удобно щото хардуерно го имам на всичките си платки, има го и на твоите платки... А пък излишен УАРТ нямам на нито една платка, не знам за теб

Скоростта никак не е за подценяване. В момента лимита ми идва от етернет-а на емулатора, който е слабичък...
А и също софтуерно - върви на всички куртекси...
И надеждността е супер, нямам баудрейт... бачка независимо от това с какъв клок е таргета

Аха. А как се реализира самото пренасочване на TRACE стринговете към SWO пина?

Просто пишеш в един регистър...

ех, на практика е малко по-сложно за да не се изпускат байтове и за да е threadsafe. Ей ти го кода всъщност:




edit: фана ме срам че кодът е неоптимален... ей така е малко по-добре:

Мда сега остава да измисля как да го подкарам през Jlink-а

с jlink не знам дали ще стане... може би jtrace ако държиш на марката

Е не, Jtrace няма кой да го хаква

Jtrace е по тежка артилерия, май работи с широкия кабел директно към TRACE порта (ЕТМ).

Jlink по принцип подържа SWD и SWV. Само че по новите му версии. А аз не знам мойте клонинги дето се търкалят по бюрото коя версия си. Според колегата fan последното творение на китайците би трябвало да ги подържа, ама не съм го пробвал досега.

Аз досега не бях приритал за нещо такова, щото на ST -тата по принцип има минимум 3 UART-a (големите са с по 5) и все някой артисва. И аз на всичките си устройства извеждам класическия JTAG + UART TX/RX + захранване, общо е куплунг с 10 пина. И после го ползвам и за наливане през бутлоадера и за трейсване и за дебъг. И едва ли ще се откажа от тая концепция, щото наливането през бутлоадера така или иначе ми трябва за пройзводство, така че UART - все трябва да е наличен.

Трейса по ще ми е интересен ако има стабилни фрии имплементации на по сложните неща които описа по горе. Ама както разбирам за сега няма. Но въпреки това ще пробвам да го подкарам, та да знам въобще може ли през Jlink да мине.

Имам да дорутя една платка и другата седмица ще го побъзикам малко да видим, ще стане ли.