Тонкости отладки, JTAG, printf, светодиоды, ножки + осциллограф Опции

[uriy]

RTT хорош когда у чипа нет вывода SWO.

Не соглашусь. Насколько я знаю через SWO невозможно выводить по прерываниям. SWO работает только через поллинг. Это значит ваш код с выключенными отладочными сообщения будет работать совсем по другому. Если я не прав покажите как выводить через SWO по прерываниям.
RTT же работает по прерываниям. Причем можно настроить разное поведение по переполнению буфера. Можно ждать когда в нем появится место а можно откинуть данные. Вот тут отличная статья о нем https://habr.com/post/259205/

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

В смысле RTT viewer приходится перезапускать? Да это напрягает. Иногда он работает после рестарта кода иногда нет.

Как я понимаю, RTT абсолютно даром выкачивается с сеггера.

Не знаю. Я ставлю скачанный софт для jlink с закромов там вроде сразу все ставится. Отдельно RTT вроде не ставил.

Tracealyzer https://electronix.ru/forum/index.php?showtopic=127646

Для вывода данных через RTT использую вот такие макросы

Код

#define DEBUG_MSG    // default color
#define INFO_MSG    // green color
#define WARNING_MSG    // yellow
#define ERROR_MSG    // red


#ifdef DEBUG_MSG
#define DEBUG(fmt, args...) \
        SEGGER_RTT_printf(0,"%s%s %-20s:%-4d: " fmt "%s\r\n", RTT_CTRL_TEXT_WHITE, GetUpTimeASCII(), __func__, __LINE__, ## args, RTT_CTRL_RESET)
#else
    #define DEBUG(fmt, args...)
#endif

#ifdef INFO_MSG
#define INFO(fmt, args...) \
        SEGGER_RTT_printf(0,"%s%s %-20s:%-4d: " fmt "%s\r\n", RTT_CTRL_TEXT_BRIGHT_GREEN, GetUpTimeASCII(), __func__, __LINE__, ## args, RTT_CTRL_RESET)
#else
    #define INFO(fmt, args...)
#endif

#ifdef WARNING_MSG
#define WARNING(fmt, args...) \
        SEGGER_RTT_printf(0,"%s%s %-20s:%-4d: " fmt "%s\r\n", RTT_CTRL_TEXT_BRIGHT_YELLOW, GetUpTimeASCII(), __func__, __LINE__, ## args, RTT_CTRL_RESET)
#else
    #define WARNING(fmt, args...)
#endif

#ifdef ERROR_MSG
#define ERROR(fmt, args...) \
        SEGGER_RTT_printf(0,"%s%s %-20s:%-4d: " fmt "%s\r\n", RTT_CTRL_TEXT_BRIGHT_RED, GetUpTimeASCII(), __func__, __LINE__, ## args, RTT_CTRL_RESET)
#else
    #define ERROR(fmt, args...)
#endif

для putty через uart туда добавляю еще эскейп последовательности для цвета. Если надо оставить например только сообщения об ошибках закрываю дефайны в самом верху.

[haker_fox]

у меня есть неплохой анало

Можно подробнее?

[uriy]

Вот что оказывается надо сделать https://devzone.nordicsemi.com/f/nordic-q-a...wer/68926#68926 чтобы в RTT пошел цветной текст

[haker_fox]

Попробовал RTT. С наскоку (сразу) заработал вывод в буфер 0. Ввод не делал. В буфер 1 не работает. Полагаю, надо что-то настраивать. Порадовало, что судя по документации виртуальных консолей доступно более, чем может понадобиться. Также добавляет уверенность наличие исходников RTT для TARGET. С ними не разбирался, но в будущем можно понять, какой добавляется избыток в программу)))) Traceanalyzer не осилил. Он не подклчается к микроконтроллеру. Но там настроек очень много, а времени на это сейчас нет. В общем, uriy, выражаю вам благодарность за то, что напомнили мне об этих инструментах!

Критерий правильности софта - когда debug и release версии работают одинаково.

Скажем, необходимое, но недостаточное условие Но я согласен!
Но всё же, хотелось бы по-максимум исключить стадию перевода проекта на более выскоий уровень оптимизации. Хотя, как показывает беседа, от этого придётся отказаться. Любое средство отладки (или почти любое?) вносит свои нюансы в целевое устройство. Да даже банальный осциллограф оказывает воздействие на схему. ОФФ: помню, как долго добивался работоспособности nand-флешки на высокой частоте, пока не догадался отключить логический анализатор. А он у нас не китай, а lecroy

[jcxz]

Банально, по причине изменившихся времён выполнения кода. Понимаю, что некорректное программирование. Но вот и надо отладить эти моменты. А по-этому и вижу целесообразность отлаживать сразу с оптимизацией. В общем хочется внешнего опыта по этому вопросу)

Банально, но это обыкновенное "заметание проблемы под ковёр" как тут кто-то сказал.
Вместо того, чтобы это своё "некорректное программирование" найти и исправить, Вы пытаетесь придумать костыль чтобы проблема не проявлялась. В медицине это ещё называют: "Борьба с симптомами вместо лечения причины".
Нормально всё отлаживаются без оптимизации. После чего включают оптимизацию и просто проверяют, что программа не перестала функционировать. Отлаживать тут особо не надо. Ну если только в крайнем случае - посмотреть пару переменных в паре точек останова, но это можно и по асм-коду разобраться.
Корректно написанная программа работает одинаково как с оптимизацией так и без. Ну разве что за исключением случаев, когда ресурса быстродействия - впритык.

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

В точку!

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

Тоже часто так делаю. Для сложных проектов.
Ну и прочие комплексные сложные методы отладки.
Например: Когда отлаживал своё графическое API и юзер-интерфейс на его основе, то сделал эмуляцию работы LCD на компе (через USB-канал (уже использовался в устройстве) периодически передавал содержимое видеобуфера на комп и там рисовал его в проге на VS). А положение мышки на компе - через этот же USB на устройство. Так отладка графического API значительно упростилась и ускорилась.
Когда делали сложные устройства, длительное время работающие без выкл. питания и вдали от удобных мест отладки, то делали логгирование всяких критических событий (с полной инфой о них) в журналы во FRAM. С вытягиваением потом их по рабочему протоколу.
Сейчас вот пишу осциллографирование - тоже для отладки, наблюдение за множеством переменных в сложной программе в runtime.

Так что метода отладки сильно зависят от задачи.
А то что обязательно всегда есть по дефолту: JTAG/SWD и отладочный вывод в UART.

[AlexandrY]

Не соглашусь. Насколько я знаю через SWO невозможно ....
Вот тут отличная статья о нем

Эт моя статья.
Здесь я SWO упомянул в связи с использованием такой фичи Cortex-ов как Trace Port Interface Unit
Вот действительно очень нужная, просто критически необходимая вещь.

Почему здесь о ней ни разу ничего не видел даже странно.
Этот интерфейс связывает отладчик с Instrumentation Trace Macrocell (ITM)
Например в IAR есть хидер arm_itm.h с объявлениями типа ITM_EVENT8(channel, value)
Это как раз симулирует вывод на виртуальный пин сигнала чтобы посмотреть временную характеристику.
Только смотрят не осциллографом, а прямо в окне отладчика в виде графика.
Таких сигналов можно сотнями создавать, программе они обходятся в пару тактов.
И измерять их время с точностью до наносекунд. Можно среднее смотреть, можно худшее-лучшее время.
Именно с помощью ITM можно надежно посмотреть как оптимизация влияет на скорость разных функций и прерываний.
Кстати, временные характеристики (когда случились, сколько длились, кого прервали) всех прерываний выводятся через ITM автоматически без вставки каких либо команд.

[jcxz]

Очень правильный пользователь, которых хочет отсечь бракоделов с UB. Высокий уровень оптимизации хорошо выявляет таких "индусов".

Полностью согласен. Хотя даже тут, на форуме, приходится видеть фразы типа: "никогда не включаю оптимизацию". Видимо если её включить - всё повалится, а чел не хочет/не может искать свои баги. Ну и место такому поделию - соответствующее.

Да что-то давно не слышно zltigo.

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

Конкуренты увяли.
Они лепили кастомные платы, ставили туда десяточек одноцветных диодов и преподносили это как великолепную диагностическую панель. А мы повесили дешевую RGB ленту и вывели на нее сотни! диагностических сигналов.

Следующий ответный шаг конкурентов: вывести отладочную инфу в UART.

[AlexandrY]

Полностью согласен. Хотя даже тут, на форуме, приходится видеть фразы типа: "никогда не включаю оптимизацию". Видимо если её включить - всё повалится, а чел не хочет/не может искать свои баги. Ну и место такому поделию - соответствующее.

GCC-шниками что есть оптимизация что нет все одинаково, вот и не используют.
А так нормальная практика когда отладил без оптимизации, потом включил оптимизацию скомпилировал и отдал не глядя.
Но это уже надо иметь железную интуицию.

Следующий ответный шаг конкурентов: вывести отладочную инфу в UART.

Не UART, а облака.
И да, они тут нас урыли, но надеюсь ненадолго.

[Kabdim]

GCC-шниками что есть оптимизация что нет все одинаково, вот и не используют.

Обоснуйте вашу точку зрения, пожалуйста.

[haker_fox]

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

Вопрос был задан довольно ясно: есть ли альтернатива JTAG?

Корректно написанная программа работает одинаково как с оптимизацией так и без.

Ключевое слово - корректно написанная. А если она написана некорректно?

но это можно и по асм-коду разобраться.

Да? Вы серьёзно? Я вот такую квалификацию пока не заработал.

Когда делали сложные устройства, длительное время работающие без выкл. питания и вдали от удобных мест отладки, то делали логгирование всяких критических событий (с полной инфой о них) в журналы во FRAM. С вытягиваением потом их по рабочему протоколу.

Вот это уже ближе к теме, мы что-то подобное делаем.
Вообще, jcxz, вопрос мой был больше про методы отладки, кто что использует. И можно ли отладиться без JTAG. Вот и всё. Будем считать, что это мой личный интерес.

Ну и место такому поделию - соответствующее.

Классное высказывание! У вас наверно идеальная продукция?!

[jcxz]

Да? Вы серьёзно? Я вот такую квалификацию пока не заработал.

Тогда у Вас всё впереди

Вообще, jcxz, вопрос мой был больше про методы отладки, кто что использует. И можно ли отладиться без JTAG. Вот и всё. Будем считать, что это мой личный интерес.

Тогда вопрос поставлен неправильно. Ибо зачем "без JTAG"? Чтобы создать себе трудности, чтоб жизнь мёдом не казалась? Для достижения результата стОит (и нужно) использовать все методы, позволяющие достичь его с бОльшей скоростью и меньшими тратами.

Классное высказывание! У вас наверно идеальная продукция?!

При чём тут идеальность? Моя продукция не валится при включении оптимизации. Ибо когда такое происходит, я берусь за отладчик и не двигаюсь дальше, пока не найду причину.

[uriy]

Здесь я SWO упомянул в связи с использованием такой фичи Cortex-ов как Trace Port Interface Unit

AlexandrY это вам тема для новой статьи!

[haker_fox]

Тогда у Вас всё впереди

Ну так мне это действительно интересно! Я и тему это создал ради интереса, удовлетворения потребности расширения кругозора))) Когда у меня реальные трудности на работе, я практически не создаю темы, а сижу, и упорно решаю задачу. Так, что созданные темы на форуме - скорее показатель жажды знаний.

Тогда вопрос поставлен неправильно. Ибо зачем "без JTAG"? Чтобы создать себе трудности, чтоб жизнь мёдом не казалась? Для достижения результата стОит (и нужно) использовать все методы, позволяющие достичь его с бОльшей скоростью и меньшими тратами.

Вполне возможно, я посавил вопрос некорректно для других людей. Но ещё раз: я использую JTAG. Каждый рабочий день. На равне с этим я использую printf, консоль из состава FreeRTOS, журнал событий в EEPROM, ведётся логгирование на NAND. Но мне стало интересно, а можно ли без него, но по возможностям, не уступающим? Неужели, вы никогда не пробуете сделать что-то не стандарным путём, а альтернативным?

При чём тут идеальность? Моя продукция не валится при включении оптимизации. Ибо когда такое происходит, я берусь за отладчик и не двигаюсь дальше, пока не найду причину.

Ещё раз, я интересуюсь альтернативным путём. Работа моя (за которые деньги получаю) не стоит. Мне не платят за одни мечтания. Поэтому я тоже беру все отладочные средства, которые у меня имются, и ищу проблему. Ибо начальнику нужен результат.

З.Ы. Может быть вы не позволяете себе мечтать?)))))

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

Я не возражаю против этого по отношению к вам. Но сам с этим не согласен. Иногда считаю полезным пройти другим путём. Знаете ли, полезно)))) Люблю эксперементировать.

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

Если вы про J-Link, то тут главное не стать рабом этого средства) Потому, что оказавшись в поле, один на один с объектом, вы можете быть лишены возможности подключить отладчик, и даже вскрыть корпус. Но вам никто не запретит воткнуть USB кабель, и получить канал связи в своё распоряжение. Хотя можно J-Link запаять на плату в устройство, как вариант. Но это мне не подходит. Да и не одобрят мне такой подход. А вот консоль, журналы и т.д. и т.п. использовать можно.

Одно из наших устройств работает на электрической подстанции. И никто не будет отключать оперативное напряжение для того, чтобы мы открыли корпус. Но подключить ETHERNET/USB вполне могут. Вот и как отлаживать?

[jcxz]

Но мне стало интересно, а можно ли без него

да

, но по возможностям, не уступающим?

нет.
Ибо зачем бы его тогда придумывали и лепили (прямо в ядро уже), если и без него можно и нет никакой разницы?

Неужели, вы никогда не пробуете сделать что-то не стандарным путём, а альтернативным?

Трусы всегда надеваю через ноги, через голову никогда не пробовал. Если Вы про это....

Если вы про J-Link, то тут главное не стать рабом этого средства) Потому, что оказавшись в поле, один на один с объектом, вы можете быть лишены возможности подключить отладчик, и даже вскрыть корпус. Но вам никто не запретит воткнуть USB кабель, и получить канал связи в своё распоряжение.

Я не про J-Link. Я про весь отладочный комплекс.
Видимо Вы не читаете мои сообщения..... Прочитайте моё сообщение выше, про каналы отладки, которые мне приходилось использовать: https://electronix.ru/forum/index.php?showt...p;#entry1570953

Одно из наших устройств работает на электрической подстанции. И никто не будет отключать оперативное напряжение для того, чтобы мы открыли корпус. Но подключить ETHERNET/USB вполне могут. Вот и как отлаживать?

Вы не поверите, но уже десятки тысяч моих устройств работают на электрических подстанциях РФ и соседних стран (и не очень соседних). И никто не отключает напряжение, когда нам надо что-то проверить в своих устройствах
PS: А вот USB на подстанциях не место. Имхо.....

[AlexandrY]

Одно из наших устройств работает на электрической подстанции. И никто не будет отключать оперативное напряжение для того, чтобы мы открыли корпус. Но подключить ETHERNET/USB вполне могут. Вот и как отлаживать?

Хм, у меня на сети подстанций в узлах рядом с релейной защитой стояли SNMP шлюзы к системам климата.
Не так ответственно, но все равно режимные объекты.
Так на ура открывали двери и пускали. Я молча открывал корпус и сразу присоединялся к JTAG-у.
Более того я и на ARM-ы 7-ые в свое время перешел только из-за JTAG-а.
А то мне и 51-х которые на 300МГц работали хватало.

Даже сервисным инженерам на местах посылали свои адаптеры JTAG.

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