Добрый день, коллеги!

Собственно говоря, вопрос в теме. Просьба поделиться, кто как отлаживает свои проекты, выполненные на микроконтроллерах. Ядро не принципиально, но лучше Cortex-M0/3/4(F).

Почему возник вопрос? Раньше я не пользовался для отладки JTAGом. В не меньшей степени этому способствовали отзывы об этом инструменте уважаемого zltigo. Кто на форуме давно, тот поймёт. Поэтому я поднимал консольку. И работал с ней. Где было необходимо посмотреть вывод программы, добавлял свои версии printf. Либо махал лапками, с подключенным оциллографом. Потом, попробовав вкусности, предоставляемые JTAG, пользовался только им. При этом вывод в консоль стал если не вторым по приоритету, то точно на равне с отладчиком. Но вот проблема. Пользователю нужно отправлять программу с выставленными уровнями оптимизации (обычно balanced для IAR). Отладживать же программу с этим уровнем не всегда удобно, т.к. исчезают переменные, ветвления и даже функции. Т.е. возниакает предположение, что JTAG годится только для черновой и грубой отладки. Дальше поднимаем уровень оптимизации, и пользуемся printf'ом и подобными инструментами. Но как принтфом получить информацию, что, скажем содержится в регистрах ssp или dma модуля, как остановить программу в нужном месте и посмотреть переменные? Как отследить call stack? Уважаемый zltigo часто говорил, что ему хватает только консольки, и за отладчик он берётся только в особо сложных случаях.
В общем я снова стал приходить к выводу, что отлаживаться через аппаратный отладчик - бесполезная затея. Нужно сразу выставлять уровень оптимизации на максимум, и использовать иные способы. В связи с этим у меня возникла определённая каша в голове, и захотелось услышать мнение коллег по этому вопросу? Возможно ли использовать что-то вместо JTAG при отладке, почти не уступающее ему по возможностям? Или может быть я вообще не тем путём иду?
Спасибо!

А зачем, извините, отлаживать программу с включённой оптимизацией?

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

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


Отладчик читает эту информацию ровно так же, как и программное чтение. Если Вы отладчиком прочитаете чувствительный к чтению регистр, программа и под дебаггером будет вести себя эпично-эпилепсично. Программу остановить можно, по крайней мере в Cortex-Mx, инструкцией программной точки останова BKPT + некое шаманство с регистрами отладчика (режим Halt вроде).
Отказываться от отладчика, ИМХО, глупо. Ну а насчет отладки в оптимизированных программах - то, как было сказано выше, это бесполезно (понятное дело, почему). Программа должна работать одинаково на любых уровнях оптимизации. Если это не так - это уже повод подсуетиться и посидеть денек над облагораживанием программы на предмет возможных скрытых багов. Оптимизатор не исправляет ошибки пользователя - он лишь жестче показывает программисту, где он не прав, на мой взгляд
Ну а для устройств, которые должны отлаживаться далеко за пределами моего рабочего стола - я веду систему логгирования всего и вся на внутренний накопитель и при возникновении проблем - требую .log файл сессии, где уже с ним в поте лица сижу и думаю "шо цэ такое было".
Осциллографом и лапкой МК смотрю обычно правильность настройки частоты этого МК по таймерам. Светодиодов пару всегда на устройствах ставлю - это дэ-факто. Ну а насчет call stack - программно тоже можно сделать, достаточно проанализировать состояние CPU и содержимое стека.

Jlink (SWD) + RTT

предлагаю перевести в плоскость "какие существуют" или "какие юзали-знаете"...

у мну зависило от задачи, камня, возможностей(читай лапок).
ногодрыг (осцил, светодиодик), jtag отладка, в лог файл (конфигурирование из ini файла)
не юзал, но на мой взгляд заслуживают внимания: - по сети (если проект поддерживает сеть)
так-же интересен подход в 1 пин (делается декодер на скорострельной плисине), делается код на сях (разница нолика от единички - в один ноп) и всё...достаточно шустро и не зависит от тактовой...

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


как то так...
(круглый)

Интересное ограничение. Откуда взялся такой привередливый пользователь? Прямо так и говорит: "включайте оптимизацию, адназначна"?

Коллеги, спасибо! Я не собираюсь отказываться от отладчика. Просто интересно было услышать какие есть альтернативы ему кроме тех, которые мне известны.
Обработчики на hardfault, stack overflow и out of heap у меня есть. Также использую configASSERT (из FreeRTOS). В eeprom пижу журнал на 20 событий, прямо текстом в случае наступления этих событий. EEPROM находится внутри МК, поэтому доступ к ней 100%, даже в обход штатных драйверов под управлением оси. Помогает видеть статистику сбоев.


Если это стёб, то как принято сейчас говорить очень толсто!. Я ничего не говорил о требованиях пользователя. Но я сказал, что пользователю требуется отправлять. По нашим внутренним требованиям.

Конкретно поинт про ненужность дебагера у злтиго считаю снобским и вредным. Он работает для самого злтиго и 5% таких же как он. А его попытка убедить всех что его рецепт применим для всех, а если пользуешься дебагером то "нипрограмист" откровенна вредна. Спустя десятки лет набитых шишок десятки схожих задач и проектоа, возможно дебагер и правда будет не нужен, но это значит только то что человек которому не нужен дебагер вошел таки в эти 5%.

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

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

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

Понятно, у меня примерно такие же измышления.

Это уже интересно. Т.е. ассемблерная вставка (или макрос) с командой. Но, получается, что JTAG должен быть подключен.

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

Прежде всего это для собственного (я про себя) самолюбия и гордости. Без иронии. Ну, и посольку, я не один проект выполняю, мнение коллег тоже учитывается.

Кстати, отладчик не очень помогает, когда снаружи микроконтроллера висит железка, дающая этак 8 кГц на ногу прерываний, по прерываниям запускаются транзакции DMA и т.п. В момент остановки отладчиком, обычно выпадаем в ошибку DMA, или сразу после возобновления выполнения ПО. Т.к. потеряна синхронизации пакетов.

Да что-то давно не слышно zltigo.
Его искрометный сарказм здОрово веселил в былые времена.
С тех пор мало что изменилось в отладке.

Ну вот я стал ставить RGB светодиоды. Эт честно был прорыв в нашей сфере. Конкуренты увяли.
Они лепили кастомные платы, ставили туда десяточек одноцветных диодов и преподносили это как великолепную диагностическую панель.
А мы повесили дешевую RGB ленту и вывели на нее сотни! диагностических сигналов.
Ну надписали их конечно.
Один взгляд и практически сразу ясно что случилось с системой.
Откуда собственно и растут ноги у этого проекта - https://habr.com/post/373027/

Компилю сразу с включенной оптимизацией, если надо что-то отлаживать по шагам оптимизацию отключаю.
Логи вывожу через RTT + китайский Jlink (правда мне в нем не нравится отсутствие возможности вывода цветного текста) или uart в putty (тут с цветным текстом нет проблем).
Логический анализатор saleae китайский клон, usb-uart переходник.
Tracealyzer для Freertos

Да, без него скучно... И опыт у него огромный. Жаль, что исчез(((


ВО! Точно, давно о них знаю, но всё никак не попробовал.
Как я понимаю, RTT абсолютно даром выкачивается с сеггера.
А вот Traceanalyzer врод как за денежку. Не подскажете, есть на наших закромах "нежадная" версия?

При работе с дебаггером :
Вместо отладочного printf - использую "log" breakpoint. (это не требует перекомпиляции, изменения кода, можно менять-переставлять BP во время отладки).
Для отладки в "жестком" реалтайме (таймеры, прерывания, RTOS) - ногодрыг, выводимый на осцилограф с лог.анализатор или ЛА Saleae.
Критерий правильности софта - когда debug и release версии работают одинаково. Опции оптимизации - по необходимости, но когда после их изменения что-то перестает работать - стараюсь разобраться в причине.
JTAG экономит много времени и невров.

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

Но консоль сама по себе довольно устаревший подход.
Я тут в инетах видел гуляет микриумовский uC/Probe.
Правда сам не пробовал, у меня есть неплохой аналог, но за такими штуками будущее отладки.

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

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

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

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

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

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

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

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

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


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

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


В точку!


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

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

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

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

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


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


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

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


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

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

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

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

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

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


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

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


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


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

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

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

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


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

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


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


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

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

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

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


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


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

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

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

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

А если не девайсе стоит пломба(ы)? Сможете не нарушив её на "ура" подсоединиться?

Да и объекты видимо были не очень режимными, т.к. даже пару инструктажей по ТБ не провели

Да мало ли зачем.

Понятно.

Ну как же не читаю. Ваши как раз в одну из первых очередей. Это правда.
Просто конкретно в этом случае я вас не правильно понял.

Я не про количество устройств, а про модельный ряд. Одно из наших устройств также будет растиражировано. Но это десятки тысяч одной модели!

Вы их один делаете (вряд ли), значит вы руководитель отдела/группы?

Что вы делаете? РЗиА или ?

Вполне возможно. Но есть ещё ETHERNET.


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


Как вы осуществляете доступ к своим устройствам? Удалённо? Я ещё раз повторюсь, энергетики просто так никого не пускают на действующие электроустановки в РФ. Либо у вас есть допуск (не знаю какой и кем оформленный), либо ваше устройство имеет удалённый интерфейс.

Конкретно: привод высоковольтного выключателя 110 кВ. Какой ответственный за подстанцию в своём уме пустит туда постороннего? Они своих-то по двое запускают на опертивные переключения, да ещё с камерой на каске. Чтобы вот такие моменты фиксировать)

Ну и в модельном ряду 7-8 шт. точно есть.


Делал. На прошлой работе. В группе конечно. Но значительную часть ПО.


АСКУЭ, АСТУЭ, АСДУЭ.


Удалённо обычно. В действующие лично - только при проблемах. Со всеми необходимыми бумажками, согласованиями, инструктажами и т.п. в допустимые технологические окна.


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