Миро май беше споменавал, че ползва трейс отвреме-навреме само, че с друг дебъгер (Ronetix PEEDI, ако не бъркам). Но дето се вика, ако много се закучат нещата, би могла да бъде полезна благинка.

Друга чуденка - дали не съм сбъркал, че поръчах Segger? Lauterbah дали не си струва повече? Или пък Ronetix? Или пък някой безименен жълтурник?

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

Не искам да зарибявам никой, по-скоро от техническата страна няколко думи. Значи хардуерно трейсът може да е по една жица (SWO), може да са по няколко, може да има клок, може да няма. Обикновено на стандартния конектор за jtag/swd трейсът е само по една жица и без клок. Демек най-прост сериен интерфейс.
Разликата обаче спрямо обикновен сериен интерфейс е скоростта. Идеята е, че трейсът не трябва да товари проца. Иначе с трейс и без трейс ще има разлика и проблеми от сорта с дебъг работи, без дебъг не ще. За да няма разлики трейсът трябва да е с много голяма скорост. Другата файда от високата скорост е примерно като пишеш usb или ethernet стек или някаква комуникация и искаш да я трейснеш, естествено трейсът трябва да е по-бърз от usb-то или етернета.
Сега теоретично SWO може да бачка май до CPU клока, само че обикновен сериен на 100+ Mbit е безсмислица. Никога няма да работи, освен ако приемника не работи на абсолютно същия клок. Но клок както казах няма на стандартния конектор. Освен това трейсът е редно да работи винаги, още от ресет когато проца тръгва с нисък клок, после го вдига, после може да го сваля и т.н. Би било тъпичко да трябва да се сменят баудрейтове ръчно.
Доколкото знам и обикновения JLINK поддържа някакъв трейс но без да решава горните проблеми. Демек може да го ползваш като най-обикновен сериен порт, на много ниски скорости, да нацелваш баудрейтове и т.н. Но това за мен не е трейс...
Решението, което АРМ са измислили за тия проблеми е манчестър кодиране. Това позволява на приемащата страна да детектне продължителността на старт бита и автоматично да определи баудрейта и да работи безпогрешно дори и при много високи честоти (до 40-50Мбит, а може и повече).
Чисто практически настройките в какъв режим да се работи и изобщо дали да се пуска трейс е редно да ги прави емулатора или дебъгера. Фърмуерът обикновено се опитва да трейсва, но само ако трейсът е разрешен. Ако не е, изплюва данните и толкоз. Демек фърмуера не го интересува дали ще ползва JTRACE, PEEDI или нещо друго и кой как точно ще го ползва.
Тук говоря за трейс на съобщения, заложени в кода. Теоретично има различни виртуални портове, демек може да има множество виртуални канали. Аз ползвам само един канал, за да мога си виждам кой трейс след кой се появява. За различните неща просто ползвам различни цветове. Примерно ако е някаква комуникация, приетото го трейсва в един цвят, предаденото в друг цвят. Критичните неща са в червено и т.н. Смятам, че така е много по-прегледно, отколкото да ги пръскам в различни логове.
Освен за съобщения има възможност да се трейсва и какво прави самия процесор. Демек какви инструкции изпълнява от кой адрес и т.н. Тук обаче проблемът е в съответния софтуер, който трябва да обработва получените данни. Технически аз мога да правя такъв трейс, практически обаче нямам подходящ софтуер за след това.

За какво става дума... Едното приложение е статистическа обработка. Пускаш устройството, правиш лог и после анализи, които ти показват коя функция колко често се вика, колко отнема изпълнението и т.н. Това би било полезно, ако човек иска да оптимизира кода. Щото едно е да си мислиш къде цикли най-много, друго е да го измериш вместо да хвърляш боб.
Другото приложение е ревърс дебъга. Това е за ситуации в които примерно паметта се омазва и гръмва. Гръмването може да го хванеш и с обикновен дебъгер. Но виждаш примерно, че някой ти е омазал я стека, я указатели и съвсем естествено си гърми. Въпросът е кой и кога е направил омазването. Щото то може да е преди 5 секудни, може да е преди 5 часа или преди 5 дена. Та за целта просто правиш лог и зареждаш тоя лог в дебъгер. Като дадеш стъпка на пред, то просто отива на следващия ред от лога. Може да отидеш на момента на гръмването, да видиш коя памет точно е омазана, да сложиш watchpoint на нея и да пуснеш дебъга в обратна посока. И така ти спира там където е мазало последно.
Както казах аз още не ползвам нито ревърс дебъг нито execution trace. Не ползвам щото нямам софтуер, но бих искал да ползвам и ако някой разоре тая нива да свирка

Lauterbah е мерцедесът в тая област... Обаче то повечето неща са свързани със софтуера. Няма никакъв смисъл желязото ти да поддържа execution трейс, ако няма дебъгер или статически анализ. Само че в случая (пък и повечето случаи) то всичко една система, като почнеш от дебъгер, компилатор и някои стигат до RTOS-а даже.
И всичко е платено...
Хайде да оставим парите (които никак не са малко) пак опираме до това, което правиш. Ще правиш нещо на VxWorks, treadx или baremetal + gcc.. Според мен няма универсално решение.

...Ти наясно ли си с със нещата отдолу - как се записва състоянието на процесора на всеки такт - не се сещам за нещо по малко от 20-30 бита на всяка инструкция за да се следи състоянието на процесора т.е. 20-30 пъти по голям битрейт спрямо клока на койот върти процесора - или бъркам някъде бакалската сметка?

С подходящ хардуер (модулация) не би трябвало да е проблем да се предават няколко бита на такт.

Ти наясно ли си с със нещата отдолу - как се записва състоянието на процесора на всеки такт - не се сещам за нещо по малко от 20-30 бита на всяка инструкция за да се следи състоянието на процесора т.е. 20-30 пъти по голям битрейт спрямо клока на койот върти процесора - или бъркам някъде бакалската сметка?

Аз съм правил фпга-то на peedi, т.е. може да се каже, че съм наясно с SWO на хардуерно ниво. На софтуерно всичко го има документирано от АРМ, чел съм го навремето само от любопитство щото съдържанието и смисъла на пакетите не беше мой проблем. От тогава минаха 15+ години и не помня подробности. Но като цяло си имат система за филтриране и нещо като компресиране. Естествено през 1 пин няма как да изкараш всичко. Да кажем в минималния вариант те интересува само откъде е минало. Тогава се настройва да трейсва при инструкция с условен преход, както и викане/връщане. Абе като има някакъв преход. Колко бита ще генерира зависи от инструкцията. Евентуално ако нямаш твърде често преходи може и да се справи... Ако не мисля имаш опции дали да паузира процесора или да загубиш данни.
В общия случай през SWO май само за статистика става. С допълнителни трейс пинове ще е значително по-добре, но пак мисля че няма гаранция за пълен трейс. В смисъл то изпълнението ще го хваща, ама за Тайм дебъга ти трябват и достъпите до паметта. Особено при М7 и нагоре може да имаш достъп на клок, демек 32 бита адрес + 32 бита данни... Сещаш се колко бързо ще се задръства