Pull to refresh

Comments 23

Не упомянут интерфейс SWO, который можно использовать как для вывода данных в терминал, так и для отображения состояния нескольких переменных, включая построение графиков (значительно быстрее, чем в STMStudio, не привязано к продукции ST).

В некоторых «жирных» контроллерах есть скоростной интерфейс ETM Trace, требует более навороченного программатора/отладчика, зато позволяет собирать огромное количество информации о происходящем в контроллере в реальном времени.

Есть еще механизм Semihosting — по интерфейсу SWD можно передавать/принимать данные в терминал.

В многих IDE есть возможность просматривать переменные в реальном времени, не останавливая MCU. Скорость обновления при этом обычно не высокая. Хотя я не уверен, что при этом отладчик не влияет на скорость выполнения программы.

В IAR (про другие IDE не знаю) есть интересная фича — при работающей отладке можно в определённом месте кода сохранить данные из RAM на диск ПК: Ссылка

Для того, чтобы просматривать содержимое массивов в виде графиков при помощи отладчика, я в свое время писал специальную утилиту: Ссылка2

Судя по частоте упоминания UART для отладки, создается ощущение, что автор в основном пользует 8 - битные решения. Посему упоминаний про SWO нет.

интерфейс SWO

Интерфейс SWO не позволяет отправить данные в микроконтроллер. Поэтому он не очень эффективен по сравнению с UART.

SWO можно использовать параллельно с UART.

А к какому из вышеперечисленных пунктов относится Посткоды?

》пошаговой отладкой через SWD/JTAG?

На Процессорах она ещё и по каждому из ядер позволяет отлавливать и отлаживать.

Есть еще вариант post-mortem отладки, т.е. снятие дампа памяти, который позже можно как-то расковырять (например, загрузить в отладчик)

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

Какой ужас! Мало того, что нет ни эмуляций, ни трассировки в реальном времени (на самом деле есть, но автор просто не знает, как работает упомянутая "хипстерская тулза". Но даже те методы, что описаны, описаны криво!

Чем логи на SD отличаются от логов в USART? Как термометр поможет отлаживать прошивку? Можно было бы добавить примеры вспомогательного кода для отладки. Можно было бы рассказать про дампы памяти на SD и разбор инцидентов. Можно было бы описать ограничения каждого метода и лучшие кейсы применения.

Напишите сами про это. Наступит чудо у вас появится хотя бы один пост.

Как правило, методов SWD+логический анализатор хватает для всего. Остальное для совсем уж специфических случаев, а кое что может сожрать весьма существенную часть Flash.

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

1) Подмена выходных сигналов отладочной информацией. В той ситуации было совершенно невозможно использовать другие методы отладки. Ни эмулятора, ни точек останова, ни debug printf, ни GPIO/LED. Вместе с тем, прошивка формировала некие выходные сигналы. Временно заменив эти сигналы отладочной информацией, удалось вывести эту информацию наружу и по ней обнаружить и исправить ошибки в программе.

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

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

4) Создание «пыточной» программы установления сетевых соединений. Изредка затыкался сетевой стек. Ошибка была практически невоспроизводима «на заказ». С помощью программы, постоянно устанавливающей и рвущей соединения, удалось воспроизвести ошибку за полчаса-час «пыток». Дальше дело техники — внутрисхемный отладчик, останов программы, изучение ее состояния — и вот ошибка найдена и исправлена, повторные несколько суток «пыток» показали, что результат достигнут.

Да, что еще важно… Никогда не отмахиваться от сообщений коллег или клиентов о сбоях. Оно обычно само не проходит, не рассасывается — как беременность.

"Подмена выходных сигналов отладочной информацией."
Когда-то давно читал, как программист выводил ШИМ на имеющееся реле, и оно издавало звук. Причем не абы какой - для отладки в контроллере был реализован простейший синтезатор речи)

Однако недооценена роль светодиодов при отладке.
В своё время промышленно применяли вот такие ленты для отладки:

Поскольку вывод в них был по DMA из RAM без вмешательства программы, то продолжали работать даже когда софт уходил в разнос. Для управления требуется всего один сигнал.

STM Studio разочаровало. Работает только через адаптер ST-LINK.
В этом контексте надо было упомянуть о визуальном отладчике в Arduino IDE (раз уж автор выбрал такой хаб).

Нет также упоминаний таких методик как MIL, SIL, PIL, HIL
А это очень интересные подходы.

А можно про эти подходы подробнее, пожалуйста?

UFO just landed and posted this here

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

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

Вот потребление у некоей схемы при мигающем светодиоде:

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

Но нужен измерительный дивайс с большим динамическим диапазоном.

Который всегда под рукой, особенно в цеху, особенно ночью, особенно за 1000+ километров от офиса разработкии, как вишенка на торте, с системой на проходной "вноси что угодно, но вынести надо пропуск и хрен тебе этот пропуск кто подпишет", да.
Реальная практика которую продавил лично сам:
было на МК 8(восемь) свободных выводов GPIO.
Так совпало что и основных задач выполнения было тоже восемь. А далее было уже преодоление косности мышления коллег и добавление на плату 8 светодиодов и простой строки в тело каждой функции: пока выполняется - горит соответствующий светодиод. Всё.

UFO just landed and posted this here

Да, в большинстве случаев отладочный вывод через программный асинхронный передатчик гораздо удобнее и информативнее, чем использование ЦАП. Особенно если есть свободный аппаратный таймер. Но даже если нет - всё равно можно выкрутиться.

Любая разработка начинается там, где есть возможность делать диагностику. Когда нет способов диагностики, то говорить о разработке не приходится.

Программировать MK без отладки это как писать ручкой с закрытыми глазами.

Sign up to leave a comment.

Articles