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

[haker_fox]

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

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

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

[jcxz]

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

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

[haker_fox]

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

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

[jcxz]

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

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

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

В точку!

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

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

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